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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-02-15 18:22:15

Fernando Cacciola wrote:
> "Peter Dimov" <pdimov_at_[hidden]> escribió en el mensaje
> news:003201c51395$4f587820$6501a8c0_at_pdimov2...

>> A correct assignment operator should typically handle self-assignment
>> without an explicit test. Adding the test usually doesn't fix the
>> problem, only its most obvious manifestation.
>
> Which could be accounted as good enough for classes intended to be
> used in certain ways, thus making the swap idiom overkill.

It would (probably) be OK to offer a "limited" assignment operator that 
doesn't handle certain corner cases, but only if these cases are clearly 
documented as part of the preconditions of operator=.

But I'm really not sure why should optional<> attempt to provide a basic 
guarantee when the contained type does not (unless the basic guarantee is 
free, which it isn't.) A type that doesn't provide the basic guarantee is 
pretty much unusable.

It seems to me that the straightforward solution is to just defer to 
T::operator= when necessary. Those that want destroy+recreate semantics can 
always obtain them explicitly.