From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-02-06 20:19:36
On Wednesday, February 6, 2002, at 07:37 PM, Hamish Mackenzie wrote:
> 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.
This is sounding like a promising compromise. In effect I believe this
is telling class authors that you can implement move semantics in one of
1. Provide nothrow constructor and nothrow assignment taking a
2. Implement a nothrow default constructor and nothrow swap and
register with move_traits.
And if you do neither, code should be able to detect that you don't
support move via move_traits (unless your class registers true with
is_POD in which case you do support move with no effort required).
Aside: Be careful what std::containers you give move semantics to via
choice 2. I know of implementations of std::containers that do not have
a nothrow default constructor.
> 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.
Not sure how this will be used. Will it mistakenly allow move from
> 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 agree that we can't change the return of f().
> 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 think people will still complain. I don't believe they will want to
do the extra typing to create a named temp.
move_to(dest) = move_from(f());
is so much easier.
And I still like:
dest = move(f());
better. But I think this is mainly because I've yet to be convinced
that we need the destruct-source (or relocation) versions of move. They
don't help in the std::containers. I'm looking for the killer
application where they can't be done without.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk