Up to the present, I have been using Visual C++ 6.0 for a collection C++ source code that dates back to 1998. There is really no pressing need to update to a new version of Visual Studio, though I do have a company license for the current version. Still, there might come a time where compatibility with other projects, or newer versions of Windows, might become an issue - so there is some (weak) motivation to update.

A couple years ago I had a bit of spare time, and tried loading the C++ workspace into Visual Studio 2003. Got hundreds of warning messages - all of which I had time to look at, turned out to be meaningless (as in fixing would offer no benefit). Generally speaking I tend to be a bit pedantic, and always use the compiler’s highest practical warning levels - “Level 3” with “Warnings as errors” in VC6, and “-Wall” when compiled with g++ (the code is portable). The code is littered with ASSERT() calls, pounded by unit tests before each release, and has lots of mileage in customer use. So on seeing so many compiler warnings … I was a bit skeptical.

By a bit pedantic - years ago working on Unix, I would regularly run my code through the Greenhills C compiler at the highest warning level (the production compiler), the GNU C compiler with “-Wall”, and lint … and not find anything amiss. I have some reason to suspect the compiler warnings coming from VS might be bogus.

I gave up on VS2003, as I did not have time to wade through all the false positives, and could not justify requiring the remainder of our workgroup to do the same.

To take another run at things, created a virgin Windows 2000 VM (using VMware), loaded VS2005, and installed all updates. At first, nothing would compile - lots of D9028 and C1902 errors. Turns out I had sized the VM to meet the recommended minimum requirements for VS2005, and that will not work. After upping the VM to 512MB, the D9028 and C1902 errors went away. Looks like Microsoft needs to update their minimum requirements. :)

Next up is a deprecation warning for using fopen() - seems that Microsoft thinks the function is unsafe, since it returns a null. Turns out Microsoft has chosen to “deprecate” a whole bunch of standard portable functions, for which they recommend non-portable Microsoft-specific replacements. Right.

In this case they suggest you use the non-standard fopen_s(). Right.

FILE* f = fopen();
if (!f) {
    // handle failed open
}

This is unsafe, how? If the programmer is not checking return values, you are screwed with either fopen() or fopen_s(). In fact, the notion that you can turn C/C++ into a “safe” language is dubious. I have seen a lot of quite horrible C/C++ code, and small tweaks just are not going to solve the problem.

Waded through and eliminated the compile errors - mostly by disabling warning 4996 and altering scope of for-loop variables. Still failing the regression tests. Something to look at later.

Clearly Visual Studio 2005 is an improvement over Visual C++ 6. If I had not spent considerable time with Eclipse, I might be impressed. At least so far, there is nothing compelling. I am tempted to stick with VC6. :)