Migrating from MSVC 6.0 to Studio 2005?

greywar asks: "While the preferred method would be simply use Linux, unfortunately my company is using Microsoft Visual Studio 6.0 with C++. I have been asked to recomend if we should upgrade to the new upcoming visual studio 2005. Has anyone got any real life experience with moving a project of about 220,000 lines of code, 60,000 lines of comments from the old MSVC to the new Studio 2005 which is currently in Beta? What benefits are there, and what things do we lose? What problems will occur?"

Comments

Migration Problems

[megaversal]

I've had lots of various problems with small projects. What I've learned to do is port a few things at a time, especially if you have a lot of libraries and other things, you can try porting over a library and fix that up to keep running with other VS6.0 stuff while you slowly move it all over.

Of course the fun one would be download the trial beta and take a copy of all the code, build it, and see how many errors you get (hint: it will probably be a lot).

Re:Very poor

[Keith Russell]

The problem is one of lockin. MS depricated ALL of the C standard library. Every strlen() is now a compile error. Best of all the only documented way to enable the old functionality (some obscure #pragma) was broken.

Are you sure that wasn't just early-beta cruft? Microsoft has been making a push for C and C++ standards compliance with VS2k3 and 2k5. And if functions like strlen() are failing, I doubt Microsoft would be able to use the compiler as dogfood.

If it ain't broke...

[N7DR]

I have a project that's about 1/3 the size of yours, with VC++ 6.0 as the development environment.

Out of interest I purchased VC++.NET 2003 a while ago.

Once I fired it up and tinkered a bit with the IDE, all thought of porting the project went away. Things look quite different (and, at least in my case, the help that came in the package was a big fat zero). I eventually worked out how to build a small test project and have it run. But to take a complex pre-existing project looked like a job that one would take on only if one absolutely needed something that was only available in 2003 .NET. (In fact, my first reaction on seeing the IDE was: Good Grief! Why does everything nowadays have to be so complicated? I had hoped for a reaction along the lines of: Oh good! This looks like something I'm used to. But it was Not To Be.)

Now, rumour has it that the 2005 .NET compiler is going to have lots of support for fancy stuff like template metaprogramming. So I can see using it for new projects if the new stuff is going to be useful in those projects. But as for porting an old project, I have to assume that 2005 is going to be at least as far removed from 6.0 as 2003 .NET was. And since you already have the project building and working under 6.0, I would not recommend the switch.

Maybe if you have the capability and version control resources to keep using 6.0 as your mainline code while you tinker to get 2005 .NET working, then that might be reasonable. But unless you have spare people/time, I honestly don't think it would be wise to try to make the switch

Why bother?

[DavidYaw]

The question to ask is, why upgrade at all? Is there something wrong with MSVC 6? Does it all of the sudden not work?

If the only reason to upgrade is because some not-too-informed person (be it PHB or novice programmer) wants to be running the latest-and-greatest, then don't.

Re:Why bother?

[cookd]

VC 6 was released in 98. Do you develop apps for the latest version of Linux with GCC 2.8 (VC 6's contemporary) and GLibC 2.0.7? If you're targeting older platforms (Windows 98), I could see why you might want to stick with VC 6. But otherwise, use the best tool for the job.

Since VC was released, there have been 7 years of bug fixes and improvements to the compiler. Lots of new optimizations, warnings, and security features. Not all of them are trivial. And the runtime has had a lot of work -- much closer to the C++ spec.

Finally, VC 6.0 is no longer supported by Microsoft. No bug fixes, patches, security checks, etc. The 6.0 CRT might still get updated, but the compiler won't.

The longer you wait before upgrading, the harder it is to upgrade. It may actually take less time total to do it less often, but the process is much smoother and causes fewer problems if you keep up to date.

Why are you upgrading?

[Geoffreyerffoeg]

What benefits are there, and what things do we lose? What problems will occur?"

If you're looking mainly at upgrading the compiler, you can download the command-line compilers for free and you can see if it compiles well or not, or if language features you wanted to use are there. These are both the .NET compilers (CSC, VBC, etc.) and the regular compilers (CL, etc.). CL compiles both normal C++ (I've used it on the same code I gave to g++) and Managed (Embraces and) Extensions for C++.

Otherwise you're looking at upgrading the IDE, which is motivated by how much your programmers like or dislike the 6.0 IDE. And if you buy 2005, you're probably going to be upgrading both, so you need to make sure that both will work better (or one better, one as well) as those in 6.0.

Re:Sloppy Programming will cause issues

[Rufus88]

So what do you do?
1. Use a different variable name for each loop. [...]
2. Do exactly what you describe, and reuse i over and over even though it's incorrect.

And what, pray tell, is wrong with doing it the valid, old-fashioned way? I.e.:

int i;
for (i=0; i<MAX_A; i++)
{
do_something(i);
}
for (i=0; i<MAX_B; i++)
{
do_something_else(i);
}

Re:Sloppy Programming will cause issues

[Henry V .009]

That's great as long as things don't get complicated. Declaring i in the outer scope like that is a temptation to use it in that outer scope. (Like not declaring things const.) For example, what if you have this:

int i;
for (i=0; i<MAX_A; i++)
{
do_something(i);
if (condition) break;
}
...
if (i==...) {...}

No problem, right? But say a year later, you come along and find that you need to modify your code to something like this:

int i;
for (i=0; i<MAX_A; i++)
{
do_something(i);
if (condition) break;
}
...
for (i=0; i<MAX_B; i++)
{
do_something_else(i);
}
...
if (i==...) {...}

Oops!