Boost logo

Boost :

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
> > 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
> that will check the precondition of operator*; should we do the
> > I strongly support liberal usage of assertions in boost.
> assert() itself in many cases cannot be used, due to ODR (one
> 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:
> -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?

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