In article <3fe1f73d@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

>>> For inline functions this is true. Not so for extern linkage.
>>
>> You cannot have external linkage for template functions.
>>
> You can. You just have to make sure that a specialisation for the
> used type is linked in extenally.

Well, you still need the whole template source code for the compiler to
work.  So, the code would still be generated locally and the linker may then
indeed decide to throw the local instance of the template functions away and
use the one from the outside, but this will hardly gain you anything but
problems with most compilers.

>> Only if you use containers of many different types!  Modern linkers will
>> eliminate multiple identical template function instances, thus you only
>> see the code bloat in the object files, but not in the final linked
>> program.
>>
> 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!).

>> But only if there is data.  If properly designed, if there is no data, no
>> memory should be allocated.  Unless you use fixed-size data in C, you will
>> have exactly the same amount of work.  And there is nothing that keeps you
>> from using fixed-size data in C++, except that it is bad style, in both
>> languages.
>>
> I have the feeling that we're not getting the point of what we want
> to tell each other...

Could well be the case.

> 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...


> 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!

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++).  And of course, you will still
have the same problems when doing something similar in 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.  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.

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!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message