Subject: Re: [boost] [optional] little addition... optional_move_to?
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2009-03-06 08:27:30
>>> Well, we can achieve almost the same in old C++03, by declaring the
>>> function as a /member/ of optional<T>. I'd suggest naming it
>>> "optional_move_to", as follows:
> Fernando Cacciola wrote:
>> Nice one! :)
> Thanks :-)
>> I keep wondering whether being member functions, these move_to() and
>> swap() need the "optional_" name prefix?
> In the case of "optional_move_to", "move_to" is okay to me as well, as
> "move_to" isn't so much "overloaded". (Although I still think that
> "optional_move_to", or even "conditional_move_to", is more clear.)
>> On further thinking, if the optional is an lvalue this would do the
>> right thing but will have the wrong name o)
> If "move_to" does either swap or assign-to, IMO the name is right, even
> if it moves from an lvalue.
What I really meant is that, with an lvalue, most likely you don't
*want* move but copy.
>> Or, probably better, a single [optional_]assign_to() that magically
>> does one or the other depending on "this" being and lvalue or rvalue
>> Something which, btw, in C++0x can actually be properly overloaded:
>> template<class U> bool optional<T>::assign_to( U& ) & ;
>> template<class U> bool optional<T>::assign_to( U& ) && ;
>> This is getting unsurprisingly closer to the initial proposal from
>> Arno :)
> What about adding a "const" overload as well? ;-)
> template<class U> bool optional<T>::assign_to( U& ) const & ;
> Maybe Ion Gaztañaga's Boost.Move can be of help to emulate move
> semantics in C++03?
I'm sure it could help, but I wouldn't like adding such a depedency into
Boost.Optional... but maybe I'm over reacting o)
> Anyway, for the time being I think that adding optional_move_to(T&) and
> optional_swap(T&) members (as I presented), and optional_assign (by
> Arno) should be sufficient.
With swap(), move sermantics are aways welcome for both l-and-rvalues,
so an optional_swap(T&) member makes sense.
When assigning from an rvalue, move-assign is aways welcome, while when
assigning from an lvalue you want move only by explicit request. So, an
assign_to() API that won't ever move from an lvalue but will always try
to with an rvalue also makes sense.. and it must be a member function
nowadays to potentially move from rvalues.
A member move_to() also makes sense when you explicitely want to move
even from an rvalue.
So.. I have the same list as you except for optional_assign(), which
should be a member to make moving from rvalues possible.
is the counterpart of:
v = o ;
which would move IFF 'o' is an rvalue.
is the counterpart of:
v = std::move(o)
which always moves.
-- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk