Boost logo

Boost :

From: Joe Gottman (jgottman_at_[hidden])
Date: 2002-11-17 19:11:14


"Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
news:02df01c28e4f$15cc5b30$76c3a8c0_at_nesottolap...
> ----- 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. Moreover, if you put the precondition in the library,
you
> take the burden away from the client; this is highly recommeded since it
> encapsulates
> commen code _one_ place, not O(n) places!
>

   On the other hand, if the library writer does check the precondition and
it fails, there isn't too much he can do other that immediately abort the
program or throw a very general exception. Whereas if the end user checks
the precondition he may be able to write code that corrects the error, or at
least throw a specific exception that lets the user know exactly where and
when the mistake occurred. If both the end user and the library writer
check for the same error condition the library writer's check is a waste of
time. This reasoning is why the STL vector class includes both operator[]()
and at() member functions.

Joe Gottman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk