Re: [Gnucap-devel] waves branch and wave copy constructor

[al davis]

On Saturday 20 December 2014, Felix Salfelder wrote:
> std::map<X,Y>::operator[](const&X) returns a Y&, which acts
> more or less like a Y* here. thus, no copy is involved when
> accessing existant entry (speaking of c++98).

Sort of, but not here.

Even returning something by value, g++ does a good job at 
eliminating unnecessary copies.

But the map contains a bunch of <X,Y> objects, which are not the 
same as X objects and Y objects.

Every time an <X,Y> object is created, a X object and a Y object 
are copied in.

Every operator[], where a Y object is desired, unless the 
programmer is careful to use references all the way, there is a 
copy to extract the Y object from <X,Y>.

So, if you want to be sure it works like Y*, say so.  Problem 
solved.  That's one reason the DISPATCHER contains pointers.

> FWIW, in c++11, not even upon creating a new pair (accessing
> a nonexisting map element) the copy constructor of Y is
> called. they did a great job in avoiding unnecessary copies,
> which they are totally aware of.

That brings up the question of when gnucap should officially use 
c++11.  It's compliant with both new and old now.  There are 
some features in C++11 that I would like to use, but put off 
waiting for widespread availability.

This brings back memories of the transition to C++ from C, to C 
from FORTRAN/Ratfor, use of STL, use of plugins ...  ACS/Gnucap 
has traditionally led the pack in things like this, but always 
with a little caution "widespread availability".

There was a significant reduction in code size and memory use, 
and a slight improvement in speed with the transition to C++.

> i'm not fully convinced that the current implementation calls
> more copies than it should. but sure, i might be missing
> something.

There are!  The untested() macro tells me so!