Neither is defined in any way AFAIK. They aren't even present in Boost.Build. There also not present in Boost.Config, so I would think they aren't touched in any way by Boost code.

...Not that I know what those do, I just know how to do a text search ;-)

Thanks for checking. FYI, _SECURE_SCL, which is 1 by default, turns on the "secure" version of the C/C++ libraries. This version, among other things, includes extra checks in some functions. MSFT claims these checks should not slow down functions but I wanted to know if somebody had noticed a slowdown in boost libraries compiled with this option. 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, 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. Anyway, I think something like this could be in the boost docs, so that users compiling boost libraries in debug mode define it, or at least know of the possible effects. Opinions? Thanks Delfin Rojas

...

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