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! _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
