[boost] Re: Re: [bug]: optional<T> fails on self-assignment

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 
news:20050216142546.4f00c668.jody-boost-011304_at_atdesk.com...
> 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 
assignment.
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.

Best

Fernando Cacciola