1
General / VisualStudio and STL debug settings
« on: February 24, 2012, 10:42:19 am »
While trying to install and integrate Assimp with SFML, I stumbled upon this post concerning STL in recent Microsoft compilers and that the debug checks are apparently also active in release mode:
http://assimp.sourceforge.net/lib_html/install.html
And here is some information from Microsoft about this:
http://connect.microsoft.com/VisualStudio/feedback/details/524141/serious-bug-when-using-secure-scl-0-c
Question: does this affect SFML in any way? I suspect if I link the standard ASSIMP library (which was compiled with both flags set to 0), it will crash with the SFML libraries as they were compiled with these flags set to their default settings of 1. Anyone already has experience with this?
http://assimp.sourceforge.net/lib_html/install.html
Quote
In VC8 and VC9 Microsoft has introduced some STL debugging features. A good example are improved iterator checks and various useful debug checks. Actually they are really helpful for debugging, but they're extremely slow. They're so extremely slow that they can make the STL up to 100 times slower (imagine a std::vector<T>::operator[] performing 3 or 4 single checks! scary ...).
These security enhancements are - thanks MS! - also active in release builds, rendering ASSIMP several times slower. However, it is possible to disable them by defining
_HAS_ITERATOR_DEBUGGING=0
_SECURE_SCL=0
in the preprocessor options (or alternatively in the source code, just before the STL is included for the first time).
If you're linking statically against ASSIMP: Make sure your applications uses the same STl settings! If you do not, there are two binary incompatible STL versions mangled together and you'll crash.
And here is some information from Microsoft about this:
http://connect.microsoft.com/VisualStudio/feedback/details/524141/serious-bug-when-using-secure-scl-0-c
Quote
When changing _SECURE_SCL from its default setting, certain rules need to be followed. These rules are logical consequences of the fact that _SECURE_SCL changes the representations (including the sizes) of STL objects.
The first rule is that _SECURE_SCL must be consistently set throughout each translation unit (a translation unit is a source file and all of its included header files, which is compiled into an object file). That is, _SECURE_SCL can't be changed in the middle of a translation unit. The easiest way to follow this rule is by defining _SECURE_SCL on the command line (or in your project settings) instead of in source files/header files. (This rule is being followed by your case; I mention it for completeness.)
The second rule is that _SECURE_SCL must be consistently set in all of the object files that are linked into a single binary (EXE or DLL). Mismatch will be not detected by the VC8/VC9 linker, and will cause incomprehensible crashes. (In technical terms, _SECURE_SCL mismatch is a One Definition Rule violation.)
The second rule applies to static libraries (which are simply packages of object files).
Question: does this affect SFML in any way? I suspect if I link the standard ASSIMP library (which was compiled with both flags set to 0), it will crash with the SFML libraries as they were compiled with these flags set to their default settings of 1. Anyone already has experience with this?