------- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-22 07:03 ------- > Using a copy constructor and returning by value is of limited > applicability. Having to invoke a copy constructor to "simulate" a > post rvalue operation is not an option for objects that do not support > copy, and perhaps more significantly for large objects, is both very > time inefficient and could blow stack.
Why do you say could blow the stack, the C++ standard actually mentions an optimization where the copy constructored is removed and there is no extra variable. It is called named return value optimization which removes the need for the extra stack, basically the return value is actually a pointer that is passed into the function and then initialized that way. So I don't see your point still. The result you are seeing is exactly, I mean exactly what the C++ standard says the results should be as b = a++; is translated exactly as b = a.operator++(0); and not as b = (tmp = a, a.operator++(0), tmp); In fact this is worse than what you are suggesting the C++ standard says there is an extra tmp variable on the stack to begin with while before with named return value, you don't have one. >Furthermore, changing the > implementation would not break any existing code that returns a copy > constructed object as in your example. Such a change could only alter > semantics of source code that depends on non post rvalue op semantics > which are certainly not expected, specified, or likely. Actually it would violate the C++ standard and break existing code as people don't have to return the copy. Your example shows exactly why your proposal change will break valid code. I think you need to go back and read more about overloading operators as it seems like you don't understand that overloading operators can sometimes change the semantics if the overloaded operator changes them as shown by your example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31652
