From: Jonathan Wakely (cow_at_[hidden])
Date: 2005-10-10 10:54:26
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
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
It doesn't mean you shouldn't try to make Boost correct w.r.t the debug
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk