Yes, Microsoft really screwed up on their compiler this way. Look at the CRT, you cannot even link modules that use different CRTs, but you can link (and they *will* horribly crash) modules with different _SECURE_SCL definitions as the linker is not aware of it.
I am just always in this habit of always adding this to my preprocessor definitions in any project I create or download, might be useful for everyone here to keep your code more like C++ and not Microsoft variation of it, not to mention the programs are *always* faster with these defined (just add them to the end of your current preprocessor definitions):
If you use and of the compiled libraries in boost, just add this to your bjam command-line:
define=_CRT_NONSTDC_NO_DEPRECATE define=_CRT_SECURE_NO_DEPRECATE define=_SECURE_SCL=0 define=_SCL_SECURE_NO_DEPRECATE define=_HAS_ITERATOR_DEBUGGING=0
So on and so forth, quite useful, just make sure that *everything* you build that uses the STL library is compiled with these (C apps, apps that do not use the STL, etc..., do not need it, but good to add it nonetheless).
And no, it is not anywhere near 1000x normally, just my parser uses a lot of iterators that should normally compile mostly out, but the freaking compiler adds in all that crap and does not remove it when it optimizes out the iterators, so I practically had half the parser source code just being calls to the range bounds checking function, really really retarded. I still wish the person who decided to add that (and make it default on for some god forsaken reason) would get flogged for a year straight, I lost so much time/sanity because of him/them, now I have to edit every freaking project I create or download to add the above line in every projects configuration file just to keep some sanity in speed in some of my code.
Yes, if you cannot tell, I am still highly irritated by their stupidity of a decision. If I wanted bounds checking, I would use Java or .NET or something, not C++...
EDIT: If you want to know how the ABI changes, with _SECURE_SCL=0 an iterator size is 4 bytes (8 on 64-bit), a single pointer. With _SECURE_SCL=1 it is double that, so 8 bytes (16 on 64-bit) because it keeps a pointer to its parent container, thus that changes the storage sizes of everything that uses them, hence why you cannot link in code using different _SECURE_SCL settings, and the real kicker, the linker DOES NOT CATCH IT.
It does other things too, if it is _SECURE_SCL=1 it dereferences the pointer to the parent object, gets its beginning and end, and compares the current iterator position to those to make sure it is bounded within, this does not break the linking though, this would work fine if you could choose it on a per file or per usage basis (whoever decided to force normal stl containers to use that style is a retard, if they wanted it they should have made new-named secure versions in their stdext namespace, like they do other things). But yes, it is the fact they are different sizes with different settings, and as stated, the linker does not catch it, really screws things up. As stated, the people who decided to implement that need to be flogged for a long extended period (there were some programmers on the team who were vocally opposed to it, too bad they were not loud enough...). It is reasons like this which is why I stayed with VC7.1 for so long, and still would have of except a certain library I require requires a more standards conforming compiler then VC7.1 was (and VC8.0 supported, too bad it breaks other things...).