🚀 go-pugleaf

Steve Clamage wrote:

> If sumsq has a throw() clause, the compiler can assume that
> no exceptions will escape from sumsq, and perhaps can avoid adding
> exception-handling code to the calling location. At the call
> site, there are no disadvantages to sumsq's empty exception-spec,
> and there are potential advantages, as you noted in your article.

The Borland compiler makes no attempt at optimizition of the caller in 
this case.

> If a function has an empty exception-spec, the compiler must in
> general add scaffolding to the function to ensure that any exceptions
> occurring in the function do not escape. In the case of sumsq, the
> compiler may be able to determine that no exception is possible,
> and not generate the extra code. If the extra code is generated,
> on most implementations it does not add to the run time of the
> function.  Typically none of the extra code is executed unless an
> exception actually occurs and would otherwise escape from the 
> function.

The Borland compiler makes no attempt to deduce whether it really needs 
this code, and adds it no matter what. It amounts to a couple of calls 
to helper functions which don't amount to that much code, but too much, 
in my view, for simple functions like sumsq (or, say, C string handling 
functions like strlen).

It was my experience with the Borland compiler that led me to these 
thoughts. I tried adding throw() to all my diddling little utility 
functions, in the hopes that it would simplify some of the calling code, 
and was surprised to find that it didn't do that, but instead made the 
functions more complicated. I then decided to junk the throw() 
specifiers. Then, however, it occurred to me that with a different 
compiler, junking the throw() specifiers could be the exact wrong thing 
to do. Hence, my desire for throw(void) to be explicitly defined as an 
optimization hint.

-- 

Ciao,
Paul D. DeRocco

[ To submit articles: Try just posting with your newsreader.  If that fails,
		      use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]