Hi Niels,
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 reference
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 & ;
;) indeed
Maybe Ion Gaztañaga's Boost.Move can be of help to emulate move semantics in C++03? http://svn.boost.org/svn/boost/sandbox/libs/move_semantics/doc/html/index.ht...
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.
Let's see: 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. That is: 1) o.assign_to(v) is the counterpart of: v = o ; which would move IFF 'o' is an rvalue. 2) o.move_to(v) is the counterpart of: v = std::move(o) which always moves. Best -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com