Boost :

Date view	Thread view	Subject view	Author view

Subject: Re: [boost] [optional] little addition... optional_move_to?
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2009-03-06 08:41:15

Next message: Fernando Cacciola: "Re: [boost] [SPAM (Header)] - Re: [optional] little addition... optional_move_to? - Number of numbers in MIME From exceeds maximum threshold"
Previous message: Stewart, Robert: "Re: [boost] [utility] new auto_buffer class --- RFC"
In reply to: Fernando Cacciola: "Re: [boost] [optional] little addition... optional_move_to?"
Next in thread: Arno Schödl: "Re: [boost] [SPAM (Header)] - Re: [optional] little addition... optional_move_to? - Number of numbers in MIME From exceeds maximum threshold"

I wrote:

> 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.

Never mind that.. if for lvalues it *must* copy instead of move, it
can't use swap(), then being a member function won't make any difference!

I see now that's why you said that the third fucntion could be the free
optional_assign_to() by Arno.

Agreed on your list then:

>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.

Best

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

Date view	Thread view	Subject view	Author view

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk