Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-02-17 06:39:01

"Jody Hagins" <jody-boost-011304_at_[hidden]> escribió en el mensaje
> On Wed, 16 Feb 2005 12:10:01 -0300
> "Fernando Cacciola" <fernando_cacciola_at_[hidden]> wrote:
>> The correct fix along Joe's initial proposal would be:
>> void assign(optional_base const& rhs)
>> {
>> if (is_initialized)
>> {
>> if ( rhs.is_initialized )
>> get_impl() = rhs.get_impl();
>> else destroy();
>> }
>> else
>> {
>> if ( rhs.is_initialized )
>> construct(rhs.get_impl());
>> }
>> }
>> AFAICS, this code is as safe aliasing-wise as it can be (it handles
>> not only the trivial case of this==&rhs but also any other deeper
>> aliasing issues)
>> If no voice is raised I'll proceed with this fix.
> Unfortunately, I believe you now have a new dependency on
> copy-assignment (i.e., T::operator=()), which IIRC, did not previously
> exist. This may break existing code for users whose classes do not
> implement copy assignment.
Yes I now. Joe did when he first proposed the fix, and I think that Peter
and David knows this too.
Yet, I (we?) don't think there would be any real user code breaking becasue
of this...
Or to put it another way, if a class is so broken as to support a reasonable
copy-constructor (which is a current requirement), but not assignment, then
I'm probably doing him/her a favor by breaking it :-)

Consider that an assignment operator is such a fundamental thing that the
compiler generates one for you if you don't. IMO, there are no classes with
no support for assignment.. at most, they have the wrong user-defined
If the semantics of T's assignment are in any way odd (say auto_ptr), then
that of optional<T> should really be just as equally odd.


Fernando Cacciola

Boost list run by bdawes at, gregod at, cpdaniel at, john at