Boost and Microsoft's _SECURE_SCL Long story short of this post: Are there any plans (left) to add additional name mangling to the boost libs on Windows to address the problem of mismatched _SECURE_SCL setting? The Microsoft (Dinkumware) _SECURE_SCL=1 macro [1],[2] adds additional checks to standard library iterators/containers, rendering them ABI incompatible with _SECURE_SCL setting 0 vs. 1. This in turn leads to crashes when using a wrong combination of this flag. For example: [3] This has been discussed numerous times before: [4], [5], [6] -- see [5] for a list of further links to more threads. A trac issue [7] to add a specific build option has been closed as invalid. What I have been unable to determine is what the status is on supporting an additional *name mangling scheme* for the _SECURE_SCL option. From what I can discern from the current Getting Started page [8], not only do we not support any such name mangling, but the _SECURE_SCL macro (or the new _ITERATOR_DEBUG_LEVEL macro in VS2010) is not even mentioned on the Getting Started page. Since Visual Studio 2005 defaulted to _SECURE_SCL=1 and boost just uses the default, many people hit this when they used _SECURE_SCL=0 to improve performance in their release builds. (Which, as an aside, doesn't yield too much, as the real showstopper is the - independent! - _HAS_ITERATOR_DEBUGGING macro and that is only active in debug builds anyway.) In Visual Studio 2010, the situation is reversed, as Microsoft decided to now default to _SECURE_SCL=0. That means the people who change it to 1 in their release build for additional security will be bitten by the problem. (Or not, as it seems that they added some link-time checks in VS2010 to detect mismatches regarding the _ITERATOR_DEBUG_LEVEL. [9]) OK, so now again: Are there any plans (left) to add additional name mangling to the boost libs on Windows to address the problem of mismatched _SECURE_SCL setting? -- Or are we just going to ignore the issue since VS2010 defaults to the "boost preferred" - off - option now anyway? By "boost preferred" I mean that from some of the discussions it seemed to me that there was doubts w/rgd to complexity issues etc. when _SECURE_SCL is on. cheers, Martin p.s.: FWIW, here's how /I/ compile my release version of boost 1.44 on VS2005: bjam.exe --build-type=complete variant=release toolset=msvc-8.0 threading=multi define=_SECURE_SCL=0 --with-regex --with-program_options --with-test --with-serialization stage [1] Visual Studio 2005 - _SECURE_SCL : http://msdn.microsoft.com/en-us/library/aa985896%28VS.80%29.aspx [2] Visual Studio 2010 - _SECURE SCL : http://msdn.microsoft.com/en-us/library/aa985896%28v=VS.100%29.aspx [3] access violation with _SECURE_SCL turned off : http://lists.boost.org/boost-users/2009/02/45137.php [4] _SECURE_SCL for msvc (2009) : http://thread.gmane.org/gmane.comp.lib.boost.devel/185898/focus=185987 [5] MSVC _SECURE_SCL causes ABI change, ODR violation - mangle library names? : http://lists.boost.org/boost-users/2008/10/41253.php [6] Re: Bug/Incompatibility: Visual C++ 2005 checkediteratorslead to major crashes : http://thread.gmane.org/gmane.comp.lib.boost.devel/144082/focus=144089 [7] Add build option to define _secure_scl=0 + add runtime check to ensure no ODR violation : https://svn.boost.org/trac/boost/ticket/2086 [8] Boost 1.44 Getting Started on Windows : http://www.boost.org/doc/libs/1_44_0/more/getting_started/windows.html [9] Visual STuduio 2010 - detect_mismatch : http://msdn.microsoft.com/en-us/library/ee956429.aspx