Boost logo

Boost :

From: Jesse Jones (jesjones_at_[hidden])
Date: 2000-12-16 17:52:29

>> From: Jesse Jones [mailto:jejones_at_[hidden]]
>> <snip>
>> It's true that most vendors
>> do a poor job of catching precondition violations, but there's no reason
>> for boost to go along with this.
>If they do a "poor job" of catching precondition violations, what is the
>alternate solution? Doing a "poor job" of generating efficient code?

Yes, in a debug build you'll normally be generating poor code: the
optimizer will be disabled (in most of the compilation units) so that the
debugger is useable and asserts will be sprinkled throughout the code.

>what point do we draw the line? I think the "Safe STL" provides iterators
>that will check the precondition of operator*; should we do the same?

We should check every precondition (and ideally postcondition) violation
that we can check in constant time.

>> I strongly support liberal usage of assertions in boost.
>assert() itself in many cases cannot be used, due to ODR (one definition
>rule) problems. I would be persuaded if we could find an assertion
>replacement that:
> 1) Has no overhead in release code
> 2) Avoids ODR problems
>You might want to read the "assert() replacement?" thread long, long, ago on

It's a good point, especially given how template heavy boost is. But
saying that we cannot use assert because someone *may* define NDEBUG
inconsistently sounds like a terrible idea to me. At some point you have
to make a trade off. If the vendors would do something as simple as
adding asserts to std::string and std::vector to catch range errors I
have no doubt that this would quickly save many man years of debugging
time. Of course this may cause problems for a few because of the ODR, but
I think the balance very much tilts in favor of using asserts.

  -- Jesse

Boost list run by bdawes at, gregod at, cpdaniel at, john at