Question

We are considering moving the win32 build of our cross-platform C++ application from MS Visual Studio 2003 to MS Visual Studio 2005. (Yes, very forward-looking of us 😉

Should we expect to many code changes to get it compiling and working?

Answer 1

I’ve just migrated a comparatively large codebase from VS2003 to VS2008 via VS2005 and the majority of issues I found were const/non-const issues like assigning the return value of a function that returns a const char * to char *. Both VS2005 and VS2008 are a lot more picky when it comes to const correctness and if your existing codebase is a bit sloppy, sorry, old school when it comes to const correctness, you’ll see plenty of this.

A very welcome change was that the template support in VS2005 is noticeably better than it is in VS2003 (itself a big improvement on earlier versions), which enabled me to throw out several workarounds for template related issues that the team had been dragging around since the heady days of VC++ 4.x.

One issue that you are likely to encounter are tons of warnings about ‘deprecated’ or ‘insecure’ functions, especially if you are using the C string functions. A lot of these are ‘deprecated by Microsoft’ (only that they left out the ‘by Microsoft’ part) and are still perfectly usable, but are known potential sources for buffer overflows. In the projects I converted, I set the preprocessor define _CRT_SECURE_NO_WARNINGS and disabled the warning C4996 to turn off these somewhat annoying messages.

Another issue that we came across is that MS has changed the default size of time_t either in VS2005 or in VS2008 (I apologise but I can’t remember – it’s definitely in VS2008 but it may already be in VS2005) so if you have to link with legacy libraries that use time_t in the interface, you’ll have to use _USE_32BIT_TIME_T to revert to the older compiler’s behaviour.

If your solution contains several projects, you may find that the parallel build feature (which is turned on by default) will highlight missing build dependencies. so projects are suddenly built in the wrong order but magically build correctly if you revert from parallel build back to linear build.

Overall I do prefer VS2005/8 to VS2003, and I would recommend to upgrade to VS2008 if that is an option, as the compiler is ‘better’ than VS2005 – MS seems to have made a massive effort in improving the native C++ compiler. Part of that was already noticeable in 2005 so you’ll get at least some of the benefit even if you stick to 2005.