Re: [boost] Exception specifications in smart_ptr.hpp

From: Greg Colvin (greg_at_[hidden])
Date: 2000-07-16 13:11:40

From: Howard Hinnant <hinnant_at_[hidden]>
> David Abrahams wrote on 7/16/2000 11:29 AM
> >From: "Beman Dawes" <beman_at_[hidden]>
> >
> >> Should boost programming guidelines ban exception-specifications?
> >
> >Yes, without specific compiler switches which turn them on when it's been
> >determined that it is an optimization.
> >But I am absolutely *certain* that we've discussed this on the list and that
> >there was (at least) a published web page which said they should be avoided.
> >I think it was the library guidelines. I am also pretty sure that the
> >discussion was specifically in reference to smart_ptr and that we had
> >decided to leave them off on purpose. So I'm surprised to hear that they
> >crept back in.
> 
> No I don't think they should be banned.  Though I will admit that I would 
> vote against they're use in every project I'm currently familiar with.  
> But I think they should be considered on a case by case basis, and not 
> banned with a blanket statement.  They provide a runtime behavior that 
> could be desirable in some circumstances.

Given the state of current compilers exception specifications
usually do more harm than good on inline functions.  It's
unforunate that this is true, because the "throws nothing"
specifications in shared_ptr aren't there for runtime behavior,
they are there as *specifications* that certain operations will
not throw, by design.  If we are forced by low compiler quality
to remove the specs we should add comments and documentation so
that users can count on this design.

For non-inline functions "throws nothing" specs may allow
optimizations that help more than their overhead hurts.