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

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-10-08 22:06:24

--- David Abrahams <dave_at_[hidden]> wrote:

> > [...]
> >
> >> I realize it now.
> >> I think that it is ok to have a singular variant.
> >> It should be treated as unallocated memory
> >> any access to it should generate an exception.
> >
> > The downside is that then all users of boost::variant have to test for this
> > possible condition or be prepared for runtime failure where otherwise they
> > could rely on the variant to contain one of the specified types.  Rather
> > than force this complexity on those who aren't concerned with the
> > possibility of using the heap backup, those who want this behaviour can just
> > specify boost::empty as on of the possible types of the variant.  As Dave
> > was saying you are in effect using boost::empty to specify the policy.
> 
> Note that it wouldn't just be forced on people who are willing to
> accept heap allocation.  It would also be forced on people who don't
> want heap allocation, but know they are never going to assign a
> *different* type into a variant once it's been initialized.
>

All are good points.
I really like the fact that
variant< my_type, int > and variant< int, my_type >
have the same behavior (sorry Dave :)) now.

What is the rationale for basic guarantees?
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?

BTW: I am not able to get the latest code from boost CVS.
I guess that the server is overloaded or something.
Worked fine couple days ago. I'll keep trying.

Eugene

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com