Re: bounds checking in array.hpp

From: deansturtevant_at_[hidden]
Date: 2000-12-16 14:27:10

--- In boost_at_[hidden], scleary_at_j... wrote:
> > From: Jesse Jones [mailto:jejones_at_a...]
> 
> > <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?  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?
> 
> > 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
> 
> 	-Steve

Lacking a 'perfect' solution to the problem, one must be willing to 
make a trade-off. If one places high value on detecting programming 
bugs early on in the development process, assert() provides a time-
tested, simple solution. I know of no situation with current 
compilers where the subsequent ODR violation presents a problem. 
Indeed, if a compiler came out that actually had problems with assert
(), I claim that that compiler could not be successful, based on the 
widespread use of assert().
Another point -- boost is full of ODR violations! Any inline or 
template code that is conditioned on some compile-time variable 
violates the ODR, doesn't it?