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
see my prev. comments
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk