1. Use another compiler such as GCC

It may or may not be possible to use an alternative compiler from within the Visual Studio IDE. I can’t find any references for it, but I have heard (though not tested) that it is possible to set up a project that uses a makefile to build.

Code::Blocks is probably the best alternative IDE to Visual Studio. They also provide a download package which includes MinGW.

Another advantage of switching compiler is that you avoid another issue of Visual Studio: you need to ensure that someone running your application has the Visual C++ Redistributable package installed. But that is another rant for another time.

2. Use another STL implementation such as STLPort

STLPort is an alternative STL implementation. Performance-wise, it should beat the Microsoft implementation, even after fixing that as described below.

3. Change the idiotic Visual Studio behaviour

There are a couple of obscure macros that you must define to disable the runtime safety checks which cause the agonising slowness:

#define _SECURE_SCL 0
#define _HAS_ITERATOR_DEBUGGING 0

You should set these in the project settings, under pre-processor definitions (and make sure to do it in both debug and release mode). Don’t ever do it from a header file unless you’re certain that file will always be included first. So the new set of definitions should look something like this:

The reason those warnings talk about runtime errors is because of the catch related to this solution:

If you link with another object/library with those macros defined differently (i.e. the default), you may get runtime errors. The gorey details as descibed in this comment are as follows:

These are the rules that you must follow when modifying _SECURE_SCL and _HAS_ITERATOR_DEBUGGING:

They must be consistently defined within each translation unit (i.e. a source file and all of the header files that it includes). For example, you can’t include a Standard header, alter _SECURE_SCL or _HAS_ITERATOR_DEBUGGING, and include another Standard header.

Translation units that are linked into the same binary (executable or DLL) must have identical definitions of _SECURE_SCL and _HAS_ITERATOR_DEBUGGING. For example, linking one .obj with _SECURE_SCL==0 to another .obj with _SECURE_SCL==1 into an .exe or .dll is bad. For another example, linking several .obj files with _SECURE_SCL==0 into a .lib, and then linking an .obj with _SECURE_SCL==1 against that .lib into an .exe or .dll is bad.

Binaries that pass STL objects between each other must have identical definitions of _SECURE_SCL and _HAS_ITERATOR_DEBUGGING. (They must also be both retail or both debug.)

My (not necessarily 100% accurate) summary of those rules:

You must have the same settings across your entire project and in any libraries you statically link to. Dynamically linked libraries should be fine unless they use STL containers in their public API.

The error message you get if these rules are broken will be beautifully unhelpful and even misleading: so be on your toes.

2 comments by 0 or more people

Sue

How absolutely amazing! (I’m not your mother!)

07 Feb 2010, 00:56

Sue

I was quite disappointed when I showed this to my partner and he wasn’t very impressed. He said he couldn’t see that it is a collider at all. Before I showed him the film I’d asked him what a polygon collider was and he thought it must be something to do with the configuration but he couldn’t see how that name was come by at all afterwards. Were you the person who sat next to my daughter in one of the lectures and admired the kangaroo on her pencil case? This episode has always stuck in my memory as it was the only tit-bit of information she ever gave me about what went on in any lecture.

07 Feb 2010, 20:55

Add a comment

You are not allowed to comment on this entry as it has restricted commenting permissions.

New blog location

After a hiatus of several years, I’ve started blogging again at blog.draknek.org.