Josh Stern wrote:

> Since the de facto topic of this thread is code bloat
> in C++ and its relationship to quality of implementation,
> I'd like to ask about how much (if any) efficiency is gained
> with existing C++ compilers when throw() is added to
> all function definitions where it is permissible to add it.

Slower, out-of-line functions, bigger code on
some compilers with poor EH.

> This question is motivated by the idea that a function
> with local objects that have non-trivial destructors may
> be able to optimize the scheduling of those destructors
> more efficiently when it knows that all of the functions
> it calls will not throw exceptions.  Does this turn
> out to be significant with existing implementations?

What do you mean by scheduling ? Risc instructions
scheduling ?

Optimisation is normally done assuming exceptions are
possible but have a probabillity of 0.

On a good compiler, empty exceptions specifications
can help to have smaller EH code (that's code which
is used with a probabillity 0 too, so it should
never really be loaded in memory on systems with
lazy loading).

> Also, I'm wondering whether it would be a sensible
> language extension for a compiler to offer, as a flag
> option,  a processing mode where all functions
> that do not have throw signatures are interpreted as
> if they had the signature throw() and an error is
> issued where this does not work.

No. Existing code (including std lib implementation and
third party libs implementations) mostly don't use
exception specifications.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]