Jonathan Wakely <cow@compsoc.man.ac.uk> 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.)
Right.
That doesn't mean the debug mode is wrong if it causes some Boost code to fail.
Right.
It doesn't mean you shouldn't try to make Boost correct w.r.t the debug mode.
Right.
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 www.boost-consulting.com