Re: [Boost-users] vc 8 secure stl/runtime and boost

From: Delfin Rojas (drojas_at_[hidden])
Date: 2005-12-15 13:08:35

> >As far as _HAS_ITERATOR_DEBUGGING, which is also 1 by default, turns on
> some
> >extra checks inside STL _in debug mode only_. These checks are pretty
> heavy,
> 
> yes, and they've already found at least one bug in a boost library.
> 

I'm glad to hear the extra checks are useful. 

> >to the point of changing the complexity of STL algorithms. For example,
> >std::lower_bound(it_begin, it_end, val, pred) will execute
> pred(it_current,
> >val) when appropriate. If _HAS_ITERATOR_DEBUGGING is 1, MSFT calls pred
> >_twice_, once like pred(it_current, val) and once like (val, it_current).
> >This, besides slowing down lower_bound, prohibits the use of a predicate
> >that takes different argument types.
> 
> I don't see how this changes the complexity  n pred calls or 2n pred
> calls <shrug>
> 

You are right that this example does not show any complexity change.
However, calling the predicate twice may produce a noticeable speed change
depending on the number of iterations and the specific actions carried out
by the predicate. There may not be any boost libraries where this is
applicable, or there may be.

As far as the complexity of algorithms changing because of the extra checks,
my information may be outdated. This specific issue seems to have been
resolved in the final version of VS 2005.

> 
> as for documenting possible debug features in different
> compilers?  have at it.  write 'em up.
> 

I don't think it is Boost's responsibility to document debug features in
different compilers. However, considering boost already advices users to
declare _SCL_SECURE_NO_DEPRECATE to avoid warnings when compiling boost with
vc-8, I think it may be appropriate to mention things like
_HAS_ITERATOR_DEBUGGING.

Besides the speed penalty that may or may not occur inside some debug-mode
boost library, there are compilation errors that a user may get when
combining STL algorithms with, say, boost::bind or boost::lambda. For
example, in the case I mentioned above with std::lower_bound predicate being
called twice, if the lambda functor being formed takes arguments of two
different types, there will be a compilation error. Of course this error is
not related to boost::lambda, but the compiler error trace would point to
it, which may confuse a lot of people. 

Again, I just think it may be nice for boost to mention something like this
to its users, but that is a decision for boost developers to make.

-delfin