[boost] Re: move semantics

From: Andrea Torsello (torsello_at_[hidden])
Date: 2004-04-19 07:59:35

David Abrahams wrote:

> David Abrahams <dave_at_[hidden]> writes:
> 
>> So I'm wondering if there's a way to combine the advantages of your
>> approach with those of mine.
> 
> The code in the sandbox now appears to be supporting both approaches.
> I've also added disable_if_same.
> 
> Use the BOOST_LVALUE_COPY_CTOR2 and BOOST_LVALUE_ASSIGN2 macros to
>                               ^                        ^
> auto-generate constructor/assignment overloads taking const_lvalue<T>
> instead of using the template technique.  Let's call that "technique 2".
> 
> Findings
> --------
> 
> Aside from the easier time you'll have getting partial ordering of
> constructors and assignment operators with technique 2, I noticed the
> following:
> 
> The use of the 'explicit' keyword for a T const& ctor overload seems
> to be completely unneccessary.  All the optimizations you can get in
> intel's strict mode are available using an ordinary non-explicit copy
> ctor. Am I missing something?

No, in some implementations you can just not provide the explicit
constructor at all (at least gcc works well without it). If you do that you
do not have the direct initialization problem anymore. I used the explicit
keyword to use my approach with compliers like Comeau that do not like if
you do not provide a X(X const &) constructor. I actually omitted to say
this on the first iteration of the sample code because I though I needed 
to focus on the general approach. In the library I use with gcc I simply do
not provide the explicit copy ctor at all.

> 
> In non-strict mode (and on Intel 8/win32) technique 2 seems to
> generate copies when constructing from const rvalues whereas
> technique 1 does not.

Yes, actually different compilers seem to act differently here. 
Since the compiler is free to copy const rvalues to non-const 
rvalues and optimize the copy away, I would consider returning a const
temporary an odd thing to do. I am curious: does anyone have a use-case 
for it?
 
> Not having a real T const& parameter for const lvalues makes writing
> overloads tricky.  I was able to make the macros transparent for
> operator=, but because of initializer lists there's no way to do the
> same thing for constructors.  const_lvalue<T> now has a conversion to
> T const&, so you can use boost::implicit_cast<T const&>(rhs) to get
> a reference to the argument with uniform syntax.

I am not sure I understood what you are saying here. 
Can you rephrase it please?
 
> Results
> -------
 [...]

We should probably try and not provide the explicit copy ctor with 
compilers that do not complain about it. I feel that this way some 
of the suboptimal copies will go away.

Regards,
Andrea Torsello