[boost] Re: move semantics

From: David Abrahams (dave_at_[hidden])
Date: 2004-04-18 16:14:24

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?

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.

Technique 2 seems to require most compilers to go through move
constructions in situations where technique 1 allows the compiler to
elide copies.  That could bring a significant speed penalty for some
types, unless optimizers are smart enough to eliminate the code later.

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.

Borland doesn't seem to be able to cope with technique 2.  It
complains that operator= is ambiguous.  I didn't try very hard to work
around the problem, though.

Results
-------

This code has been tested on win32 with the following compilers.
Where the techniques differ, results are shown as
#technique1/#technique2.

como-win32              3 suboptimal copies in strict mode.  With
                        -DBOOST_IMPLICIT_MOVE_CTOR_FOR_COPYABLE_TYPES
                        in non-strict mode, 0/1 suboptimal copies
                        with 1/3 warnings.

cwpro8                  0/1 suboptimal copies

gcc 2.95.3, 3.2, 3.3.1  0 suboptimal copies

bcc564                  2/? suboptimal copies
                        <<< can't handle technique 2 yet >>>

msvc 6, 7, 7.1          0 suboptimal copies (**)

                        vc7 issues a couple of bogus warnings (C4927)

intel8                  0/1 suboptimal copies (**)

intel5 intel6 intel7    2 suboptimal copies (**)

(**) On these compilers, non-copyability isn't automatically inherited
     from movable<T>, i.e. the boost::noncopyable trick doesn't
     work. Rvalues are silently bound to non-const references.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com