Re: [boost] Temporary objects

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
> 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