Yesterday I attended the Microsoft Visual C++ Accelerator Tour. It was a well-organized and interesting event and there were approximately 300-400 people in attendance (it was a free, open invitation). The message coming out of Redmond was very interesting: Microsoft is no longer positioning C++ as “yet another .NET programming language”. Damien Watkins, a Program Manager on the Visual C++ team, stated quite frankly that the feedback they have received from C++ developers is that they prefer to use C# for developing managed code for .NET. So what is the new positioning for C++? Apparently it’s:
Both Damien and Boris Jabes, another C++ PM, freely admitted that they are seeing great demand for a high quality environment for building native Win32 and Win64 applications, both inside and outside Microsoft (Microsoft SQL Server was mentioned several times as a particularly demanding client. Also I understood that Microsoft Visual Studio itself, as well as the VC++ compiler are both native applications). Consequently, most of the event was dedicated to discussing the benefits of the upcoming Visual Studio 2008 (Orcas) for this type of development. In the context of .NET, VC++ will not be getting support for LINQ.
Jonathan Caves, a lead developer on the VC++ team and a member of the C++ Standards Committee delivered two interesting presentations about what is (slowly) coming down the pike for the standard C++ language (some sort of simplified garbage collection if you would believe) including Microsoft’s commitment to that standard, and a very cool demo of the improvements to the C++ optimizer. You have to be a developer at heart to appreciate the reaction in the crowed when a program execution time came down from 4.5 seconds to 0.45 seconds.
Probably the most amusing part was Boris’ presentation of the new VC++ features, in particular MFC. Turns out that contrary to popular belief (and messages emanating from Microsoft itself) MFC is not dead, it was just in a comma. Microsoft is now reviving it and Visual Studio 2008 will introduce some new MFC functionality such as the wonderfully productive menu-bar auto-hide (a la IE7), support for the new Vista file dialogs, and the new Common Controls. Office 2007-like ribbon did not make it, but will be provided as a part of a follow-up service pack (in response to a question from Boris, two people in the audience actually admitted they will consider integrating this feature into their existing MFC applications).
My personal take on this is that existing code-base notwithstanding, if you are going to do significant UI development for Windows then .NET is the way to go. To my mind the real question is whether to use WPF or not. The only reason I can see for doing significant UI development in C++ is for cross-platform support, and in that case I would probably choose Qt.
One of Microsoft’s original messages regarding .NET was that, unlike the JVM, it’s a language agnostic platform. Turns out this feature wasn’t in such great demand: JScript.NET was the first casualty (raise your hand if you are aware of a single product that was built using that language), J# was always just a C# variant to ease Java-to-.NET migration, and now managed C++ is being dropped as a language for .NET development. This essentially leaves just C# and VB.NET, which I’ve never really gotten the point off. Yes, there are some experimental languages for .NET, such as F#, and the new DLR, but overall it seems to me that the overall consensus is that .NET development should be done in C#.