DE wrote:
afaik nrvo is not implemented in msvc80
RVO is implemented since MSVC6, NRVO since MSVC7.
certainly it would be nice to have such but with current standard it is very hard to implement
Not really. You just have to deduce the expression you're returning is either a temporary or a local variable, which is hardly difficult for a compiler.
it because it is very hard to statically analyse the code of copy constructor and assignment operator
NRVO doesn't involve the assignment operator at all. The optimization also doesn't even require to know what the definition of the copy constructor is, so static analysis of its definition is irrelevant.
i mean either the standard would be broken or the optimized code might produce unexpected behavior, e.g. where you expect 2 copy constructors there is only 1 etc.
The standard explicitly states that the compiler is allowed to elide calls to the copy constructor in certain situations, even if the copy constructor in question has side effects. It also states the same thing for move constructors in C++0x.
while nrvo is not guaranteed (again afaik) to take place this approach will always (!) work if it is explicitly stated so
Boost.Move already provides move emulation for C++03, and moving is independent from NRVO.
i'm not familiar with upcoming move features but my guess is that it will be some nerdy metaprogramming (no offence guys) while i propose almost trivial solution which can be started using right now without even changing classes (structs) definitions
Boost.Move is actually fairly similar to what you are proposing. And no, it's not nerdy meta-programming, C++0x is simply introducing a new mechanism to distinguish rvalues from lvalues: rvalue references.