From: Valentin Bonnard (Bonnard.V_at_[hidden])
Date: 2000-07-21 13:44:17
Mark Borgerding wrote:
> In theory, I love the concept of throw specifications; describing exceptions as part
> of the method invocation, almost as part of the signature
You mean type, don't you ?
> -- telling both the class
> user and the compiler exactly what can possibly be thrown, It seems clear however,
> that they can cause a performance hit on some compilers.
> Perhaps there is a middle ground.
> Since at least one compilers *is* apparently capable of using a throw() to their
What kind of benefits ? Time ? Space ? Both ?
``at least one compilers *is* apparently'' is pretty vague.
> (or at least doing no harm) , it would be a shame not to take advantage of
> such a compiler. Perhaps we should use a preprocessor macro that would expand to an
> empty throw-spec or nothing, depending on the compiler flags. In either case, the
> class user will be informed of the behavior of the method with regard to exceptions.
> That way, the intent of "throw()" can be documented in the code, even if the macro
> expands to nothing.
> #ifdef BOOST_BAD_EMPTY_THROW_SPEC
> # define BOOST_NOTHROW
> # define BOOST_NOTHROW throw()
I have used a THROW macro in my code for this purpose.
Still, on an inline function, it never helps the compiler.
-- Valentin Bonnard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk