|
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