Re: [boost] [move] move assignment from lvalue returned by func (was: one more dumb question)

Subject: Re: [boost] [move] move assignment from lvalue returned by func (was: one more dumb question)
From: Christopher Jefferson (chris_at_[hidden])
Date: 2010-02-26 15:21:35

On 26 Feb 2010, at 20:11, DE wrote:

> on 26.02.2010 at 21:27
> Jeffrey Hellrung wrote :
>> Yes, the type of an rvalue can be const-qualified, but the current
>> mechanism cannot distinguish between a const-qualified rvalue and a 
>> const-qualified lvalue.  So only returning by non-const value will work.
> 
>> For a simple demonstration of the basic mechanism (untested, so not sure
>> if it will compile, but it should give the basic idea)
>> [code here]
> oh now i get it! i didn't realize there are operator rv<T>& and its
> const counterpart hidden behind the macros
> thanks for your effort explaining this
> 
>> I don't have any simpler solutions, only a spectrum of solutions to
>> select the best set of tradeoffs for a given situation.  Which, in some
>> sense, is more complicated.
> so summing it all up i say that this solution is far too tricky to be
> useful
> no offence
> it seems to me too restrictive and too incomplete
> the infrastructure is too complicated
> on the other hand i guess forcing users to return something like rv<t>
> from functions like this
> 
>  rv<my_type> foo();
> 
> is not an option
> 
> another question arises: who is the target audience (aka users) of
> this lib?

I use this lib myself, as it implements a significant subset of "true rvalue references" from C++0x. Using this library, and some care, we can write optimal code for new C++0x compilers, while maintaining support for older C++03 compilers as well.

Chris