What code changes are required to migrate C++ from VS2003 to VS2005?

问题

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?

回答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.

回答2:

If your code is already quite clean and compiles without warning, it's not a big step.

Check this article and consider how big the impact of those changes would be on your existing code. Cleaning up for-loop conformance can be a bit of work.

You can get the free Express edition of Visual Studio 2005 here.

回答3:

You should review MS's lists of breaking changes when deciding if & how to undertake this project.

Breaking Changes VC 2005 - 2008

Breaking Changes in the Visual C++ 2005 Compiler

Breaking Changes in Visual C++ .NET 2003

回答4:

you will find alot of string commands will give you warnings as in vis 2005 they stepped up the security to try and stop buffer over runs.

your 2003 code will still compile though.

回答5:

I recently converted a 10-year old VC6 program to VS2008. It required no changes to the source code, and the only changes needed to the project files were handled by the upgrade wizard.

回答6:

No. I wouldn't expect more than a few.

Edit: you should/could try the code with a demo version of vs2005 first.

回答7:

Also, consder disabling checked iterators or the performance may suffer after porting to the new version.

回答8:

If your source code conforms to the C++ standard, you shouldn't need to change anything to move to 2005. You may get some depreciated warnings, but nothing that should give compile errors.

The main issue people have with going from older versions of VS to newer ones is that the newer versions are more standard conforming.

Things like: