Re: [boost] _SECURE_SCL for msvc

Subject: Re: [boost] _SECURE_SCL for msvc
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2009-02-13 17:42:22

On Fri, Feb 13, 2009 at 3:32 PM, OvermindDL1 <overminddl1_at_[hidden]> wrote:
> On Thu, Feb 12, 2009 at 3:07 AM, Thorsten Ottosen <nesotto_at_[hidden]> wrote:
>> Hansi skrev:
>>>
>>> Hello,
>>>
>>> the problem with _SECURE_SCL define was already discussed a few times on
>>>  this list. But til now it came never to a end.
>>> Is there any interrest to get also compiled libraries for _SECURE_SCL
>>> enabled and _SECURE_SCL disabled?
>>
>> Yes. I define
>>
>> import feature ;
>>
>> #
>> # Composite feaure that ensures <define> can propagate
>> # to all dependencies, not just sub-projects.
>> #
>>
>> feature.feature secure-stl : on off : propagated composite optional ;
>> feature.compose <secure-stl>off : <define>_SECURE_SCL=0
>>                                  <define>_CRT_SECURE_NO_DEPRECATE=1
>>                                  <define>_SCL_SECURE_NO_DEPRECATE=1
>>                                  <define>_CRT_NONSTDC_NO_DEPRECATE=1 ;
>>
>> And then add
>>
>>         <secure-stl>off
>>
>> to the requirements.
>>
>>
>> I am in favor of libraries being named differently, eg. with "_nsc" suffix.
>
> Oh please yes.  I always compile boost with secure_scl and a few
> others things disabled (or some of my programs take exponentially
> longer to run).  Having name-mangled libraries for having those
> enabled or disabled would be perfect.
>

For note, here is the full build line I use:
..\bjam --build-type=complete --toolset=msvc-8.0 --without-mpi
--prefix=R:/SDKs/boost/built_head --build-dir=R:/SDKs/boost/build_head
define=_CRT_NONSTDC_NO_DEPRECATE define=_CRT_SECURE_NO_DEPRECATE
define=_SECURE_SCL=0 define=_SCL_SECURE_NO_DEPRECATE
define=_HAS_ITERATOR_DEBUGGING=0 install>..\build-HEAD.log

That _HAS_ITERATOR_DEBUGGING is also another really nasty one
(_secure_scl may also disable it, but better safe then sorry, it bit
me in the rear and cost me a couple of days when I first encountered
the massive slowdowns it causes at times), causes the debug builds of
some of my programs to be over 1500 times (yes, 1500 times, not 1500
percentage) slower then the debug builds with
_HAS_ITERATOR_DEBUGGING=0 set in certain areas, that is just way too
much of a speed hit to allow for any real debugging.