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

>> And on modern compilers an assignment will
>> rarely cause a copy being made.  Return value optimisation will take care
>> of
>> almost all cases in modern compilers.  Anyway, this really isn't even
>> necessary as most STL containers are designed to minimise assignments and
>> copies to cases where it is really necessary.
>>
> For inline functions this is true. Not so for extern linkage.

You cannot have external linkage for template functions.

> The result is lots of inline code which results in larger executables
> and eventually even in slower code.

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.

>>> But _not_ for real simple types. For "I quickly need a vector", using
>>> double v[3] is still faster than anything using operator new or
>>> applying a fancy con/destructor.
>>
>> Sorry, but if you need a local variable, who said you should use new???
>>
> So, if you need a local variable of just such a type we're talking about,
> i.e. a class which simply contains a pointer to an internal class,
> then the class will be allocated on the stack (okay, fast) and the
> internal class will be allocated using operator new on the heap.

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.

> All that happens when you call the constructor and initialize your
> class. For the normal use, this is just what you want because when
> you pass the class to a function, it is quite fast (just increase
> reference counter). But if the object is simply a local var you want
> on the stack, then the overhead is considerably.

Why would you reference count the internal data of most classes?  You seem
to be thinking about some special case, but even then, how would a reference
counting C++ implementation be slower than a similar C implementation?

>> Of course if one uses new in a brain-dead manner it is easy to make a
>> program slow, but it is like using malloc for local variables in C - just
>> something nobody would do.
>>
> Correct. But if your class behaves that way because you're doing reference
> counting (see above), then there is little you can do against that.

Well, you should really not be doing reference counting inside a class in
the first place.  If you share data among several objects of the same class,
most of the time you have a serious design problem.  And again, the
reference counting would not work differently in C, so there is again no
difference in overhead!

    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