• Illustration: The New C++
• Chart: Native C++ Libraries

Visual C++ 2005, part of Visual Studio 2005, is currently in beta, giving developers their first look at the roadmap for Visual C++. Two major themes are apparent in this roadmap: helping ISVs with existing C++ applications take advantage of the .NET Common Language Runtime (CLR), while simultaneously increasing support for ANSI C++ standards. The two themes are in some ways contradictory, but both are aimed at reinvigorating C++ development and preventing defection to other languages and platforms.

Stronger Focus on ISVs

C, according to its co-creator Dennis Ritchie, was devised in the early 1970s as a "system implementation language for the nascent Unix operating system." C++, which evolved from C by adding support for object-oriented programming concepts, such as classes and inheritance, shares the same basic design. Even developers not using C++’s object-oriented features often use it as a better, more modern version of C. For purposes of this article, the two languages are close enough to be considered interchangeable.

Developers who use C++ today fall into one of two camps:

ISV and system programmers. ISVs and developers of system components (such as device drivers, Windows services, and specialty components with extremely high performance requirements) prefer C++ because it places as few layers as possible between the source code and the underlying hardware and OS. C++ offers a "nothing is impossible" environment by providing direct access to memory. The combination of low-level access to the system and advanced optimizing compilers means that C++ applications offer the highest performance. (Note, however, that application performance is a complex subject and a poorly written program is likely to perform slowly, regardless of the language in which it was written.)

The trade-off is that C++ lacks many of the safeguards that prevent developers from making serious errors, such as introducing buffer overflows that can be exploited by worms and viruses. Nevertheless, competitive considerations ensure that ISVs have a compelling interest in producing the smallest, fastest programs possible, which means that C++ is likely to remain their language of choice.

Advanced corporate developers. Despite the fact that it’s more difficult to program and lacks some safeguards, C++ has been used by some corporate developers who find languages and tools such as Visual Basic (VB) too limiting. For example, although VB can use COM objects and provides some support for authoring them, only C++ can build a COM component that uses the multithreading APIs provided by Windows—an important factor when building components used in server applications.

The introduction of C# and the .NET CLR, however, is likely to draw many advanced corporate developers away from C++ by giving them a more productive and safer environment than C++ without forcing them to give up the basic language syntax they have grown accustomed to. The CLR is an engine that loads programs and takes care of many housekeeping details, such as automatically freeing memory when it is no longer in use. Applications that run under the control of the CLR are frequently called "managed" applications or code, as opposed to "native" code, which runs directly on top of the OS. C# fits in between C++ and VB because it provides more access to underlying OS data structures than VB but maintains many of the basic syntax elements of C++.

Finally, unlike ISVs, which have economic and competitive reasons to use C++, corporate developers typically face a backlog of applications they need to create and are therefore more likely to value the productivity benefits of C#, provided the overall performance of its managed code is good enough, which seems to be the case for many corporate developers. With C# filling the need for a more powerful productivity tool than VB, the C++ team can focus its efforts on its traditional ISV constituency, which is more concerned about sheer performance and code portability.

Two Tracks: .NET and Standards

Microsoft’s roadmap for Visual C++ focuses on ISVs and systems programmers and embodies two major and somewhat contradictory themes: enabling developers to incrementally add managed code to their existing native-code C++ code bases in preparation for the upcoming Longhorn release of Windows, and, to a lesser degree, improving support for standards such as the ANSI/ISO C++ language definition to catch up with popular C++ compilers for Linux.

Improved .NET Support for Longhorn

Microsoft will update its C++ dialect in Visual C++ 2005 to make it easier for developers to build managed code, especially from existing C++ applications.

When the company first shipped the .NET Framework, it also introduced C++ extensions for building .NET components and incorporating .NET into existing C++ applications. The Managed Extensions to C++ (known informally as Managed C++) are now being overhauled to make .NET code easier to read and write and to dispel the idea that C++ is a second-class citizen in the .NET world. (For details on the changes, see the illustration "The New C++".)

Managed C++ is strategic to Microsoft, despite the fact that many developers familiar with C++ (particularly corporate developers) will probably choose C# when implementing a new application. The new features of Longhorn, expected to ship in 2006 or 2007, will be exposed as .NET APIs and designed to be used primarily from managed code, unlike the current Windows APIs, which are based on C and native code. (For more information on the shift in APIs in Longhorn, see "WinFX: The .NET Framework Takes Center Stage" on page 18 of the Dec. 2003 Update.) In order for Microsoft to successfully evangelize ISVs to build Longhorn applications, it must provide them with an easy way to access these .NET functions from C++ code.

The additional focus on .NET integration also means reduced importance for many of the C++ native libraries that Microsoft has delivered for tasks such as GUI programming, creating COM components, and building Web applications. Once-strategic libraries like the Microsoft Foundation Classes (MFC) have faded in importance and will receive only minor changes in Visual C++ 2005 to better integrate them with .NET class libraries, such as Windows Forms. The trend away from C++-specific native-code libraries is likely to continue. Advanced corporate developers are likely to find that C# meets their needs, and many ISVs prefer to either develop their own libraries or use the APIs provided directly by the OS. (For the status of some native C++ libraries, see the chart "Native C++ Libraries".)

Increasing ANSI Compliance Fends Off Linux Tools

At the same time that it requires better integration with .NET, Visual C++ faces its biggest competitive threat in years in the form of free C++ compilers running on Windows and Linux. The advent of open source and shared source development tools is making it more important that Microsoft’s C++ compiler adhere to industry standards.

Historically, Microsoft has put more effort into making Visual C++ support Windows-specific technologies, such as COM, than it did on making it conform to the ANSI language standard. ANSI C++ standardization took a long time (from 1991 to 1998) and in the intervening years, Windows developers voted with their wallets and adopted Visual C++ over other, more ANSI-compliant compilers.

But in recent years, even developers building exclusively for Windows have begun to ask for a more standards-compliant compiler in order to use shared-source and open-source libraries that may rely on language features not supported by Microsoft’s compiler. The same competitive threat from free compilers (such as the GNU C++ compiler) that forced Microsoft to make its C++ compiler available for free (see "Free C++ Compiler Available" on page 24 of the June 2004 Update) also forced it to take ANSI compliance more seriously.

Not surprisingly, given the complexity of programming languages such as C++, ANSI compliance is difficult to measure. The majority of programs use only a small subset of the language’s capabilities and compliance failures tend to appear in more complicated features. But for a developer trying to use third-party or open-source code, any error that prevents compiling successfully is serious.

Many C++ developers report that Visual C++ 2003 was the single biggest step toward ANSI compliance taken by Microsoft, and that it addressed several important and long-standing compliance bugs. Visual C++ 2005 makes further minor improvements, and the company says it will continue to fix compliance problems as it becomes aware of them. Users of versions prior to 2003 who care strongly about ANSI compliance should consider upgrading to at least Visual C++ 2003.

.NET and Standards: Squaring the Circle?

The two main thrusts of the Visual C++ roadmap—better integration of .NET into the language and increased support for ANSI standards—are somewhat contradictory. The former is designed to help developers build Windows-specific applications and components, while the latter makes it easier to build and use multiplatform C++ code, but the company appears to be committed to both. Specifically, by addressing some long-standing concerns in the ANSI community about its commitment to standards, while simultaneously proposing new language features, the Visual C++ team hopes to reinvigorate C++ development and prevent large-scale defection to languages such as C# or, worse, Java.

The company has made two significant hires that strengthen its standardization efforts. In Oct. 2001 it hired Stanley Lippman from AT&T Bell Labs, where he was involved in the early development of C++ and worked closely with the language’s creator, Bjarne Stroustrup. Lippman now leads the design of the Managed C++ language and plays a role similar to that of Anders Hejlsberg, the C# language architect. In addition, in Mar. 2002 Microsoft hired Herb Sutter, a noted C++ author and secretary of the ANSI C++ committee.

This team has most recently submitted the "New C++" extensions planned for Visual Studio 2005 to the European Computer Manufacturers Association (ECMA) for standardization, after which it would then be eligible for "fast-track" approval by ANSI. This is the same track that led to C# being successfully adopted as an ANSI standard in Apr. 2003.

Resources

The Visual C++ home page is msdn.microsoft.com/visualc.

Visual C++ Architect Stanley Lippman maintains a blog where he discusses many issues surrounding C++ and the Common Language Infrastructure (CLI) at http://blogs.msdn.com/slippman.

The C++/CLI draft specification can be found at http://msdn.microsoft.com/visualc/homepageheadlines/ecma.

Detailed information on the .NET Framework and CLR can be found in the June 2003 Research Report, "The .NET Development Platform."