Re: [Boost-users] [Review] Formal Review: Boost.Move

Subject: Re: [Boost-users] [Review] Formal Review: Boost.Move
From: Neil Groves (neil_at_[hidden])
Date: 2010-05-21 03:37:28

>
>
> We are approaching the final days of the review and there have been no
> definitive reviews as of yet, and a lot of talk about design and what
> to include or not include.  If this continues without any actual
> reviews and none in sight then I will have to end the review period,
> else if we do start to get some reviews then we can issue an extension
> if the Review Wizards agree.

Heck, I intend to submit a review, but I'm having some terrible schedule
problems.

I really want to see a move library in Boost. From looking at the
implementation I like the design, however I have noticed a problem that as
yet, I have not thought of a solution for.

In the move emulation:

#define BOOST_COPYABLE_AND_MOVABLE(TYPE)\
   public:\
   TYPE& operator=(TYPE &t)\
   {  this->operator=(static_cast<const ::BOOST_MOVE_NAMESPACE::rv<TYPE>
&>(const_cast<const TYPE &>(t))); return *this;}\
   public:\
   operator ::BOOST_MOVE_NAMESPACE::rv<TYPE>&() \
   {  return *reinterpret_cast< ::BOOST_MOVE_NAMESPACE::rv<TYPE>* >(this);
 }\
   operator const ::BOOST_MOVE_NAMESPACE::rv<TYPE>&() const \
   {  return *reinterpret_cast<const ::BOOST_MOVE_NAMESPACE::rv<TYPE>*
>(this);  }\
   private:\
//

#else //#ifdef BOOST_MOVE_OPTIMIZED_EMULATION

#define BOOST_COPYABLE_AND_MOVABLE(TYPE)\
   public:\
   operator ::BOOST_MOVE_NAMESPACE::rv<TYPE>&() \
   {  return *reinterpret_cast< ::BOOST_MOVE_NAMESPACE::rv<TYPE>* >(this);
 }\
   operator const ::BOOST_MOVE_NAMESPACE::rv<TYPE>&() const \
   {  return *reinterpret_cast<const ::BOOST_MOVE_NAMESPACE::rv<TYPE>*
>(this);  }\
   private:\
//

These reinterpret_cast operations violate the standard aliasing rules
AFAICT. Indeed while most compilers work happily with this arrangement. I
have reproduced defects with GCC 4.4 when optimizations are enabled.
Additionally if one enables the strict aliasing warnings these lines are
indicated as being incorrect.

My concern here is that there is not an obvious simple and efficient
standard solution and yet, a change to correct this would almost certainly
significantly affect the interface.

I'll try and make some time so that I can put something more constructive
together. I figured it would be useful to put my concern out and see if
anyone else has a solution.

Regards,
Neil Groves