Subject: Re: [boost] Temporary objects
From: DE (satan66613_at_[hidden])
Date: 2009-11-02 12:28:54
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
>> 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
i mean that in an example like
type foo(const type &to_be_processed)
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)
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk