David Abrahams <dave@boost-consulting.com> 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