RE: [boost] bounds checking in array.hpp

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. 

>At
>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
>Boost:
>  http://www.egroups.com/message/boost/637

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