Boost logo

Boost :

From: Ed Brey (brey_at_[hidden])
Date: 1999-07-08 09:22:10


Email seemed somewhat boring, until Dave Abrahams wrote:
>
>A _decorated_ function will call unexpected (which usually results in
>terminate) rather than propagate an exception thrown by a function which it
>calls. That is how it honors the contract of its exception-specification.
>This mechanism costs something in time and/or space unless _both_ of the
>following conditions hold:
>1. The compiler can prove that none of the functions which the decorated
>function calls can throw an exception
>2. The compiler actually implements the optimization which makes use of the
>proof in step 1.
>
>This is the rationale:
>It is seldom that a compiler can make the above proof.
>Very few compilers implement the aforementioned optimization.

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 moreover
destructor can and should have an empty throw specification, when
compilers get up to par, the empty throw specification on the template
won't cost anything. 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.

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.

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.

Side note: Small error I just noticed: On page:
http://www.boost.org/libs/smart_ptr/smart_ptr.htm#Common requirements
in "The behavior of all four classes is undefined if the destructor or
operator delete for objects of type T throw exceptions.", "throw" should
be "throws".

------------------------------------------------------------------------

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