"Jody Hagins" <jody-boost-011304@atdesk.com> escribió en el mensaje news:20050216142546.4f00c668.jody-boost-011304@atdesk.com...
On Wed, 16 Feb 2005 12:10:01 -0300 "Fernando Cacciola" <fernando_cacciola@hotmail.com> 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