Hi: Jonathan Caves here. Recently I received some queries from users wanting to know what version of the Visual C++ compiler I use in my daily work. Well…that’s not really a simple question as I tend to use several different versions of the compiler.
Before I proceed a little aside on decoding the Visual C++ compiler version numbers. The compiler version number is usually something like:
The first two digits is the major version number of the compiler . This number stretches way back to the first C compiler that was shipped by Microsoft: some highlights along the way are:
6 – the last standalone C compiler
7 – Microsoft C/C++ – which included the first C++ compiler
8 – the first release of Visual C++
12 – Visual C++ 6.0
13 – Visual C++ .NET 2002
15 – Which will Visual C++ 2008
The next two digits are the minor version number. These are usually ‘00’ except for products like Visual C++ 4.2 and Visual C++ .NET 2003 (which was 13.10).
The next 5 digits are the build number. This is a number that uniquely identifies one build of the compiler from another it is incremented on a daily basis. For example: today’s build number is 20904: which you can decode as follows:
2 => year: but it is not a direct mapping: currently in DevDiv the base year is 2005 so ‘2’ maps to 2007
09 => month: September
04 => day
The latest set of one or more digits are used to identify Service Packs, etc.
For building I use the version of the compiler that the DevDiv build lab uses for the full product nightly build – this is currently build 15.00.20816.0 (which if you followed the explanation above you can see is a build from the middle of August). Using this build is important because I need to ensure that I can build the compiler using the tools that the build lab uses.
For testing I use a set of tools that I build on my machine – so I using a compiler that is only one or two days old (doing a full C++ compiler build takes at least 2+ hour even on a very fast machine so I tend not to do it every single day). Using a really fresh compiler is important as I want to ensure that I have all the recent changes that have been made to the compiler – just in case there is some weird interaction between my fix and some other recent change.
But this is only for Visual C++ 2008 targeted tasks. I am also currently responsible for handling all the QFE (Quick Fix Engineering) requests for the compiler so I also have on my machine Visual C++ 2008 Beta-2 (15.00.20706.01) Visual C++ 2005, both the original release (14.00.50727.42) and SP1 (14.00.50727.762) and Visual C++ 2003.
We also get bug reports from users against older versions of the compiler – so I also have Visual C++ .NET 2002 and Visual C++ 6.0 on my machine so I can compare whether or not code used to compiler with older versions of the product. Sometimes this ‘software archeology’ can take me back even further: recently a customer wanted confirmation that a bug only existed in Visual C++ 5.0 release so I had to find and install Visual C++ 4.2 and Visual C++ 5.0 and then I was able to confirm that the customer was correct – this specific bug only existed in Visual C++ 5.0.
On top of all this I also have to deal with builds of the compiler for x86, x64 and Itanium (the latter two come in both native and cross-compiler variants). So you can see that I don’t actually use a single version of the compiler tools and, with the exception of tools that we have released, I tend not to stick to a single version for very long. This may seem complicated (and it can be at times) but it does really help to ensure that the compiler we finally ship has been tested as thoroughly as possible.
I also use the Visual Studio IDE – though I don’t update this as often as I do the compiler tools (mostly because it take awhile to uninstall the old version and install a new version). Currently I am still using the Beta-2 release of the IDE but I do hope that if I find 1 hour of calm in the next week or so I can upgrade to a new release. I like to use a relatively recent version of the IDE so I can provide quick feedback to the IDE team on what I like and what I don’t like.