on 31.10.2009 at 17:12 Mathias Gaunard wrote :
afaik nrvo is not implemented in msvc80 RVO is implemented since MSVC6, NRVO since MSVC7. you might know better however afaik these are of very limited use
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 that in an example like
type foo(const type &to_be_processed) { type ret; //processing return ret; } semantics of the copy constructor does matter here nrvo likely not to take place (actually it should NOT take place)
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. afaik by the standard a compiler only allowed to directly construct a temporary only in case like
type bar(const other &a) { intermediate i; //??? return type(i); } //... res = bar(input);
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. well, to this point i still think that a temporary<type> better reflects the underlying semantics than, i guess, BOOST_RV_REF(type) (looks extremely ugly)
And no, it's not nerdy meta-programming, C++0x is simply introducing a new mechanism to distinguish rvalues from lvalues: rvalue references. i have a picture of that and you can't imagine how hard i wait for the new standard but for now i try to exploit existing tools that's why all these perversions exist
-- Pavel