Re: [boost] move semantics

From: Hamish Mackenzie (boost_at_[hidden])
Date: 2002-02-06 19:37:09

On Wed, 2002-02-06 at 21:47, Howard Hinnant wrote:
> On Wednesday, February 6, 2002, at 10:37  AM, Hamish Mackenzie wrote:
> 
> > I have uploaded move.tar.gz which implements some of these ideas.
> > http://groups.yahoo.com/group/boost/files/move.tar.gz
> > I have not had time to test it properly but let me know what you think.
> 
> I've taken a quick look at this.  I need more time to study it.  But 
> first impressions are pretty good.  One thing that caught my attention 
> pretty quickly was several similarities to John Maddock's design that I 
> noted at the beginning of this thread (and I think this is a good thing):

I should have mentioned that I saw some of those comments and I have
tried to include as much as possible.

> On Monday, February 4, 2002, at 04:26  PM, Howard Hinnant wrote:
> 
> > John Maddock has suggested:
> >
> > T b = std::move(a);
> 
> On Monday, February 4, 2002, at 07:40  PM, Howard Hinnant wrote:
> 
> > John Maddock has suggested that std::move return the struct
> > std::move_t<T>.  Then the class T could create a constructor and
> > assignment operator that accepted a std::move_t<T>.  This has a nice
> > parallel with the current requirements of implementing copy semantics.
> 
> Your move_from is quite similar to John's move, and your move_source<T> 
> is quite similar to John's move_t<T>.

Indeed.  I used a different name do differentiate it from move_to and
move_destination< T >

> > One thing that is probably important is adding overloads that take the
> > allocator to use as an argument
> >
> > template< typename T, class Allocator >
> > inline move_construct( T &, Allocator a );
> >
> > etc.
> 
> I don't see a need for this.  If a class needs an allocator it should 
> take it from the source.

Sorry that should have read

template< typename T, class Allocator >
inline move_construct( T *, T &, Allocator a );

I thought it might be important for a container implementor to be able
to pass in the allocator of the container.

> I think I see where are viewpoints are fundamentally different.  And 
> that is not a particularly bad thing.  It is just helpful to recognize:
> 
> You are concerned with getting move semantics up and running today, with 
> today's compilers and libraries.  And that is a laudable goal.

Yes but I also think that we can create an abstraction that would, most
likely, be compatible with future language extensions.  Then when the
compiler support is there we can change move_traits or the move*
functions.

This leaves us free to write code that uses move, move_construct etc.
without worrying if it will be compatible with future standards.
 
> I am more concerned with designing move semantics from the ground up for 
> inclusion into the next C++ standard.  And all parts of the puzzle are 
> open to change, including the language, and the std::lib.  Backwards 
> compatibility is only important so far as ensuring that existing code 
> continues to have the same semantics and performs no worse than it does 
> today.  Since move sematics do not exist today (except for auto_ptr of 
> course), we do not have to get existing classes moving.  Otoh, if we can 
> get existing classes moving for free, then why not take advantage of 
> that?  I'm still undecided on this issue.
> 
> Yes, the /only/ way to move existing std::containers is with swap (or 
> maybe clear/splice with list).   However I see no way to have vector or 
> deque take advantage of this new facility without changing their 
> implementation.  Since they have to change anyway to use move, I'm not 
> overly concerned at this point that they might have to change to be 
> moved.

Consider boost::some_container< std::vector< int > > though.  If
boost::some_container uses move then the payoff is large because it WILL
use swap( std::vector< int > &, std::vector< int > & ) to move items.

> >> 2.  How does one detect if an object implements move semantics (in
> >> templated code)?
> > We could add something to move_traits< T > to indicate how move will
> > behave. It could indicate if move is no-throw. Unfortunately it will
> > require the class designer to provide the information in some way.
> 
> Yup and Yup.  I dislike a facility that requires class authors to 
> register with it, except for the case where the number of objects that 
> need to register is known and manageable.  For example I can deal with 
> having to register all scalars with the move facility.  But I dislike 
> requiring Joe Programmer to register MyClass with it.  It is a source of 
> error that could all to easily go undetected (detected only by 
> performance monitoring or counting copy constructions for example).

So if move_traits is not specialized what should the default be?
  * use copy construct/assign
  * use swap
  * no move allowed

I am now leaning towards no move allowed (which I think was your
preference). Then specialize move_traits for existing classes that have
a good swap function.

> John Maddock suggested a traits class that would be specialized for 
> scalars (actually I think for PODS if is_POD comes on line), but for 
> classes it would use
> 
> 	is_convertible<move_source<x>, x>::value
> 
> (of course he used move_t, not move_source, but they are the same idea)
>
> This clever technique means that Joe Programmer only needs to provide 
> the converting contructor taking move_source<x>, and then x will be 
> automatically "registered" with move.

I like it! I will change the default move_traits so that it uses that.
When is_POD is available will add that too (is_scalar is already in
there).

> Unfortunately this will only detect the constructor taking move_source.  
> It won't detect move semantics if they are somehow provided "for free", 
> except perhaps for PODS.  And it won't detect move assignment no matter 
> what.  The best I currently have for that problem is a rule:  If you 
> provide move construction, you must also provide move assignment (and 
> vice-versa).

That seems like a reasonable assumption. I seem to remember reading a
similar rule for copy constructors and assignment opperators.  And the
worst that can happen if you forget "operator =( move_source<T> )"
should be a compiler error.

> >> 3.  How does one move from a temporary?
> > Hmm...
> >
> > T f();
> > T dest;
> >
> > move_to( dest ) = mover_from( f() );
> >
> > Will fail to compile (for good reason). But compilers should do a good
> > job with return values so
> >
> > T temp( f() );
> > move_to( dest ) = move_from( temp );
> >
> > Should be just as fast.
> 
> I could be wrong, but I think people will complain.  auto_ptr went to 
> great lengths to insure that you could move from a temporary, but not 
> from a const.  Indeed, auto_ptr_ref looks remarkably similar to your 
> move_source<T>.  I don't have the answer for this one.  I wish I did.  
> Imo, this is the hardest part of move, and may require help from the 
> language.

I did try this hack

template< typename T >
move_source< T > move_from_temporary( const T & source )
{
  return move_source< T >( const_cast< T & >( source ) );
}

And on the surface it seemed to work in gcc, but I didn't try it with
optomization on.  It feels wrong to me perhaps someone with a copy of
the standard could clarify this.

I don't think we can do what auto_ptr does without changing the return
type of f(), which I don't think is a good idea.

I still think a good compiler should be able to optomize out the copy
constructor from

T temp( f() );
move_to( dest ) = move_from( temp );

> I would much rather see:
> 
> void foo(T& source)
> {
> 	T t(move_from(source));
> }
>
> Or perhaps just:
> 
> void foo(T& source)
> {
> 	T t(move(source));
> }

I would prefer to add the following, but Fernando pointed out that it
needs to use aligned_storage< T > to work and I gather that is not
working yet.

template< class T >
move_to_here
{
  unsigned char buffer_[ sizeof( T ) ];
  T *get() { return reinterperet_cast< T * >( &buffer_ ); }
  const T *get() const { return reinterperet_cast< T * >( &buffer_ );}

public:
  move_to_here() { new ( get() ) (); }
  // not sure if it should have default constructor
  
  explicit move_to_here( T &source )
  {
    move_construct( get(), source );
  }
  ~move_to_here() { allocator< T >::destroy( get() ); }

  T & operator *() { return *get(); }
  const T & operator *() const { return *get(); }

  T * operator -> () { return get(); }
  const T * operator -> () const { return get(); }
};

Then you could do this

move_to_here< T > t( source );

Its still not ideal because you have to use -> and *
 
> Since the author of T may be required to provide the move_source 
> constructor anyway (say to avoid the default constructor requirement), I 
> am very inclined to /require/ the move_source constructor (except for 
> PODS).  That would clean up the end user syntax considerably.

The advantage of move_to_here is that it would work for existing classes
(eg. std::vector) 

Hamish Mackenzie