The release of Visual Studio Code Name Orcas Beta 1 presents a good opportunity to take a first look at the new C++ features in the product. Before diving into the features, it is worth having a brief look at the overall Orcas release; Orcas represents a return to the briefer 18-24 month release cycles for Visual Studio that occurred before the long gap that preceded the release of Visual Studio 2005. The shorter release cycle meant that certain features that required a longer development time have been moved into the release after Orcas, which has been identified as ‘Visual Studio Hawaii’ in various media reports.
For Visual C++, the lack of native use and support of MSBuild is the most noticeable consequence of the shorter release cycle of Orcas. As this column covered over two years ago, Visual C++ projects can be built with a MSBuild task, but there is no Visual Studio IDE support for selecting a Visual C++ project that will have a MSBuild project type. The C++ team at Microsoft has indicated that they are doing a lot of work internally to support MSBuild, and it seems very likely that Hawaii will have integrated support for MSBuild. It is also possible that command-line support of MSBuild for Visual C++ will be available through an unsupported release like a PowerToys offering.
Native Code Features
One of the quick-wins that Visual C++ Orcas delivers is in-built support for Windows Vista User Account Control (UAC). With Visual C++ 2005, the only way to interact with UAC is by creating a custom manifest file and including it in the build using the Manifest Tool | Input and Output | Additional Manifest Files setting on the Properties page for a Visual C++ project. In Visual Studio Orcas, new property settings on the Linker | Manifest File page, as shown in Figure 1, allow fine-grained control of the UAC settings for a Visual C++ application.
Figure 1: Visual C++ Orcas UAC support
As with every Visual C++ release that follows the release of a new version of the Windows operating system, MFC has been upgraded to support the new look-and-feel of Vista. Visual Studio Orcas represents that first time in a number of Visual C++ releases where every Windows common control will have a MFC wrapper available, and all new projects that are created with Visual C++ Orcas will benefit from the Vista look-and-feel by default. The MFC controls are designed to also support non-Vista versions of Windows, so if a CFileDialog is added to a dialog in Orcas, and the resulting application is installed on a Windows XP machine, the application will show the old-style file dialog box.
Missing for Visual Studio Orcas is the ATL Server—this product has been moved from Visual C++ to a shared-source project hosted on CodePlex. The ATL Server project is currently being co-ordinated by Nikola Dudar, who is a Program Manager in the Visual C++ team, and as with WTL, Microsoft hopes that a community of active developers will form around the code base.
In addition to the UI aspects of Vista, a new linker switch has been added to produce executable images that can use the address space layout randomization (ASLR) feature of Windows Vista. ASLR raises the bar for hackers who attempt to exploit a vulnerability by calling a function that is known to live at a specific address. ASLR will randomly rebase ASLR-aware images when they are loaded, and is a security technique that has been present in other operating systems, such as OpenBSD.
To take advantage of ASLR, an image has to be built to support a randomized base address, and this in the case for a number of the executable images that ship with Windows Vista. Visual C++ Orcas is the first compiler to support this technology for Windows, and randomize base address (/DYNAMICBASE is the linker command line switch) is turned on by default.
As the tool of choice to bridge the native to .NET divide, it is no surprise that the Orcas release includes a number of new features to make interoperability easier. The long-awaited release of an STL port to .NET ships with Orcas, and has been given the name STL/CLR (STL.NET was the working name of the project of porting STL to .NET). STL/CLR combines the C++ features of templates with the .NET concept of generics; this allows C++ programmers to take advantage of the power of STL containers and algorithms with .NET types. STL/CLR will be covered in further depth in a future article.
Visual C++ Orcas also introduces a new Marshaling Library that simplifies the conversion between types common in .NET and the native equivalents of those types. Although most C++ programmers who have done significant amounts of interop programming will probably already have helper functions, the introduction of the Marhsaling Library provides a common mechanism for achieving these conversions. The syntax of the new library is quite simple:
#include <msclr\marshal.h> TCHAR* c_style_string = _T("My C style string"); System::String^ dotNetString = msclr::interop::marshal_as<System::String^>(c_style_string);
The Marshaling Library is fully customizable, and next month you’ll take a look at writing a custom marshaller and also examine context-based marshalling.
C++ and .NET
One of the most noticeable features of C++ Orcas is the lack of some of the more advanced .NET features like LINQ that are included in C# and Visual Basic.NET. The gap between the managed code features of C++ and C# is likely to increase in future Visual Studio releases as the Visual C++ team focus on providing support for native features in the Windows operating system and the challenges of updating the compiler for the new release of the C++ language standard. In some ways, the lag between the support in C++ for advanced managed code features can be viewed as very similar to the gap between the release of the Windows SDK and the .NET Framework’s support of the new features it contains.
The growing differentiation between C++ and C# gives a good indication of which language to use for which task—the obvious and only choice for native development is C++, and for interop work the clear winner is C++, with three different interop technologies in It Just Works (IJW), COM interop and P/Invoke, and with the new support of the Marshaling Library in Orcas. The decision becomes more difficult when a solution will be primarily based on managed code. C++/CLI is a great extension to C++; it supports the simple and efficient production of managed code, and all the features of the .NET Framework libraries are available to C++. The area that C++ has traditionally lagged behind in is IDE support for WYSIWYG designers—Visual C++ 7 (2002) lacked any support for .NET designers, and Visual C++ 7.1 (2003) added support for Windows Forms but not Web Forms. Incompatibilities between the compilation model of ASP.NET 2 and C++ means that producing the front end of a web site in C++ is not easy achievable (and many would argue is not desirable). The gap between C++ and C# in terms of .NET features is obviously widened by LINQ, and while elements of LINQ will possibly be available in C++ in coming releases, it is very likely that there will continue to be some version lag for C++ in supporting all the features of C#.
The optimum approach with Visual Studio 2005, and a choice that only becomes more obvious with Visual Studio Orcas, is to prefer C# for application development, UIs and line-of-business data-centric applications, and to prefer C++ for system-level programming, applications that work closely with the Windows operating system, and for DLLs that bridge the gap between the native and managed worlds.
Visual C++ Orcas represents a renewed focus on what makes Visual C++ a unique and valuable tool in the Visual Studio product suite—rather than simply adding features in a ‘me-too’ race with C# and Visual Basic.NET on the managed code front, the C++ team have focussed on the areas where the other two languages are weak—interoperation with existing legacy code and deep integration with the Windows operating system. With over a thousand new native APIs released as part of Vista, it is obvious that native code development is far from dead, and Visual C++ is strongly placed with the Orcas release to take advantage of whatever header file the Windows SDK can throw at it.
header file the Windows SDK can throw at it.
About the Author
Nick Wienholt is a Windows and .NET consultant based in Sydney, Australia. He has worked on a variety of IT projects over the last decade and continues to stay involved in the developer community. Nick is the co-founder and president of the Sydney Deep .NET User group, writes technical articles for Pinnacle Publishing and the Microsoft Developer Network, and is a participant in many .NET-related newsgroups. Nick’s most recent book is Maximizing .NET Performance.