Boost logo

Boost :

From: Branko Èibej (branko.cibej_at_[hidden])
Date: 2000-06-10 05:32:50


Kevin Atkinson wrote:
> I think that safety should be the default when debugging a program, but
> when compiling for production use efficiency should be the default
> *unless* the cost of safety is cheap as for as efficiency goes.

You're assuming here that the safe implementation will catch *and
warn about* all the programming errors that would cause the efficient
implementation to misbehave. If you don't guarantee that, the result
will be hard-to-find bugs that never show up in "debugging" code.

A good example of how things should be done IMHO is the STL practice of
providing a non-checking operator[] and a checking at() method. Nobody
sane will put a

        #ifndef DEBUGGING
        # define at(x) [x]
        #endif

in her code (even if it didn't cause a syntax error). That would mean
that, in the final instance, the released product containes code you
never really tested.

And a good example of how things _shouldn't_ be done is the Microsoft
practice of not providing support for assert() in the optimized version
of their runtime library. Which means I can't use the faster library
and still keep assert()s in my code, although in my opinion an abort()
is always better than a segfault (or worse). Which in turn means that I
have to implement my own assertion macro; then what's the point of having
a standard interface?

    Brane

-- 
Branko Èibej                 <branko.cibej_at_[hidden]>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: (+386 1) 586 53 49     fax: (+386 1) 586 52 70

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