Re: [boost] [boost.build] should we not define _SECURE_SCL=0 by default for all msvc toolsets

Subject: Re: [boost] [boost.build] should we not define _SECURE_SCL=0 by default for all msvc toolsets
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2008-12-21 05:19:53

On Sat, Dec 20, 2008 at 1:02 PM, Anteru
<newsgroups_at_[hidden]> wrote:
> OvermindDL1 schrieb:
>> I compile everything I ever get that even touches the STL with the
>> above defines, else nice crashes abound.
>>
>> But for an example, a parser I made with Boost.Spirit took 5 minutes
>> without the above defines, took 5 second with them (times are pretty
>> accurate, it was a massive difference), that is how utterly crappy the
>> STL implementation is in VS2k5 and higher without those.
>
> You should try and send that exactly as is to the microsoft guys, as
> they are playing with the idea of disabling the _SECURE_SCL stuff in
> release builds by default.
>
> The more reasons they get for doing so, the better.

Do you have a link to send me to for that?  I buy VS by itself, I do
not have an MSDN subscription (I do not even make that much spare
money a year), as such I do not often stay with the 'in' Microsoft
community, end up figuring most out by myself.  I actually compile
more for *nix, but all by coding takes place in Visual C++ and Visual
Assist until there is a 'nix IDE that is mostly-comparable.  Just this
issue was odd in that GCC *vastly* outperformed VS, when usually VS is
usually a 'little' bit faster then GCC in compiled code, had to look
in to it.

> ..\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

But yes, this bjam line is rather essential for a few of my projects.
I would love another build option that had this as an extra set as
right now I have two boost directories, one for normal builds, one for
the above (although I generally just use the above, as I have not made
addon libraries for other apps that use the STL externally
recently...).