Re: [boost] Boost regression notification (2005-10-06 [RC_1_33_0])

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.)

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