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 not explicit macro being defined) for each supported compiler in order to work correctly in any build environment. However, do not quite understand how this affects what default feature value choice we make in Boost Build. Which ever choice we make (on, off or compiler default), we will need to encode the on/off decision in the library's name. We will also need to 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.
Hmm... are you sure about this? I have not checked any header files but states:
To enable iterator debugging in debug builds, set _HAS_ITERATOR_DEBUGGING to 1 To disable iterator debugging in debug builds, set _HAS_ITERATOR_DEBUGGING to 0
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ć