[boost] Re: Variant implementation change (was re: unions)

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-09 08:41:05

"E. Gladyshev" <egladysh_at_[hidden]> writes:

> --- brock <brock.peabody_at_[hidden]> wrote:
> [...]
>
>> No resources are leaked and class invariants are maintainted.
>> 
>> > Let's say that there is an assignment exception
>> > and varaint<t1,t2> has one of
>> > the value-initialized types, t1 or t2 now.
>> > What do you normally do with that?
>> 
>> I don't know what you would want to do, but my understanding is that if an
>> exception has been thrown from an operation on an object, and that operation
>> does not make the basic guarantee, the results of subsequent operations on
>> that object are undefined - it might not even be safe to destroy it.
>
> I understand all these theoretical considerations.  What would you
> normally do in practice?  Are there any useful practical techniques
> that would clearly benefit from basic guarantees?

Yes, any code which creates classes in automatic variables benefits,
because you know it isn't going to crash when it unwinds.  But that's
just one example.  If you have, for example, a dynamically-allocated
class instance which isn't destroyed during unwinding, you can be sure
that it's still in a valid state after an exception has been thrown.
If you don't know that program invariants are preserved, you can
basically do nothing reliably.  This is error-handling 101; if you
want to challenge established wisdom in this area, well, I guess I
won't argue with you (because it seems futile) but I think it'll take
more than your disbelief to convince me that it's useful.

> Remember that after the exception the original object could be
> already gone.  The variant has just a value initilized object now.
> Who cares whether this value initialized object has a type from
> variant types or of some internal type.  The rest of the code will
> have to be able to handle it anyway.

No, that's incorrect.  The rest of the code would not have to handle the
internal type if the variant always contains one of the types it was
specified with.

> This is why boost::variant has the 'backup' flag.  In practice, it
> is no different from singular variant.

That's incorrect, too.  The "backup flag" is an implementation detail
which doesn't affect the external interface.  If the variant could
contain a type not in the specified list, that would constitute a
change to its external interface.

Somehow I get the feeling that you're so convinced of your intuition
that the current design is wrong in some absolute sense, that you're
unable to think clearly about the issues.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com