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

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-10-09 11:53:48

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of E. Gladyshev
> Sent: Thursday, October 09, 2003 11:23 AM
> To: Boost mailing list
> Subject: Re: [boost] Re: Variant implementation change (was re: unions)

[...]

> I don't care about anybody's wisdom or convincing anyone for
> the same matter. It is a technical discussion.
> I just want to know how to use basic guarantees in practice.

Read this: http://www.gotw.ca/gotw/082.htm

It is very simple.  If an exception is thrown from a function that makes the
basic guarantee, it is _possible_ to recover.  How is up to you.

If an exception is thrown from a function that does not make the basic
guarantee the result of _every_ subsequent operation in the program is
undefined.  Recovery is _not_ possible.

> 
> >
> > > 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.
> 
> What is the big difference with the singular variant if it has a value
> that was changed by the variant internals.

If you say that all variants can be singular, or empty, then every piece of
code in the whole world that deals with variants has to be prepared to deal
with them where before they could rely on variant always holding a value of
the types you list.

> It is even worse. In the case of singular variant you need just one
> additional case in the rest of your program.

One case everywhere in the whole program?  In everyone's programs?  This is
not trivial.

> In the case of basic guarantees you need to be able to
> handle unexpected value modifications for all the types.
> Again how do you handle it in practice?

It's not just about what happens to your variant, it's about what happens to
the whole program.  With the basic guarantee you are free to ignore the
variant if you want and do something else.  You can try to assign a
different type.  You can write a log entry.  Without the basic guarantee,
you can't do _anything_!

Imagine, for instance, that boost::variant ignored exceptions during
assignment - it stops making the basic guarantee.  Can you see that the
destructor for boost::variant will enter undefined territory?

Brock