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
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 www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk