RE: [boost] Re: unions

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-10-08 17:20:20

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of David Abrahams
> Sent: Wednesday, October 08, 2003 5:06 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: unions
> 
> "E. Gladyshev" <egladysh_at_[hidden]> writes:
> 
> > --- David Abrahams <dave_at_[hidden]> wrote:
> > [...]
> >>
> >> Please consult any basic textbook on algorithm complexity.  No offense
> >> intended, but if we can't agree on O(N) == O(k * N), I think we'll
> >> never agree on anything and I don't see any point in continuing this
> >> conversation.
> >
> > Of course I are right, I was just teasing sorry.
> 
> Oh.  I should have a better sense of humor about that, but my time is
> so short these days...
> 
> > You were paranoid about me using word "behavior"
> > I was paranoid about 'k'; technically you should
> > have said that k is *independent* of N.
> > I liked your "o-n-squared-equals-o-one-ly" proof though.
> >
> > I think you and I agree that variant should not have a special
> > "first-type switch"?
> 
> Yes. However, I prefer that to anything other than "optimizing
> whenever an optimization is possible", which is where we may differ.

So library could offer any one of

(1) no exception safety guarantees
(2) basic guarantee
(3) strong guarantee

Where performance is traded for increasing safety.  Maybe some day the type
of exception safety chosen could be done by policy.  In the mean time, I can
see a reason for wanting any of the three.

My personal preference would be for (3).  I'd take the performance penalty
(the double allocation?) to get the strong guarantee - just do the right
thing you know.  It's certainly the least surprising solution.  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.

My .02

Brock