Visual C++ 8

I'm not interested in any of the honeypots Microsoft have put in Visual Studio to try and trap me into using supplier dependent material. I want a career even if Microsoft start making serious mistakes, so I will not specialise in manufacturer dependent products more than I have to. This means the only language that's worth me considering in Visual Studio is Visual C++. Fortunately, this compiler is a very good product indeed.

The compiler has significantly improved conformance, so that, for example, loop variables are correctly scoped (at long last!). It has a new annoying warning that is actually an excellent idea; if you use standard C functions that potentially risk buffer overflows, it tells you off. Mysteriously, the recommended solution is to use the Windows API, but if you filch, say, the relevant portions of the C library from Open BSD, you end up with more secure, more portable code, from a source with a strongly secure reputation.

The VC8 GUI is usable. It does presume you've a big screen, which is a nuisance if you're use a cheap laptop, like me. Despite this, it's generally nice to use, and is an improvement on its predecessors.

However, the VC8 GUI retains many of the flaws of its predecessors. My three main gripes remain the inability of the property pane to show its content (unlike VC6); the presumption that anyone who wants to add event functions has the short term memory of a goldfish, or no concept of architecture, or both (so you have to click about twenty times between each function added before you can add the next one); and the strange omission of the full path from file properties in solution explorer so if you've opened a project containing two files with the same name on different paths, you've no obvious way of identifying which file is actually open (unavoidable when you're looking at someone else's project). I fear the GUI gets confused here. For example, I've got some code with an type error in a class that the GUI assures me is commented out: it's obviously opened the wrong file.

The VC8 help system's search functionality remains useless. I think this flaw is simply a consequence of the quantity of information Microsoft supply; there's too much for their help system to search effectively. Fortunately, Microsoft have put this information on the web, so you can use google to look things up. Google tends to return results relevant to your query.

Another VC7 flaw in the help system that hasn't been resolved is the context index functionality. It still responds to F1 by bringing up a random page, rather than encouraging you to select the correct topic. Unfortunately, it fails to force the 'select the right result pane' to display, so unless F1 by chance returns the correct page, you can't get to the information you need without seriously fiddling. On the other hand, VC8 has corrected an annoying VC71 bug that meant if you searched for an item preceded by a double colon, it'd actually search for an item preceded by a dot, which guaranteed it'd always get a wrong results.

The VC8 compiler is very good (so long as you avoid Microsoft's C++/CLI mess: four destructors? Sod off!). It properly implements much of the C++ language. The two major omissions from the standard, common to many C++ compilers, are export and tr1. You can't get around the missing export, but you can use alternative tr1 libraries. I use the commercial dinkumware libraries. Boost has a tr1 implementation in regression test.

To be fair, C++/CLI tries to resolve some issues with C++, but unfortunately, it tries to resolve issues that only occur when a programmer doesn't program well. If programmers misuse one language feature, are they really more likely to correctly use an alternative? For example, if they misuse classes like shared_ptr (or boost's smart_ptr), and leak memory, why should they correctly chose which of C++/CLI's four garbage collection destructors to implement instead? C++/CLI has some potential for implementation elegance, but I'm just not convinced by it. It doesn't help that VC8 C++/CLI is incompatible with the VC7 version.

The VC8 compiler seems significantly more robust than its predecessors. I have yet to see an internal compiler error, the bane of VC6, and still too common under VC7 and VC71. It is certainly better at compiling template metaprogramming code. The optimiser seems effective; I've not had release code break, except for programming errors. Which reminds me, Gimpel's lint works well with VC8 (and the earlier compilers)!

VC8 supports Windows CE, which runs on many CPU architectures. I've had code running on an x86, and an ARM, without any hint of a difference in compiled code behaviour on either platform.

The expensive editions of Visual Studio 8 come with a new, sophisticated project environment, Microsoft Team System, which supports automated build and test systems. Unfortunately, I've not had a chance to try it out.

I recommend VC8 to any Windows C++ programmer. Anyone wanting to explore should try the free Visual C++ Express Edition.