On Sat, Dec 20, 2008 at 1:02 PM, Anteru <newsgroups@catchall.shelter13.net> 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...).