From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-10-09 13:42:06
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
(2) The strong guarantee is too expensive because it would double the size
of all variants. This is opinion but the consensus seems general.
(3) Bitwise copying of non POD types, no matter how you call it, is
undefined. This is _fact_.
(4) The basic guarantee could be met without heap backup by relaxing
boost::variant's invariant to allow for a singular state. Fact again.
(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.
(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.
(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
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of E. Gladyshev
> Sent: Thursday, October 09, 2003 1:04 PM
> To: Boost mailing list
> Subject: RE: [boost] Re: Variant implementation change (was re: unions)
> --- Brock Peabody <brock.peabody_at_[hidden]> wrote:
> > 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
> > 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?
> I think there is a missunderstanding.
> I am not saying about ignoring anything or letting the
> program to go to an undefined state.
> All I am trying to say that the basic guarantees
> the way they are defined in boost::variant are
> not practically usefull.
> The variant guarantees say that variant
> is allowed (during an exception) to change
> the the current user data to a value-intialized data.
> I don't see anything usefull in that.
> I am arguing that in case of an exception
> variant should delete the contained object
> and set it's state to singular.
> It is more friendly to the rest of the program
> than changing the user data.
> In fact it is no defferent from basic
> guarantess if you think of variant as
> always containing a built-in type.
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk