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?
A:
No. I wouldn't expect more than a few.
Edit: you should/could try the code with a demo version of vs2005 first.
Burkhard
2008-11-13 09:51:10
+2
A:
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.
Lodle
2008-11-13 10:19:37
That warning is easy to disable by defining _CRT_SECURE_NO_WARNINGS
Enno
2008-11-13 10:23:35
But doesnt mean you should
Lodle
2008-11-14 01:16:52
Well, that's a philosophical question. What you *shouldn't* do is use MS-only functions that will mess with the portability of your code.
Enno
2008-11-14 09:02:44
thats where the preprocessor comes in. I use it to keep standard names but use the os functions for cross platform compiling
Lodle
2008-11-15 00:52:12
+5
A:
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.
Enno
2008-11-13 10:20:21
You are right, the most common work is related to the outside usage of a variable declared inside the for loop; VS 2005 fixed that and broke old code.
Jaywalker
2008-11-13 13:16:10
+1
A:
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.
James Curran
2008-11-13 13:07:03
Amazing, We are currently working on a project to move from VC6 with the warning level set to 3 to VC2008 with Warning Level 4. We have had to make many code changes; mostly minor but a few major ones as well, and the project is now in its second month!
John Dibling
2008-11-13 15:42:17
It was a rather small project (see for yourself @ http://codeplex.com/uptime), and I was trying to be careful about standard compliance even back then.
James Curran
2008-11-13 16:24:46
+5
A:
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.
Timo Geusch
2008-11-13 13:25:48
+4
A:
You should review MS's lists of breaking changes when deciding if & how to undertake this project.
Breaking Changes VC 2005 - 2008
John Dibling
2008-11-13 15:46:07
A:
Also, consder disabling checked iterators or the performance may suffer after porting to the new version.
Nemanja Trifunovic
2008-12-25 03:17:46
A:
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: for(i = 0; i < length; ++i) { }
when i is undefined prior to that point work fine in previous versions of VS, but in 2005 it correctly marks i as an undefined variable.
Tulenian
2008-12-25 03:31:19