Boost logo

Boost :

From: Valentin Bonnard (Bonnard.V_at_[hidden])
Date: 2000-07-21 14:34:23

Lois Goldthwaite wrote:

> I thought we had a general principle to write "ideal" code and let the compilers
> catch up.

That's a good policy in general.

> If our target compilers are capable of compiling code with exception
> specifications, albeit with some loss of efficiency, I think this is a
> documentation issue.

But, did we used ES (exception specs) because they solved a problem
or because the C++ language gives us ES and we had to thank C++ by
using ES ?

> As I understand the purpose of throw specs, they should contribute to greater
> robustness of code,

What kind of robustness ? Let's define foo as:

void foo ()
    bar ();

void bar ()
    throw 1;

// Documentation

// foo
// Precondition: none
// Effect: does nothing
// Postcondition: none
// Throws: nothing

Here the exception will escape foo. Let's add an empty
throw spec to foo: foo will terminate. Does the latter
option correspond to your definition of more robust ?
(Just asking, not ironical.)

I see two possible uses for ES:

(1) during debug, to check that only allowed exceptions
    escape foo

(2) with a tool capable of diagnosing that foo might throw

W/o systematic use of ES, (2) is very hard.

> and I believe there is some talk of strengthening the
> language support for them next time around.

As you know, ES aren't checked at compile time for serious reasons,
not because the committee didn't had time to add compile time
checking of ES.

Even in Java, some exceptions (Error and RuntimeException) can pass
through ES checking.

> Why pessimize the source code out of
> fear the (currently inadequate) compiler will pessimize the output? (Unless, of
> course, the output is so woefully inefficient that it becomes absolutely
> necessary, but that should be a case-by-case decision, as Howard says.)

For smart_ptr, it seems to me that the output would indeed be
woefully inefficient.

Valentin Bonnard

Boost list run by bdawes at, gregod at, cpdaniel at, john at