VisualStudio and STL debug settings

[tobybear]

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

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

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?

[Laurent]

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

Yes of course, any flag mismatch may cause undefined behaviour in the final application. You must recompile SFML with the exact same flags.

[tobybear]

Ok, thanks!
I probably adapt my makefiles then, setting these flags to 0 in both debug and release mode, in order to use ASSIMP.

[Order]

I realize this is an older topic, but I'm having an issue with Assimp + SFML and I believe it could be some of this "undefined behavior" you mentioned earlier.

I've dynamically linked all my libraries like Assimp, SFML, OpenGL, DevIL, OGL_SDK etc. I've been running code fine for a while now using my previous property files - but now that I've included Assimp its doing some strange things.

For one its saying that most of the Assimp containers like the vectors/matrix's are not defined or recognised types. This is strange as I can instantiate a new Assimp Importer, create various meshes and scenes etc.

I've rebuilt the libraries multiple times, downloaded different versions of snapshots of assimp - tried various methods of dynamically linking and a few different combinations of preprocessor commands.

Has anyone encountered anything similar with the library - I'm wondering if it could be to do with some of these flag number conflicts you guys mention?

Any new vector or info would be greatly appreciated!

[Laurent]

If it happens with Assimp, why don't you try to ask directly on their own forum? There may be something specific to the library that we don't know.

[Order]

Cool. Thanks for the prompt reply. I'll give their forum a go. I thought I'd try here first as it seems that this forum is very regularly updated - and because I just wanted to check if their were any known conflicts with SFML + Assimp etc.

Thx