Article View: comp.std.c++
Article #2567Re: ubiquitous exception specs?
From: Fergus Henderson
Date: Mon, 13 Nov 1995 17:15
Date: Mon, 13 Nov 1995 17:15
85 lines
3517 bytes
3517 bytes
herbs@interlog.com (Herb Sutter) writes:
>In article <smeyersDHwpw1.48n@netcom.com>,
> smeyers@netcom.com (Scott Meyers) wrote:
>>There is a small performance penalty to be paid for each exception
>>specification, because they have to be checked at runtime to be sure
>>they're not violated. This typically increases code size and decreases
>>code speed, though the cost of the feature varies from compiler to
>>compiler.
>
>Good point, but isn't the exception spec checked only when there actually is
>an exception? If so, then there should be no penalty in normal operation, to
>bastardise the old 'only pay for it if you use it' line.
An exception specification is pretty much equivalent to a `try ... catch'
block. For example,
void foo() throw (X, Y)
{
bar();
}
is pretty much equivalent to
void foo() {
try {
bar();
}
catch(const X &) {
throw;
}
catch(const Y &) {
throw;
}
catch(...) {
unexpected();
}
}
Widespread use of exception specifications would definitely result in an
increase in code size, although it is difficult to say how significant this
would be. (If anyone has any data on this, please post it!)
Whether or not it will have an impact on runtime speed depends on both
the compiler and the application. Some compilers (such as Sun's C++
compiler and GNU C++, from what I have heard) implement exceptions in
such a way that a `try ... catch' block has only very minimal runtime
cost if an exception is thrown, but with other compilers (apparently
including Borland C++ and Microsoft C++, from what I have heard) there
is a definite run-time cost associated with a `try ... catch' block,
and so there will almost certainly be a similar cost associated with
the use of exception specifications.
It might be a good idea to use a macro so that use of exception
specifications could be enabled or disabled via a command-line switch:
#ifdef USE_EXCEPTION_SPECIFICATIONS
#define EXCEPTIONS(x) x
#else
#define EXCEPTIONS(x) /* nothing */
#endif
void foo() EXCEPTIONS(throw(X, Y))
{
bar();
}
This would enable you to easily measure the efficiency cost of
exception specifications. You would want to keep them enabled for debugging
purposes, but if they turned out to be costly, and efficiency was important,
you could disable them for the production version.
(It's a pity C++ doesn't have variable-argument macros like GNU C/C++ does -
if it did, this could be made a bit more concise, e.g. just `THROW(X, Y)'
rather than `EXCEPTIONS(throw(X, Y))'.)
--
Fergus Henderson WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Technical Details
Message-ID:
<9531723.9375@mulga.cs.mu.OZ.AU>Path:
arc1-ca.pugleaf.net!128.32.155.1!mattReferences:
<47va08$8lb@gabi.gabi-soft.fr> <480rub$oi0@steel.interlog.com> <483e1r$kkd@steel.interlog.com> <smeyersDHwpw1.48n@netcom.com> <48535s$58r@steel.interlog.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!128.32.155.1!matt From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson) Newsgroups: comp.std.c++ Subject: Re: ubiquitous exception specs? Date: 13 Nov 1995 17:15:33 GMT Organization: Computer Science, University of Melbourne, Australia Approved: matt@physics2.Berkeley.EDU (Matt Austern) Message-ID: <9531723.9375@mulga.cs.mu.OZ.AU> References: <47va08$8lb@gabi.gabi-soft.fr> <480rub$oi0@steel.interlog.com> <483e1r$kkd@steel.interlog.com> <smeyersDHwpw1.48n@netcom.com> <48535s$58r@steel.interlog.com> NNTP-Posting-Host: physics2.berkeley.edu