|
|
Thorsten Froehlich wrote:
>> Correct. But all as you normally need to have all template stuff
>> inline, this results in a lot of inline code duplication.
>
> No, only the very common bad programming habit of placing template
> implementation code inside classes instead outside causes template code to
> be inlined (also a compiler is *not* required to inline anything!).
>
(Yes but good compilers do when told so...)
>> Because the C construction does no reference counting. You allocate
>> a pointer once and then use it. And the designer knows where it was
>> allocated, "who" is responsible for the pointer and its lifetime.
>>
>> Yes, that's insecure like hell but faster and smaller.
>
> Of course, nothing keeps you from doing this in C++ as well...
>
We were talking about what is faster... and what safer...
>> That will (1) allocate some bytes on the stack (fast) and then
>> (2) allocate internal object using operator new (slow).
>>
>> That is what I had in mind.
>
> I almost assumed you did. However, node that having just a pointer to an
> "internal" object is just terrible design, and if you use this to hide
> something "private" behind another interface, C++ is not the language you
> want to be using!
>
Ah really?! Have fun reading the STL code :p
> Second, if you really have a valid need to frequently create temporary
> copies of a specific class of objects, you will gain a really lot if you
> use
> a memory pool (i.e. boost::pool for C++).
>
I tried things like that. Stack allocation is still fastest for
small amounts of memory.
> And of course, you will still
> have the same problems when doing something similar in C.
>
One would not use a desing like that in plain C.
>> I still am the opinion that it is pretty hard if not (nearly?) impossible
>> to design really fast C++ code (i.e. as fast as insecure C code) when one
>> forces itself to stick to all the "good style" guidelines. (Depends on
>> what one defines as "good style").
>
> Yet, but you are making two major mistakes in your logic here: Just
> because C++ allows you to use more secure programming methods does not
> imply in any
> way that C++ is slow or slower than C. It simply implies that a
> well-programmed piece of code will have a tiny bit of overhead over a fast
> hack.
>
I was making no mistake in my reasoning. I just wanted to express
what you stated above in your own words...
No discrepancy there.
> And the languages features for good programming style only exist in
> C++ but not C. Thus you can only use them in C++, while you are stuck
> with unstable code in C.
>
You could implement similar (not-so-safe) things in C. Don't understand
me wrong:
I do _not_ propose that, it's just what I extracted from your frequent
replies stating "you would have the same overhead in C when implementing
that in C".
> However, this is the case for any higher language level. You can claim
> exactly the same for C and your native assembler. Of course, if you know
> what you are doing you can still outperform even a very good compiler (the
> SSE2 noise code in POV-Ray is a good example for this) by using lower
> level programming languages, but that doesn't say anything about the
> higher level languages!
>
Correct. Assuming that one could implement the core parts of an
application in assembler gaining speed increases of factor 2 or above
it may seem irrelevant to talk about <=5% loss at a C -> C++ transition.
Especially if there are benifits (better maintainability, etc)
Wolfgang
Post a reply to this message
|
|