Re: [boost] minor scoped_ptr/scoped_array feature request

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-17 12:53:52

Thorsten Ottosen <nesotto_at_[hidden]> writes:

> ----- Original Message -----
> From: "Peter Dimov" <pdimov_at_[hidden]>
> [nip]
>> In general, it is recommended practice to always assert() preconditions in
>> client code, instead of relying on in-library asserts. First, the library
> is
>> not required to have asserts, and second, the earlier you catch
> precondition
>> violations, the better (call stacks aren't universally available).
>
> I don't get this. It's a poor library if it does not even check its
> own preconditions in eg. debug mode. 

Not all preconditions are effectively checkable.

> Moreover, if you put the precondition in the library, you take the
> burden away from the client

No you don't. Either it's a precondition or it's not. If the library
documents behavior in case of a "precondition violation", it's not a
precondition anymore. The client can call the function and reasonably
expect the documented behavior.

>  this is highly recommeded since it encapsulates commen code _one_
> place, not O(n) places!

You can always add wrappers that add the checking you desire, and more
importantly, implement some useful (to you) response to a failed
check. However, there's no way to take away checking if it gets put in
the library, and there's no way to change the response in case of a
failed check if it's not the response you need.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution