Re: [boost] Exception specifications in smart_ptr.hpp

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 
    int

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