RE: [boost] Re: unions

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-10-08 18:42:25

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of David Abrahams
> Sent: Wednesday, October 08, 2003 6:01 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: unions
> 
> "Brock Peabody" <brock.peabody_at_[hidden]> writes:
> 
> > So library could offer any one of
> >
> > (1) no exception safety guarantees
> 
> Not if I have anything to say about it.

I agree that that should not be the default implementation.  It would be the
correct implementation for someone compiling without exceptions though.
It's not something I would ever need personally :)

> 
> > (2) basic guarantee
> > (3) strong guarantee
> >
> > Where performance is traded for increasing safety.
> 
> I doubt you can gain any useful performance for the "no guarantees"
> case, since it's easy just to tweak the invariant or add empty_type.

That's true.

[...]

> > It's certainly the least surprising solution.
> 
> Why is the strong guarantee less surprising than the basic guarantee?
> It's certainly not the norm among container types, and appropriately
> so.

I don't mean to say that it's less surprising in general, just in this
particular implementation.  Maybe confusing is a better word than surprising
here?

> > Doesn't boost::smart_ptr have thread safety mechanisms that increase
> > overhead unnecessarily when not needed?  I think that was the right
> > thing to do too.
> 
> How much efficiency should we sacrifice before we decide to stop
> applying that principle?

Doubling the size of variant is probably too great a sacrifice.  I don't
work on many performance intensive projects so my gut instinct is to take
the safer, simpler solution.  In hindsight I have to agree that it's not the
correct solution in general

Brock