Re: [boost] [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

Subject: Re: [boost] [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.
From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-09-04 14:42:16

[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ć