[Bah, the original message went out too soon... here's a finished one. I apologize or the noise.] Hi Peter.
Feature: <checked-iterators> 'on' --> _SECURE_SCL=1 'off' (default) --> _SECURE_SCL=0
I believe that the default should match the VC default, which is 1.
This has no performance implications. Whether _SECURE_SCL is 0 or 1 in a particular project is decided by the user, not us. The autolink code will check the macro value and attempt to link to the appropriate Boost library. What is _built_ by default should match what is _used_ by default; it doesn't matter which one is faster, the choice is not ours to make.
I fail to see how the auto-link code takes things out of our hands. Of course, auto-link code will need to be aware of the default settings (i.e. those with no explicit macro being defined) for each supported compiler in order to work correctly in any build environment. However, I do not quite understand how this affects what default feature value choice we can make in Boost Build. The auto-link code should then fine based on the preprocessor constants we set, no matter which choice we considered to be 'the default one' in Boost Build. Which ever choice we end up making (on, off or compiler default), we will need to encode the on/off decision in the library's name and set the corresponding preprocessor constants during compilation.
Name mangling: <checked-iterators> adds 'c' to library name if enabled (assuming it's applicable).
Feature: <debugging-iterators> 'on' --> _HAS_ITERATOR_DEBUGGING defined 'off' (default) --> _HAS_ITERATOR_DEBUGGING not defined
Not defined means "on" in debug builds, "off" in release builds. Defined to 0 means off. Defined to 1 means "on" in debug builds, "off", warning and redefintion back to 0 in release builds.
Thanks. Nice catch. I'll integrate this into the next design summary post. For those interested - the relevant header file distributed with MSVC is yyval.h. The official documentation on the other hand does not mention this 'default' behaviour (e.g. see http://msdn.microsoft.com/en-us/library/aa985939.aspx). Thanks for the feedback. Best regards, Jurko Gospodnetić