"Fernando Cacciola" <fernando_cacciola@hotmail.com> wrote in message news:cute52$2g5$1@sea.gmane.org...
"Fernando Cacciola" <fernando_cacciola@hotmail.com> escribió en el mensaje news:cutcrj$tcb$1@sea.gmane.org...
"Joe Gottman" <jgottman@carolina.rr.com> escribió en el mensaje news:curjg1$2vq$1@sea.gmane.org...
[SNIP]
It has the added advantage that if T's assignment operator has the strong exception safety guarantee, so does optional<T>'s assignment operator.
Well, this is a good point. It is typical for classes with a throwing copy ctor to have a strong assignment.
OK, I was sure there was a good reason why I didn't use T's assignment to begin with. I just didn't remeber it when I responded. The idea is that by using T's operator=() we are _entirely_ left to its own exception guarantees, with no guarantee at all from optional<T> itself. The current implementation gives you the basic guarantee, which is more than enough in most cases, no matter how ill T could be: if something goes wrong while reseting the value of *this, it is left uninitialized.
So the correct path is to add the cannonical guard AFAICS.
I disagree. This may ensure the basic exception-safety guarantee, but most code that uses optional<T> will use T::operator=() at some point or other. So if T::operator=() is not exception-safe, chances are good any program that uses optional<T> will not be exception safe either, regardless of whether optional<T> is. Thus, you are not gaining too much. And you are losing the strong exception safety guarantee when T::operator=() has it. I think you are much better off implementing optional<T>'s assignment from T's rather than using the destroy and recreate idiom. Joe Gottman