Re: [Boost-users] [program options] access violation with _SECURE_SCL turned off

Subject: Re: [Boost-users] [program options] access violation with _SECURE_SCL turned off
From: klaus triendl (klaus_at_[hidden])
Date: 2009-02-18 08:17:59

Peter Bartlett schrieb:
> Quoting klaus triendl <klaus_at_triendl.eu>:
>> Juergen Hunold schrieb:
>>> Of course, re-compile Boost in release mode with _SECURE_SCL=0.
>>> The developer list has two or three threads about a general solution,
>>> including different name mangling. Just search the archives...
>>
>> I didn't build boost myself, until now...
>> Thanks for your answer, that helped me a lot!
> 
> I naively built boost with a D_SECURE_SCL=0 on the bjam command line
> recently.
> It became the source of crashes even more confusing than those the
> original poster found. I believe, but never truly determined, that the
> define was being propagated to some but not all build targets.

Hmm, I've turned the macro off on the commandline with the bjam built-in
option: define=_SECURE_SCL=0

> If you are going down this route, I recommend you investigate the
> feature approach of Thorsten Ottosen :
> http://article.gmane.org/gmane.comp.lib.boost.devel/185987 . I
> understand it avoids these problems but haven't yet had time to confirm
> that myself.

_CRT_NONSTDC_NO_DEPRECATE doesn't have to do anything with the *ms
secure* functions but only deprecate posix named functions that have an
iso c++ named variant.
And as far as I understand from Stephan T Lavevej's blog (comment #2 at
http://blogs.msdn.com/vcblog/archive/2007/02/26/stl-destructor-of-bugs.aspx)
only _SECURE_SCL (and _HAS_ITERATOR_DEBUGGING) cause a different ABI.

Klaus