Transition from VS 6 to VS 2010

Question

I've finally made the leap from Visual Studio 6 (1998 vintage) to VS 2010. It's been painful, but after eight hours of work, my 200KLOC Win32 program actually runs!

I'm disappointed by how sloppy VS converts projects.

[1] VS ignores the pre-compiled target if it's not "stdafx.cpp"

[2] In a Project with multiple Configurations, VS forgets about which modules are not included in certain Configs, and includes everything everywhere. That means every module that needs to be excluded has to be re-identified.

[3] If some modules don't use pre-compiled headers, VS loses this distinction and assigns pre-compiled headers to everybody.

[4] Some modules' properties are mysteriously unchangeable. The module has to be deleted, then re-added again.

[5] Many strange error messages that don't make sense and disappear unexplainably.

Has anyone encountered any other surprises?

Does Multi-core compile make a big difference? On my Intel i5 3.2GHz 4GB 64-bit PC with 4 core, the compilation of 200K lines is 58 sec. without Multi-core, and 47 sec. with.

Still, I shouldn't complain. The compile used to take 40 min. on a 33 MHz 486.

Answer 1

Visual C++ 6.0 is no longer supported, so if I were you would be relieved this worked at all.

The main issue I hit in going from VC6 to VC7.1/VC8 - STL support in VC6 is out of date vis a vis the current standard, resulting sometimes in uncompilable code such as: auto_ptrs are no longer allowed inside STL containers; <locale> code often different.

Don't ignore warnings (your point 5 maybe?) when you build this in VS2010, and run your VS2010 builds with /W4. Addressing warnings now could save you hours of debugging.

Multicore compile in post VS2005 releases will compile non-dependent projects in parallel, so yes this could make your stuff build a lot faster.

The good news is that when the dust settles, you will be so grateful you moved. It's a way more productive IDE and language in VS2010/VC10.

Answer 2

Multicore compile does make things quite a bit faster when you have multiple non-dependent projects. The downside is that outputs of different compilations are intermixed with each other (at least in 2005, not sure about 2010), and that makes tracking down errors a bit painful. One project fails to compile and aborts, others still go on, and the final messages from the one that aborted are not eeven next to each other - they spread halfway across the log. You have to make use of the text search function in the output window.

One other thing that annoyed me to no end (again, in 2005), was that they had a bug in their macro code and you couldn't use commas in recorded macros. As far as I know, it's still not fixed.