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

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-10-09 14:16:38

--- Brock Peabody <brock.peabody_at_[hidden]> wrote:
> OK, I'm going to summarize this for you, and then I swear I'm done with this
> thread too :)
> 
> (1) We have to provide at least the basic guarantee.  You have to understand
> that it is of the highest degree of utility to make it so that exceptions
> don't put our program in an undefined state.  There is nothing to debate
> about this.

Agree, nobody wants to put a program to an undefined state.
The basic guaratntees (*the way they spelled out in boost::variant*)
is not the only way to ensure that the program is defined. That is _fact_.

> 
> (2) The strong guarantee is too expensive because it would double the size
> of all variants.  This is opinion but the consensus seems general.

It is not expensive if you allow your program to copy storage 
it allocates. This is opinion.

> (3) Bitwise copying of non POD types, no matter how you call it, is
> undefined.  This is _fact_.

The "reusing storage" concept in the standard is undefined too then.
The whole variant idea is undefined then.  
Look at it this way, you are not copying a non POD type
all you do is copying the content of a storage that you program 
allocated. It is not even funny anymore that you keep going back
to this "undefined copying" stuff.

> 
> (4) The basic guarantee could be met without heap backup by relaxing
> boost::variant's invariant to allow for a singular state.  Fact again.

Agree but you have to be specific "basic guarantees in general, not the way
they spelled out in boost::variant".  I am arguring that singular variant
is the most user friendly way to ensure basic guarantess in general.

> 
> (5) If variant can be singular you will need an additional case for each
> variant and possibly turn many compile-time errors into run-time errors.
> This is a fact too.

Singular variant is better then the situation when boost::variant 
reinitializes the user data under the covers and
says "hey, I am fine now, don't worry"

> 
> (6) You can get the behavior in (4) by specifying boost::empty as one of the
> possible types in variant.  Can't argue with that.

Not true. variant< my_type, empty > technically variant 
can reinitialize (in case of an exception) my_type, not 'empty'. 
It is not the same as singular variant. That is _fact_.

> 
> (7) It is preferable to have heap backup rather than introduce another case
> for every variant visitor and risk the possibility of additional run-time
> errors, especially since those who want the possibility of singular variants
> can request it.  This is opinion, but I suspect it will be the general
> consensus.

see my prev. comments

Eugene

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