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

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

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

> I just want to know how to use basic guarantees in practice.

I have been trying to tell you: the basic guarantee is almost the
minimal assurance you need to have in order to be able to continue any
program after an exception.  A more appropriate question would be:
"how is it possible to use anything less than the basic guarantee in
practice?"... and I don't know the answer to that one.

>> > 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.
> It is even worse. In the case of singular variant you need just one
> additional case in the rest of your program. 

No, you need an additional case for each visitor.  Furthermore, you
may turn compile-time errors into runtime errors, a poor tradeoff,
IMO.

> In the case of basic guarantees 

It isn't a question of "singular variants vs. basic guarantees".
Nobody's going to give up the basic guarantee.  Either we're going to
change the invariant of the class to accomodate singularity, thus
preserving the basic guarantee, or we're not going to have
singularity.

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

Handle *what*?

Unexpected to whom?  If the docs say what the guarantees are, why
would anyone expect more?

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