Be careful when using _SECURE_SCL option when integrating your DLLs with DLLs you received from someone else. If you have compiled your dlls with this option but the dlls you use havent, you are most likely going to get a runtime application compatibility error. To fix this just remove this option.
When secure SCL is enabled, the sizes of the vectors and iterators change (since they contain additional data for runtime bounds checking). The data types also change between debug/release builds, so be extremely careful when mixing debug and release libs together!
This leads to some horrendous problems when using third party libs, mainly because as far as the compiler is concerned, vector is exactly the same type if built in debug/release, or with/without secure SCL. As soon as a container crosses a DLL boundary, it crashes spectacularly…..
The problem gets substantially worse when using DLL’s / Plug-in APIs, because the author of the DLL could have been linking to any implementation of the SCL containers, and you’d have absolutely no way of knowing which implementation or which flags were used in the build.
If you write any DLL that are shipped as a release build, it must not contain any SCL containers for this very reason. Typically VC++ will spit out a (Level4) C4251 warning whenever you use a std::vector in a DLL header. If you have any warnings of this sort in your DLL headers, you really need to sort the problem out pronto! (because it will cause random crashes of the sort you are seeing). There are a few ways to get around the problem, but they actually cause more problems than they solve (namely that a given std::vector template specialisation can have two or more definitions, which causes the linker to go a bit mental if you are no careful).
When used in the command line its used as :
-D_SECURE_SCL=1 -D_SECURE_SCL_THROWS=1
I have got this snippet from the microsoft website:
This is caused by _SECURE_SCL mismatch.
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).
The third rule is that _SECURE_SCL must be consistently set among binaries (EXEs/DLLs) that pass STL objects to each other. If a DLL has a C or COM interface, nobody can tell what _SECURE_SCL setting it was built with, but if the DLL uses STL objects in its interface, then the mismatch rule applies.
This means that when using Boost (either statically linked or dynamically linked), you must recompile it with _SECURE_SCL defined the same way as in your own code.
VC10’s linker has been enhanced to detect violations of the second rule (and of the third rule when import libs are used, according to my understanding – if a DLL is loaded through LoadLibrary() then there’s no way to detect mismatch).
Additionally, _SECURE_SCL defaults to 0 in release mode in VC10.