Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-10-11 09:32:21

Jonathan Wakely <cow_at_[hidden]> writes:

> Libstdc++'s Debug Mode is not standard-conforming. Read the docs if you
> want clear proof:
> performance guarantees made by the normal library may not hold in the
> debug mode library. For instance, erasing an element in a std::list
> is a constant-time operation in [the] normal library, but in debug
> mode it is linear in the number of iterators that reference that
> particular list.

Well, I guess that's arguable, since it's still constant time in the
length of the list, which is (I think) all the standard guarantees ;)

Anyway, it's conforming functionally, just not efficiency-wise.

> The iterators and containers do not provide the complexity
> guarantees of the standard. So you'd be foolish to use it for
> "release builds" (unless we're talking some weird definition of
> release that isn't concerned with exponential increases in runtime.)


> That doesn't mean the debug mode is wrong if it causes some Boost
> code to fail.


> It doesn't mean you shouldn't try to make Boost correct w.r.t the
> debug mode.


> All I tried to suggest was the the debug mode failures might not be top
> priority.

That's where we part company. If your code is causing a failure in
debug mode, either the debug mode (or the compiler) has a bug, or your
code is invoking undefined behavior and will probably crash in the
field. That's a serious bug that needs to be fixed

Dave Abrahams
Boost Consulting

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