Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-08 18:01:10


"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.

> (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.
> 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.

The strong guarantee is not "just do the right thing", especially if
it's bought at the cost of efficiency. It can always be added later
in an outer layer, but the lost efficiency can never be restored if
it's killed in an inner layer.

> 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.

> 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?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk