David Abrahams wrote:
Jonathan Wakely writes:
The debug mode cannot be used in "release mode" because it makes the stdlib non-conforming.
I'd like to see some pretty clear proof that libstdc++ is nonconforming in debug mode. As far as I'm concerned, the onus is on the developer whose code is triggering the assertions. I'd be overjoyed if libstdc++ were proven wrong, of course.
OK, we seem to be talking at cross-purposes here - and you've taken my quote out of context (but I'm still right ;-) Arkadiy hasn't clarified what he meant by release mode, but I assumed he meant something like "the compiler settings you'd use when building a release that you'll ship to customers." 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. Or ask Doug Gregor - he wrote that, I believe. 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. I'm happy to be wrong, if you can make Boost 1.33.1 work perfectly with the debug mode, then that's great. As for conformance / non-conformance, that arose out of a question from Arkadiy that I don't understand and he hasn't explained. The fact is it's non-conforming and should not be used for "release builds" - but I thought naming it "debug mode" made that obvious. jon