🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #2567

Re: ubiquitous exception specs?

#2567
From: Fergus Henderson
Date: Mon, 13 Nov 1995 17:15
85 lines
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!matt
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>

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