https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051
piotr5 at netscape dot net changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |piotr5 at netscape dot net
--- Comment #1 from piotr5 at netscape dot net ---
I have the same problem, it makes the r-value types tedious.
however this is not a bug in gcc directly, it's a bug in stdc++1x specs
omitting this special case and what should be done here. however, as a
feature-request I suggest at least when accepting gcc extensions to the
standard (or better yet check with the stdc++1x paper if this contradicts the
standard), gcc should proceed as suggested in this bug-report.
more concretely: if in the example given the return-value rval would stay alive
after the return (for example it's static), then the current behaviour of gcc
should be kept. if rval would become destroyed because of going out of scope
through the return, then std::move() should implicitly be added by the compiler
alike to syntactic sugar.
alternatively one could write a software which checks all return statements for
classes which can be r-value initialized and outputs a warning whenever the
return statement doesn't come with std::move() around the returned value and
the used variable is going out of scope. this functionality could also be added
to whatever code-checker. but such a solution would only introduce yet another
hassle for the programmer.
to emphasize: the reason why this feature is important is because gcc doesn't
automatically do garbage-collection. if return-statements copy and destroy some
big class frequently, this creates many holes in memory, cluttering free space.
so this kind of optimization is needed for both, speed and size...
