From: Dave Abrahams (abrahams_at_[hidden])
Date: 1999-07-08 21:51:38
> It sounds then like omitting the empty throw specification on reset
> and ~scoped_ptr is a compiler bug/feature workaround.
> Since the
> pointee is required not to throw in the destructor and
> destructor can and should have an empty throw specification
> compilers get up to par, the empty throw specification on the template
> won't cost anything.
Even if compilers "get up to par", the exception-specification on the
destructor will occur the same overhead unless the compiler can prove that
nothing it calls will throw an exception. The only way that can happen is if
all functions called in the destructor also have an empty
exception-specification, and so on, and so on... Since lots of code is being
written today which doesn't throw and also doesn't use
exception-specifications, this is unlikely to pay off.
> Actually, it may then become a cost savings
> because whatever contains the scoped_ptr will be able to optimize
> because it knows that the scoped_ptr destructor doesn't throw.
On a "perfect" implementation the savings will only be in data which is
never even touched if no exceptions are thrown. On a less than perfect
implementation, the costs of having the exception-specification will be in
both program size and execution speed even if no exceptions are thrown.
To get the gains you anticipate, you have to live in a world where all
compilers are perfect and where everyone writes empty
exception-specifications wherever possible. But exception-specifications
have a downside: not everyone wants the termination semantics that they
imply, and they cause big problems for program evolution and maintenance. In
particular, you lose the benefits of the separation of interface from
implementation when an exception-specification is placed on a
> I think that we should document the interface showing reset and
> ~scoped_ptr as having empty throw specifications, document that the
> pointee destructor should have an empty throw specification, and then
> actually implement the empty throw specifications with a temporary macro
> hack to disable the throw specifications in scoped_ptr and the pointee
> for compilers that don't handle it efficiently.
I will never agree with you that this is preferable.
> The main advantage of this is that it keeps the scoped_ptr interface
> constant through time, which is of the greatest importantance. After
> all, the implementation is just a detail.
There's another easy way to keep it constant through time: never add the
eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk