Thorsten Ottosen <[EMAIL PROTECTED]> writes:
> ----- Original Message -----
> From: "Peter Dimov" <[EMAIL PROTECTED]>
> [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
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
