If you are interested in the Auto-Vectorizer feature, shipping in Visual Studio 11, please hop over to the Native Concurrency blog, where we are now on episode 4.  The Overview post now includes a Table Of Contents, with links to each separate post.

Jim

As I mentioned a couple of weeks ago, we announced the Metro style apps with C++ event. Since we announced the camp, there were a lot of requests for a live webcast. Thanks to Jaime who just posted on this blog, the event will be broadcasted live!

Quoting Jaime:

Event sold out within a few days, and we got a lot of requests for it to be recorded (or broadcasted live)..  

I am happy to announce that the event will now be live.  Please pencil us in in your calendar. Event will be live on Friday May 18th, from 9 AM PST to 5 PM PST.

We will share details (the link) and the agenda later this week.   We will aim to have two live Q&As (one around noon PST) and one around 4 PM PST, we will take your questions via twitter.. Just follow the #win8C++Camp on the day of the event..

Thanks,

Vikas Bhatia.

VC++ PM

We are getting ready to start the event right now. Follow the twitter feed here: https://twitter.com/#!/search/%23ch9live 

The event will also be streaming live here: http://channel9.msdn.com/Events/Windows-Camp/Developing-Windows-8-Metro-style-apps-in-Cpp 

Thanks,

Vikas.

VisualC++ PM

We provide the ability in Visual Studio 11 to do native unit testing, with a new C++ unit testing framework shipping in the box. We’re really happy to enable this support for our C++ developers, so you no longer need to use the “/clr” flag or fall back to 3rd party frameworks. Read here for more details.

Hi my name is Li Shao. I am a Senior Software Design Engineer in Test in the Visual C++ group. In this blog, our team would like to review Visual Studio 11 (VS11) Desktop application build throughput compared to Visual Studio 2010 SP1 (VS10). Jim Hogg, Mark Hall, Bill Bailey, Mohamed Magdy Mohamed, and Valentin Isac have also contributed to this blog. You can refer to the Blog by Tim Wagner if you are interested in the new Metro Style application build throughput.

Build throughput is one of the most important productivity factors for C++ developers, and so build throughput testing is a vital component of our overall performance testing for Visual C++. We have targeted build throughput tests for the compiler and linker, and we also have build throughput tests for the MSBuild build engine. For every release, we have performance tests to check the overall end to end build performance, including time spent in the compiler front-end, back-end, and linker. For those of you who may not know, the compiler front-end is the phase that parses and analyzes the source code to build the intermediate representation (IR) of the program. The compiler back-end is the phase that takes the IR as input, and performs optimizations and generates code in the form of object files. The linker takes these object files as input and assembles them into an executable file. In the case of building with /GL (compile for link-time code generation, or LTCG), code generation and optimization happen during the linker phase where the IR for the entire executable can be analyzed.

Every new release of Visual C++ contains a large amount of new technology and features available to customers in the form of source code libraries and header files. For a given compiler, the more source code you have, the longer it takes to compile. Fortunately, processor advances over the years have offset this increase in functionality. In recent releases, as processor speeds began topping out, we have invested in multi-core features, such as Multi-Proc MSBuild, and the /MP compiler switch. In VS11, we multi-threaded the backend. For builds that require a lot of optimization time, this has netted some great wins. For example, Microsoft’s SQL build is 30% faster thanks to reduced back-end times.

The increase in functionality in VS11 is among the largest delta we’ve ever shipped. As we integrated all this new technology into the product, our performance tests told us how it was affecting overall build performance versus previous releases. Even though the amount of new source code being compiled rose significantly, in most cases, build time increases were held to an acceptable delta.

However, based on our testing results, if you have an application which uses the Standard Template Library heavily, you may notice slower builds due to the increased functionality mandated by the C++ Standard. In this blog, we will analyze the build throughput of a representative application to demonstrate the improvements we made and possible slowdown you may experience.

Build Throughput Data from “real world” Applications

Our end to end throughput tests use production-level, “real world” applications. We refer to them as RWC (Real World Code). Here is the build throughput data from an internal, post-Beta version of VS11 on one of our RWC projects across different machine configurations. This particular desktop application has about 50 C++ projects, with 2.8 million lines of code (LOC). The application makes heavy use of the Standard Template Library. The “RWC” below refers specifically to this application.

Figure 1: RWC Build Throughput (MSBuild 2 Proc (/m:2) and Full Optimization (/Ox))

Figure 2: RWC Build throughput with link /LTCG (LTCG: Link Time Code Generation, MSBuild 2 Proc (/m:2), Compile with /GL, link with /LTCG)

Figure 3: RWC Compiler Back-end throughput (MSBuild 2 Proc (/m:2))

Figure 4: RWC Link time throughput (MSBuild 2 Proc (/m:2))

“Full Build time” is measured from when the build starts until the build finishes. It is the clock time that it takes for the build to finish. Compiler front-end (FE), compiler back-end (BE), and link time are the total time (accumulated time) spent in the C1.dll & C1xx.dll (FE), C2.dll (BE) and linker across all processes. Since this is a multi-proc build, and some of the projects have /MP enabled for compiler, generally there is more than one instance of the compiler running, which is why the total time spent in the tools is much larger than the “Full Build Time”.

In the non-LTCG build (Figure 1), the linker does minimal work compared with the rest of the components, therefore the linker time is hardly visible from the graph. Likewise, in LTCG build (Figure 2), all the code generation happens after linking. Since the linker eliminates all redundant template instantiations across the object files before the back-end runs, the back-end time is drastically reduced in this scenario.

Based on our data when running multi-proc MSBuild (MSBuild /M:n) on this particular application, building with 4-8 Proc can give slight throughput improvement over 2 Proc for overall build time. However, due to resource contention and project reference limitation on paralleled builds that can actually happen, a 2-Proc build is representative of multi-proc build characteristics for this application in terms of overall throughput. Therefore, we are using the 2 Proc data here to present the build throughput.

Here are some key observations based on the data:

Faster Compiler Back-end phase

In VS11, we have introduced a new feature to support creating multiple compiler back-end threads to improve build performance. The compiler back-end performs optimization and code generation on a single function at a time, allowing it to generate code for multiple functions in parallel. This can be a win, especially for code generation with optimizations enabled, as performing optimizations requires the back-end to spend more time in each function.

This throughput win can be seen in Figure 1 and Figure 3. While these are impressive improvements in compiler back-end throughput, we note that in this scenario the back end time is a small fraction of the total build time. We highlight it here for illustration purposes only.

Slower Compiler Front-end phase

We can see that there is 15% - 20% performance degradation in the VS11 front-end compared to VS10 in this real world example (Figure 1 and Figure 2). Our investigation revealed that this performance degradation is not in the compiler itself but rather is a function of the increased number of template instantiations being processed by the front-end. New functionality added to the STL, significantly increases the number of template instantiations in a given compilation. This major increase of the functionality is mandated by the new C++ Standard and is also widely requested by our customers. The increase in template types forces the front end to instantiate many more templates for a given input file, which causes the overall build performance to degrade. Of course, we haven’t shipped VS11 yet, so we continue to analyze this issue and look for ways to improve throughput.

As we mentioned earlier, the linker takes the intermediate files generated by the compiler and produces the final assembly. As a result of larger intermediate files generated by the compiler, you may also see slight slowdown in link time for both un-optimized build and optimized build (LTCG), especially on lower end machines (Spec C as we presented) due to more symbols to process and merge.

Faster LTCG Build

On a high end machine (Spec A and Spec B as we presented), our tests show faster link time in LTCG builds (Figure 4).

For a number of releases the compiler has supported Link Time Code Generation (LTCG), whereby code generation is deferred to link-time so that information on all modules for the entire image (EXE, DLL) is made available for optimization. Thus, code generation can be done in the context of the entire image, inlining across modules, application of custom calling convention, etc. Non-LTCG builds generally limit optimizations to within the context of a single object file.

With VS11, this link-time code generation can be done in multiple threads, compiling more than one function at a time, caveat dependencies as determined by the function call tree. This is a particularly good win for projects that compile into fewer, larger images. Our data shows that when building a “big EXE” Microsoft product, SQL Server, build time improved ~30% due to the work we did to improve LTCG build throughput. Note that SQL Server sources do not use template code, which is why it does not have the build throughput degradation caused by the new STL templates.

How to improve your application’s build performance?

Since build throughput is very important to C++ developer productivity, here are a few suggestions that can help you improve build throughput.

Take advantage of the CPU cores on your machine

From Figure 1 and Figure 2, you can see that although the total FE time has regressed, the regression in the overall build time is still very minimal on the particular application, especially on high-end machines (Spec A and Spec B). This is due to the effect of MultiProc build. When building in the IDE, the Build system will use the total number of cores on your machine by default. You can also modify multi-proc build by going to Tools -> Options -> Projects and Solutions -> Build and Run, changing the setting for “Maximum number of Parallel Project Builds”. If you are building on the command line, pass in /m:n (n is the numbers of processes you would like to use). The default when building with MSBuild on the command line is 1. As mentioned earlier, although building with 4 or more procs might give you better performance, for this particular application, setting MSBuild to 2 proc build (/m:2) gives the performance that is close to 4 or 8 proc build. In addition, you can also set /MP per project or per file to take advantage of compiler level multi-process build. For additional suggestions on how to further tune your build, you can take a look of this blog.

Use Pre-Compiled Headers (PCH)

C++ library headers represent a collection of living, evolving libraries, and they tend to increase in size from release to release. In VS11, for example, the windows headers increased in raw size by 13%. This is due to adding more API functions and types related to Windows 8. The new Windows headers will add more compile time when the PCH is created, not when it is used. Once built, there are many more compiles that use the PCH, whose build time are affected only a tiny amount, if at all. Proper use of precompiled headers continues to be the most effective way to reduce overall build times. If your application uses template extensively, you may also consider pre-instantiate the template types in PCH files.

A small experiment shows the difference using PCH achieves for a single project with around 200 files. Each file has around a hundred lines of code. Various library headers are included in the PCH.

Figure 5: PCH impact of minimizing the effect of size increase of library headers

Use Managed Incremental Build

If you have a managed application, you may take advantage of the managed incremental build to avoid doing a full build when the referenced assemblies have insignificant change. For more information, you can read this blog.

Summary

We have made significant throughput improvements to the Compiler Back-end and Linker build phases. If you have an application that is not a heavy user of STL and spend a lot of time in optimization, you should see the build time improvement.

The increase of template types will play a dominant role in the overall build throughput for applications with extensive templates. Applications that use the STL extensively may experience longer build times due to changes mandated by the C++11 Standard. You may also experience slightly longer build time due to the increased number of total headers files in VS11 and Windows 8.

To improve the overall build time, you can take advantage of the multiple cores on your machines to do multiproc builds. Also make sure to use Pre-Compiled headers (PCH). For managed C++ application, be sure to have managed incremental build turned on to improve incremental build performance.

Let Us Know!

We are interested in getting your build throughput performance data if you see any improvement, or slowdown beyond what you might expect from some amount of growth in header files or usage of STL templates when migrating your applications to VS11. You may reply to the blog or send email to lishao at Microsoft dot com.

In addition to capturing the overall build time, you can get compiler and linker time for each compiler/linker instance by passing /Bt to Compiler and /Time to Linker.

· When building in the IDE, you can set /Bt as the additional options for compiler and /Time as the additional options for linker. Make sure you build the application with “Detailed” verbosity. To set the verbosity, you can go to Tools -> Options -> Project and Solutions -> Build and Run, set “MSBuild Project Build Verbosity” to “Detailed”.

· For command line build, you can set _CL_=/Bt and _LINK_=/Time in the build environment and build with MSBuild /v:d option.

In your build log, you will see the time spent in C1.dll (FE), C1xx.dll (FE), C2.dll (BE) and linker for each instance of the compiler and linker. You may need to write a simple script to add up those numbers. Please let us know if you would like us to post a script that can do the work. Alternatively, you can enable MSBuild “Diagnostic” logging. It will give you the time spent in Compiler task and linker task, which is close to the compiler and linker time.

We hope that this blog can help you understand more about C++ desktop application build throughput in VS11. If you are interested in C++ Metro Style Application build throughput, which are new for VS11, you can take a look at this blog to get an overview. Note that, we continue to make improvement in C++ Metro Style application build throughput. You should see about 20% overall build throughput improvement compared to Beta in the upcoming release.

Please let us know if you have any feedback. We appreciate your input to help us improve build performance.

The C++ organization is growing and hiring across all feature areas (C++ 11, compiler front-end, compiler back-end, C++ AMP, PPL, libraries & runtime, IDE, Casablanca). We are looking for passionate program managers, developers and testers to bang out the next versions of the toolset!

What’s in it for you:

1.          Be part of the C++ standards evolution - you’ll have the opportunity to work side-by-side with folks like Herb Sutter ![if>
2.          Solve exciting challenges as we navigate the hardware evolution (newer chipsets, multi-core, GPU, heterogeneous cores etc.) ![if>
3.          Be part of the technology that builds all of Microsoft’s platforms like Windows, Xbox, Windows Phone and Windows Embedded.![if>

Please apply directly using the links below. We’ll keep this list updated for the next couple of months.

Program Management

Software Development

• Software Development Engineer ll
• Software Development Engineer ll
• Software Development Engineer ll
• Software Development Engineer ll
• Software Development Engineer, Senior
• Software Development Engineer, Senior
• Software Development Engineer, Senior

Testing

• Software Development Engineer In Test
• Software Development Engineer In Test II
• Software Development Engineer in Test II
• Software Development Engineer in Test ll
• Software Development Engineer In Test, Senior

In case some of you missed it, Soma recently announced Visual Studio Express 2012 for Windows Desktop development. This express edition will include the latest VC++ compiler and libraries, which is great for students, new developers and open source application developers.

Please follow the link to see more details and to contribute to the discussion.

Hello, I’m Pat Brenner, a developer on the Visual C++ Libraries team. I recently shared some information about the Microsoft Foundation Class (MFC) Library in this blog post. Several people responded to that post asking for a list of bugs that have been fixed in MFC for Visual Studio 2012.

Though I cannot provide a complete list of the bugs in our internal bug database, here is a list of the bugs that were reported by customers through our Connect site that have been fixed in MFC for Visual Studio 2012 RTM. Click on any Connect bug number to see more information about that bug.

I hope you find this information useful. As you can see, we do pay attention to and take action on the bugs that are reported on the Connect site. So please continue to report bugs that you find in MFC (or any of the Visual C++ libraries)—we do want to hear about them.

Pat Brenner
Visual C++ Libraries Development Team

We recently announced the Visual Studio 2012 product lineup and platform support, and as a part of this announcement we mentioned that we were evaluating options for enabling C++ developers to build applications in Visual Studio 2012 that run on Windows XP without requiring side-by-side installation of Visual Studio 2010. Today I would like to share more details about this capability.

Background
The C++ runtime and libraries that accompany Visual Studio 2012 contain dependencies on several Windows API functions that exist only on Windows Vista and higher versions of the OS.  This means that applications built with Visual Studio 2012’s C++ compiler will fail to load and execute on Windows XP. Developers wishing to target Windows XP can use Visual Studio’s C++ multi-targeting feature, which enables the use of the Visual Studio 2010 compiler from within the new IDE. Multi-targeting enables developers to take advantage of the new features of the IDE without migrating projects to the new compiler or to use the Visual Studio 2010 compiler to build applications that target Windows XP.

Assessing Multi-targeting
The Beta release of Visual Studio 2012 offered us an opportunity to evaluate the effectiveness of C++ multi-targeting, particularly among developers that wish to target Windows XP. Feedback from customers cited two key scenarios they wanted Visual Studio 2012 to support in order to best meet their needs for Windows XP targeting:

1. The ability to target Windows XP and higher from a single compiler and tools chain rather than resort to separate builds for XP and for Vista+.
2. The ability to target Windows XP and higher from a single code base that employs modern C++11 language features.

In order to better meet customer needs relative to build configuration and XP targeting, we have made the decision to enhance multi-targeting to support Windows XP targeting directly from the Visual Studio 2012 C++ compiler and libraries.

Enhancing Multi-targeting
Later this fall, Microsoft will provide an update to Visual Studio 2012 that will enable C++ applications to target Windows XP. This update will make the necessary modifications to the Visual C++ 2012 compiler, runtime, and libraries to enable developers to create applications and DLLs that run on Windows XP and higher versions as well as Windows Server 2003 and higher. This update will also be included in the recently-announced Visual Studio Express 2012 for Windows Desktop.

Steve Teixeira
Director of Program Management
Visual C++

After Pat's post last week about MFC bugs fixed in Visual Studio 2012 (aka VC11), I thought that a similar list for the STL would be interesting:

A few notes on various arcane topics:

This list of 127 bugs consists of all of the bugs that I could find in our "old database" and "new database" (we use Team Foundation Server for bug tracking and version control, but we switched TFS databases a couple of years ago, making archaeological expeditions "fun") which were created by Connect, filed against the C++ Standard Library, resolved by me as Fixed, and fixed between VC10 SP1 and VC11 RTM.  It's reasonably comprehensive, but it might not be absolutely exhaustive.  I have intentionally excluded all non-Connect bugs (the grand total of fixed bugs found by Connect, myself, and other MS employees is roughly 330 - and that doesn't count things that were really bugs but never tracked as such) and private Connect bugs (a few people who file Connect bugs mark them as private, which prevents the world from seeing them - I recommend against doing this unless the bug's repro somehow contains information that you don't want the world to see).  Additionally, I have made no attempt to group bugs resolved as fixed that are actually duplicates (e.g. the many uniform_int_distribution bugs, fixed by a comprehensive rewrite).

I have presented the bugs' original titles from their submitters, although they're often renamed internally.  This is almost never interesting (there is a certain format that I like, so my bugs sort nicely), but I can share one exception.  Connect#533464 arrived as "The <initializer_list> header in the VC10 release candidate".  I improved this to "<initializer_list>: Zombie header hungers for our delicious brains".  (In VC10, I screwed up by leaving a nonfunctional <initializer_list> header in the product.)

Finally, you may be wondering where all of these bugs come from.  (I take all STL bugs personally, and I'd hate for someone to see this list and go around thinking "wow, the STL sure is buggy".)  Our STL implementation is very solid, but it is also very large and must deal with an enormous variety of complicated situations.  C++11 churn has led to two categories of bugs: those where the Working Paper said something bogus at the time that we implemented it (e.g. this happened with to_string(), bitset, and async()), and those where it permits more complicated inputs than we've had to deal with before (typically rvalue references and movable-only types).  Totally new features (e.g. atomics/threads/futures) arrive with totally new bugs.  There's the perennial gotcha of users doing "weird stuff" (e.g. obscure compiler switches like /J and /vd2).  And because the STL has no control over how demanding its users' performance requirements are, things that would be evil premature optimizations in ordinary application code are treated as totally legitimate performance bugs in the STL.  (A number of micro-optimizations in vector were suggested by a user and implemented in VC11, for example.)

The bottom line is that we're continuously improving the STL, so you should always upgrade to the latest major version and service pack as soon as possible - and that reporting bugs through Microsoft Connect really helps.

Stephan T. Lavavej Senior Developer - Visual C++ Libraries stl@microsoft.com

Back, at the end of April, we announced our first release of Casablanca as an incubation project on Devlabs. Since then, we are glad to have received a positive response from the C++ community.

Today, we are announcing a “bug-fix” refresh to the Casablanca release. The update can be downloaded from the Casablanca devlabs site.

The notable additions are:

• A number of bug fixes (including some reported by you)
• Support for https on the client
• Support for Visual Studio 2012 RC, Azure SDK 1.7 and Windows 8 Release Preview

Please use the devlabs forums to provide us with feedback.

Thank you for your support and we look forward to hearing back from you.

The Casablanca Team.

There are several reasons to program in C++, and one of the most important ones is the incredible performance that one can obtain. 

There are a set of optimizations that the Microsoft Visual C++ compiler offers to perform on your binaries to yield the best performance for your application on varying hardware (for e.g. via compiler switches such as /O2, Profile-Guided Optimization (PGO) and Link-Time Code Generation (LTCG) etc.). 

We are reaching out to you to get your feedback on the optimizations the compiler offers today and other potential optimizations that we can introduce to help get better performance from your application.

Please take a few minutes to complete this survey. Your answers to this survey will help us make the right investments for future releases of Visual Studio. Completing this questionnaire should take about 20
minutes to finish. 

Thanks in advance for taking the time! 

Thanks,

Code Generation and Optimization team

 In Visual Studio 2012, one of the new features for C++ developers is the new native type visualization framework (natvis) added to the debugger which allows customizing the way data types are displayed in debugger variable windows (e. g. autos, watch, locals, and data tips). For those who are familiar with the autoexp.dat file that has been used in earlier versions of Visual Studio, this new visualization framework supersedes that and offers xml syntax, better diagnostics, versioning and multiple file support.

Part 2 of my third video lecture series (covering the C++ Core Language) is now available.  In this part, I took an hour to explore template argument deduction, including what "non-deduced contexts" are - and how they can be used to your advantage!  For reference, here are all of the links to my video lectures, plus my GoingNative 2012 presentation:

[STL Introduction]

Part 1 (sequence containers)

Part 2 (associative containers)

Part 3 (smart pointers)

Part 4 (Nurikabe solver) - see Wikipedia's article and my updated source code

Part 5 (Nurikabe solver, continued)

Part 6 (algorithms and functors)

Part 7 (algorithms and functors, continued)

Part 8 (regular expressions)

Part 9 (rvalue references)

Part 10 (type traits)

[Advanced STL]

Part 1 (shared_ptr - type erasure)

Part 2 (equal()/copy() - algorithm optimizations)

Part 3 (_ITERATOR_DEBUG_LEVEL, #pragma detect_mismatch, and /d1reportSingleClassLayout)

Part 4 (rvalue references v2.1 and associative container mischief)

Part 5 (deduplicator, using Boost.Bimap, Filesystem, and ScopeExit) - see my deduplicate.cpp

Part 6 (container pretty printer) - see my pretty_printer.cpp

[GoingNative 2012]

STL11: Magic && Secrets (make_shared<T>(), emplacement, pair SFINAE, range-based for-loop) - see my slides

[Core C++]

Part 1 (name lookup)

Part 2 (template argument deduction)

Stephan T. Lavavej

Senior Developer - Visual C++ Libraries

stl@microsoft.com

Following STL Bugs Fixed In Visual Studio 2012, here are similar lists for the compiler front-end (responsible for parsing C++)...

... and the compiler back-end (responsible for optimizing and generating assembly code):

As usual, these lists are far from exhaustive.  They don't contain private Connect bugs or non-Connect bugs (which come from many sources: compiler testers, STL maintainers with last names ending in J, other MS teams like Windows and Office, external customers with support contracts, etc.).  Also, some public Connect bugs aren't represented here (in particular, /analyze and /ZW bugs).

If you find any more bugs that have eluded us, please continue to report them through Microsoft Connect.

Stephan T. Lavavej
Senior Developer - Visual C++ Libraries

If you have read Jason Zander’s post earlier today, you know that Visual Studio 2012 has been released to the web! Check out the MSDN Subscriber Download Page  and the Visual Studio product website. This release has brought a huge amount of new value for C++ developers. Here are the highlights:

C++11 Standards Support

Language Support

• Range-based for loops. You can write more robust loops that work with arrays, STL containers, and Windows Runtime collections in the form for ( for-range-declaration : expression ).
• Stateless lambdas, which are blocks of code that begin with an empty lambda introducer [] and capture no local variables, are now implicitly convertible to function pointers as required by the C++11 Standard.
• Scoped enumerations support. The C++ enum class enum-key is now supported. 

Standard Template Library

•  We’ve added support for the new STL headers: <atomic>, <chrono>, <condition_variable>, <filesystem>, <future>, <mutex>, <ratio>, and <thread>.
•  SCARY iterators. As permitted but not required by the C++11 Standard, SCARY iterators have been implemented.

Here is the detailed discussion on C++ 11 features in Visual Studio 2012, with links to the corresponding C++ 11 specs. Please also see the fun video series on STL … by STL.

Parallel Programming

Compiler and Linker

We’ve made major investments to help developers make the most of their target hardware. We are introducing the auto-vectorizer to take advantage of SSE2 instructions to make your loops go faster by doing 4 number operations at time, auto-parallelizer to automatically spread your work on many CPUs, and C++ AMP (C++ Accelerated Massive Parallelism) to leverage the power of GPU for data parallel algorithms. Note that C++ AMP also comes with a first-class debugging and profiling support.

Libraries (PPL)

We continue to enhance the breadth and depth of Parallel Patterns Libraries (PPL). In addition to major investments in async programming, we’ve added more to algorithms and concurrent collections. We are also working very hard in bringing most of these concepts into the next revision of the C++ standard.

Debugging

In addition to the Parallel Tasks window and Parallel Stacks window, Visual Studio 2012 offers a new Parallel Watch window so that you can examine the values of an expression across all threads and processes, and perform sorting and filtering on the results.

C++ for Windows 8

• Native XAML-based UI model: For Windows 8 Store applications, you can use the native XAML-based UI model.
• Visual C++ Component Extensions: These extensions simplify consumption of Windows Runtime objects, which are a necessary part of the new Windows 8 apps. For more information, see Roadmap for Windows 8 Store apps using C++ and Visual C++ language reference
• DirectX apps and games: You can develop graphically rich apps and games by using the new DirectX support. We’ve added tools for working with graphics assets, and debugging support for Direct3D-based programming.  The graphics asset and debugging tools can also be used for developing desktop apps.
• Windows Runtime Component DLL development: Component DLL development makes the Windows Runtime environment extensible.

Note: XAML/DirectX interop :Developers targeting Windows 8 Store apps can use both XAML and DirectX in the same app, which allows developers to build flexible user interfaces like the one in FreshPaint app.

IDE

In addition to the general Visual Studio IDE improvements like the new Solution Explorer, Preview Tabs, new Find, Compare, and Asynchronous Solution Load etc., we’ve made several IDE enhancements that are new for C++ and help C++ developers be more productive with Visual Studio.

• C++ Code Snippets. The IDE now adds the skeleton code for common C++ code constructs like switch, if-else, for loop, etc. automatically. Select a code snippet from the List Members drop-down list to insert it into your code and then fill in the required logic. You can also create your own custom code snippets for use in the editor.
• Semantic Colorization. C++ code editor now conveys semantic structure of the code by colorizing types, enumerations, macros, and other C++ tokens by default. There are a number of other tokens that can be colorized differently to customize the experience.
• IntelliSense Enhancements. The List Members drop-down list appears automatically as you type code into the code editor. Results are filtered using a fuzzy search algorithm, so that only relevant members are displayed as you type. C++ IntelliSense Quick Info tooltips now show richer XML documentation comments style information. Selecting a symbol now highlights all instances of the symbol in the current file. Press Ctrl+Shift+Up Arrow or Ctrl+Shift+Down Arrow to move among the highlighted references.

• C++/CLI IntelliSense. C++/CLI now has full IntelliSense support. IntelliSense features such as Quick Info, Parameter Help, List Members, and Auto Completion now work for C++/CLI. In addition, the other IntelliSense and IDE enhancements listed in this document also work for C++/CLI.
• Visual Studio Templates support. You can now use the Visual Studio Templates technology to author C++ project and item templates

Application Lifecycle Management Tools (ALM)

Code Analysis

Static code analysis helps identify runtime issues at compile time when they are much cheaper to fix. Code analysis for C++ feature in Visual Studio 2012 has been enhanced aiming to provide improved user experiences as well as analysis capabilities. In this new version, code analysis has been extended to support 64 bit apps, ship with additional concurrency rules to detect issues like race conditions, and offer the ability for creating customized rule sets. This feature is now available in all Visual Studio editions allowing every developer to make the best use of it.

Architecture Dependency Graphs

Generate dependency graphs from source code to better understand the architecture of your existing apps or code written by others. In Visual Studio 2012 you can generate dependency graphs by binaries, classes, namespaces, and include files for C++ apps. Also, use Architecture Explorer tool window to explore the assets and structure of your solution by looking at solution view or class view.

Example: Dependency Graph by Binary

Example: Dependency Graph by Include Files

Use Architecture Explorer to browse assets in the solution

Unit Test Framework for C++

Visual Studio 2012 ships with a new unit test framework for native C++. You can write light-weight unit tests for your C++ applications to quickly verify application behaviors. Use the new Test Explorer tool window to discover and manage your tests along with test results. This feature is now available in all Visual Studio editions.

Code Coverage

Code coverage has been updated to dynamically instrument binaries at runtime. This lowers the configuration overhead, provides better performance and enables a smoother user experience. Code coverage feature has also been integrated well with the new C++ unit test framework in Visual Studio 2012 allowing you to collect code-coverage data from unit tests for C++ app by one single click within Visual Studio IDE.

Coming Soon!

We’ve announced two things that will arrive in a few months:

• An update that will enable targeting Windows XP
• Availability of an Express SKU for Windows Desktop that includes C++ toolset

C++ for Windows Phone 8

As soon as the Windows Phone 8 SDK is made available, C++ developers will be able to target Windows Phone. Stay Tuned!

Example: Windows 8 Marble Maze Sample targeting Windows Phone 8

As always, we love hearing from you. Thanks for keeping us honest and kudos to those who have influenced our product design for the better!

On behalf of the VC++ team,

Rahul V.Patil

Lead Program Manager, C++

Hi, I’m Andy Rich, a tester on the C++ frontend compiler and one of the primary testers of the C++/CX language extensions.  If you’re like me, making use of a technology without understanding how it works can be confusing and frustrating.  This blog post will help explain how XAML and C++ work together in the build system to make a Windows Store application that still respects the C++ language build model and syntax.  (Note: this blog post is targeted towards Windows Store app developers.)

The Build Process

From a user-facing standpoint, Pages and other custom controls are really a trio of user-editable files.  For example, the definition of the class MainPage is comprised of three files: MainPage.xaml, MainPage.xaml.h, and MainPage.xaml.cpp.  Both mainpage.xaml and mainpage.xaml.h contribute to the actual definition of the MainPage class, while MainPage.xaml.cpp provides the method implementations for those methods defined in MainPage.xaml.h.  However, how this actually works in practice is far more complex.

This drawing is very complex, so please bear with me while I break it down into its constituent pieces.

Every box in the diagram represents a file.  The light-blue files on the left side of the diagram are the files which the user edits.  These are the only files that typically show up in the Solution Explorer.  I’ll speak specifically about MainPage.xaml and its associated files, but this same process occurs for all xaml/h/cpp trios in the project.

The first step in the build is XAML compilation, which will actually occur in several steps.  First, the user-edited MainPage.xaml file is processed to generate MainPage.g.h.  This file is special in that it is processed at design-time (that is, you do not need to invoke a build in order to have this file be updated).  The reason for this is that edits you make to MainPage.xaml can change the contents of the MainPage class, and you want those changes to be reflected in your Intellisense without requiring a rebuild.  Except for this step, all of the other steps only occur when a user invokes a Build.

Partial Classes

You may note that the build process introduces a problem: the class MainPage actually has two definitions, one that comes from MainPage.g.h:

 partial ref class MainPage : public ::Windows::UI::Xaml::Controls::Page,
      public ::Windows::UI::Xaml::Markup::IComponentConnector
 {
 public:
   void InitializeComponent();
   virtual void Connect(int connectionId, ::Platform::Object^ target);
 
 private:
   bool _contentLoaded;
 
 };

And one that comes from MainPage.xaml.h:

public ref class MainPage sealed
{
 public:
   MainPage();
 
 protected:
   virtual void OnNavigatedTo(Windows::UI::Xaml::Navigation::NavigationEventArgs^ e) override;
};

This issue is reconciled via a new language extension: Partial Classes.

The compiler parsing of partial classes is actually fairly straightforward.  First, all partial definitions for a class must be within one translation unit.  Second, all class definitions must be marked with the keyword partial except for the very last definition (sometimes referred to as the ‘final’ definition).  During parsing, the partial definitions are deferred by the compiler until the final definition is seen, at which point all of the partial definitions (along with the final definition) are combined together and parsed as one definition.  This feature is what enables both the XAML-compiler-generated file MainPage.g.h and the user-editable file MainPage.xaml.h to contribute to the definition of the MainPage class.

Compilation

For compilation, MainPage.g.h is included in MainPage.xaml.h, which is further included in MainPage.xaml.cpp.  These files are compiled by the C++ compiler to produce MainPage.obj.  (This compilation is represented by the red lines in the above diagram.)  MainPage.obj, along with the other obj files that are available at this stage are passed through the linker with the switch /WINMD:ONLY to generate the Windows Metadata (WinMD) file for the project. This process is denoted in the diagram by the orange line.  At this stage we are not linking the final executable, only producing the WinMD file, because MainPage.obj still contains some unresolved externals for the MainPage class, namely any functions which are defined in MainPage.g.h (typically the InitializeComponent and Connect functions).  These definitions were generated by the XAML compiler and placed into MainPage.g.hpp, which will be compiled at a later stage.

MainPage.g.hpp, along with the *.g.hpp files for the other XAML files in the project, will be included in a file called XamlTypeInfo.g.cpp.  This is for build performance optimization: these various .hpp files do not need to be compiled separately but can be built as one translation unit along with XamlTypeInfo.g.cpp, reducing the number of compiler invocations required to build the project.

Data Binding and XamlTypeInfo

Data binding is a key feature of XAML architecture, and enables advanced design patterns such as MVVM.  C++ fully supports data binding; however, in order for the XAML architecture to perform data binding, it needs to be able to take the string representation of a field (such as “FullName”) and turn that into a property getter call against an object.  In the managed world, this can be accomplished with reflection, but native C++ does not have a built-in reflection model.

Instead, the XAML compiler (which is itself a .NET application) loads the WinMD file for the project, reflects upon it, and generates C++ source that ends up in the XamlTypeInfo.g.cpp file.  It will generate the necessary data binding source for any public class marked with the Bindable attribute.

It may be instructive to look at the definition of a data-bindable class and see what source is generated that enables the data binding to succeed.  Here is a simple bindable class definition:

[Windows::UI::Xaml::Data::Bindable]
 public ref class SampleBindableClass sealed {
 public:
   property Platform::String^ FullName;
 }; 

When this is compiled, as the class definition is public, it will end up in the WinMD file as seen here:

This WinMD is processed by the XAML compiler and adds source to two important functions within XamlTypeInfo.g.cpp: CreateXamlType and CreateXamlMember.

The source added to CreateXamlType generates basic type information for the SampleBindableClass type, provides an Activator (a function that can create an instance of the class) and enumerates the members of the class:

if (typeName == L"BlogDemoApp.SampleBindableClass")
{
  XamlUserType^ userType = ref new XamlUserType(this, typeName, GetXamlTypeByName(L"Object"));
  userType->KindOfType = ::Windows::UI::Xaml::Interop::TypeKind::Custom;
  userType->Activator = 
   []() -> Platform::Object^ 
   {
     return ref new ::BlogDemoApp::SampleBindableClass(); 
   };
  userType->AddMemberName(L"FullName");
  userType->SetIsBindable();
  return userType;
}

Note how a lambda is used to adapt the call to ref new (which will return a SampleBindableClass^) into the Activator function (which always returns an Object^).

From String to Function Call

As I mentioned previously, the fundamental issue with data binding is transforming the text name of a property (in our example, “FullName”) into the getter and setter function calls for this property.  This translation magic is implemented by the XamlMember class.

XamlMember stores two function pointers: Getter and Setter.  These function pointers are defined against the base type Object^ (which all WinRT and fundamental types can convert to/from).  A XamlUserType stores a map<String^, XamlUserType^>; when data binding requires a getter or setter to be called, the appropriate XamlUserType can be found in the map and its associated Getter or Setter function pointer can be invoked.

The source added to CreateXamlMember initializes these Getter and Setter function pointers for each property.  These function pointers always have a parameter of type Object^ (the instance of the class to get from or set to) and either a return parameter of type Object^ (in the case of a getter) or have a second parameter of type Object^ (for setters).

if (longMemberName == L"BlogDemoApp.SampleBindableClass.FullName")
{
  XamlMember^ xamlMember = ref new XamlMember(this, L"FullName", L"String");
  xamlMember->Getter =
  [](Object^ instance) -> Object^
  {
    auto that = (::BlogDemoApp::SampleBindableClass^)instance;
    return that->FullName;
  };
 
  xamlMember->Setter =
  [](Object^ instance, Object^ value) -> void
  {
    auto that = (::BlogDemoApp::SampleBindableClass^)instance;
    that->FullName = (::Platform::String^)value;
  };
  return xamlMember;
 }

The two lambdas defined use the lambda ‘decay to pointer’ functionality to bind to Getter and Setter methods.  These function pointers can then be called by the data binding infrastructure, passing in an object instance, in order to set or get a property based on only its name.  Within the lambdas, the generated code adds the proper type casts in order to marshal to/from the actual types.

Final Linking and Final Thoughts

After compiling the xamltypeinfo.g.cpp file into xamltypeinfo.g.obj, we can then link this object file along with the other object files to generate the final executable for the program.  This executable, along with the winmd file previously generated, and your xaml files, are packaged up into the app package that makes up your Windows Store Application.

A note: the Bindable attribute described in this post is one way to enable data binding in WinRT, but it is not the only way.  Data binding can also be enabled on a class by implementing either the ICustomPropertyProvider interface or IMap<String^,Object^>.  These other implementations would be useful if the Bindable attribute cannot be used, particularly if you want a non-public class to be data-bindable.

For additional info, I recommend looking at this walkthrough, which will guide you through building a fully-featured Windows Store Application in C++/XAML from the ground up.  The Microsoft Patterns and Practices team has also developed a large application which demonstrates some best practices when developing Windows Store Applications in C++: project Hilo.  The sources and documentation for this project can be found at http://hilo.codeplex.com/.  (Note that this project may not yet be updated for the RTM release of Visual Studio.)

I hope this post has given you some insight into how user-edited files and generated files are compiled together to produce a functional (and valid) C++ program, and given you some insight into how the XAML data binding infrastructure actually works behind the scenes.

Hello; I'm James McNellis, and I've recently joined the Visual C++ team as a libraries developer. My first encounter with the C++/CX language extensions was early last year, while implementing some code generation features for the Visual Studio 2012 XAML designer. I started off by hunting for some example code, and it suffices to say that I was a bit surprised with what I first saw. My initial reaction was along the lines of:

"What the heck are these hats doing in this C++ code?"

Actually, I was quite worried; because I thought it was C++/CLI—managed code. Not that managed code is bad, per se, but I'm a C++ programmer, and I had been promised native code.

Thankfully, my initial impression was uninformed and wrong: while C++/CX is syntactically similar to C++/CLI and thus looks almost the same in many ways, it is semantically quite different. C++/CX code is native code, no CLR required. Programming in C++/CLI can be very challenging, as one must deftly juggle two very different object models at the same time: the C++ object model with its deterministic object lifetimes, and the garbage-collected CLI object model. C++/CX is much simpler to work with, because the Windows Runtime, which is based on COM, maps very well to the C++ programming language.

Windows Runtime defines a relatively simple, low-level Application Binary Interface (ABI), and mandates that components define their types using a common metadata format. C++/CX is not strictly required to write a native Windows Runtime component: it is quite possible to write Windows Runtime components using C++ without using the C++/CX language extensions, and Visual C++ 2012 includes a library, the Windows Runtime C++ Template Library (WRL), to help make this easier. Many of the Windows Runtime components that ship as part of Windows (in the Windows namespace) are written using WRL. There's no magic in C++/CX: it just makes writing Windows Runtime components in C++ much, much simpler and helps to cut the amount of repetitive and verbose code that you would have to write when using a library-based solution like WRL.

The intent of this series of articles is to discuss the Windows Runtime ABI and to explain what really happens under the hood when you use the C++/CX language constructs, by demonstrating equivalent Windows Runtime components written in C++ both with and without C++/CX, and by showing how the C++ compiler actually transforms C++/CX code for compilation.

Recommended Resources

There are already quite a few great sources of information about C++/CX, and I certainly don't intend for a simple series of blog articles to replace them, so before we begin digging into C++/CX, I wanted to start with a roundup of those resources.

First, if you're interested in the rationale behind why the C++/CX language extension were developed and how the C++/CLI syntax ended up being selected for reuse, I'd recommend Jim Springfield's post on this blog from last year, "Inside the C++/CX Design". Also of note is episode 3 of GoingNative, in which Marian Luparu discusses C++/CX.

If you're new to C++/CX (or Windows Store app and Windows Runtime component development in general), and are looking for an introduction to building software with C++/CX, or if you're building something using C++/CX and are trying to figure out how to accomplish a particular task, I'd recommend the following resources as starting points:

• Visual C++ Language Reference (C++/CX): The language reference includes a lot of useful information, including a C++/CX syntax reference with many short examples demonstrating its use. There's also a useful walkthrough of how to build a Windows Store app using C++/CX and XAML. If you're just starting out, this would be a great place to start.

• C++ Metro style app samples: Most of the C++ sample applications and components make use of C++/CX and many demonstrate interoperation with XAML.

• Component Extensions for Runtime Platforms: This used to be the documentation for C++/CLI, but it has since been updated to include documentation for C++/CX, with comparisons of what each syntactic feature does in each set of language extensions.

• Hilo is an example application, written using C++, C++/CX, and XAML, and is a great resource from which to observe good coding practices—both for modern C++ and for mixing ordinary C++ code with C++/CX.

• Building Metro style apps with C++ on MSDN Forums is a great place to ask questions if you are stuck.

Tools for Exploration

Often, the best way to learn about how the compiler handles code is to take a look at what the compiler outputs. For C++/CX, there are two outputs that are useful to look at: the metadata for the component, and the generated C++ transformation of the C++/CX code.

Metadata: As noted above, Windows Runtime requires each component to include metadata containing information about any public types defined by the component and any public or protected members of those types. This metadata is stored in a Windows Metadata (WinMD) file with a .winmd extension. When you build a Windows Runtime component using C++/CX, the WinMD file is generated by the C++ compiler; when you build a component using C++ (without C++/CX), the WinMD file is generated from IDL. WinMD files use the same metadata format as .NET assemblies.

If you want to know what types have been fabricated by the C++ compiler to support your C++/CX code, or how different C++/CX language constructs appear in metadata, it is useful to start by inspecting the generated WinMD file. Because WinMD files use the .NET metadata format, you can use the ildasm tool from the .NET Framework SDK to view the contents of a WinMD file. This tool doesn't do much interpretation of the data, so it can take some getting used to how it presents data, but it's very helpful nonetheless.

Generated Code: When compiling C++/CX code, the Visual C++ compiler transforms most C++/CX constructs into equivalent C++ code. If you're curious about what a particular snippet of C++/CX code really does, it's useful to take a look at this transformation.

There is a top-secret compiler option, /d1ZWtokens, which causes the compiler to print the generated C++ code that it generated from your C++/CX source. (Ok, this compiler option isn't really top secret: Deon Brewis mentioned it in his excellent //BUILD/ 2011 presentation, "Under the covers with C++ for Metro style apps." However, do note that this option is undocumented, and thus it is unsupported and its behavior may change at any time.)

The output is intended for diagnostic purposes only, so you won't be able to just copy and paste the output and expect it to be compilable as-is, but it's good enough to demonstrate how the compiler treats C++/CX code during compilation, and that makes this option invaluable. The output is quite verbose, so it is best to use this option with as small a source file as possible. The output includes any generated headers, including the implicitly included <vccorlib.h>. I find it's often best to use types and members with distinctive names so you can easily search for the parts that correspond to your code.

There are two other useful compiler options, also mentioned in Deon's presentation, which can be useful if you want to figure out how class hierarchies and virtual function tables (vtables) are laid out. The first is /d1ReportAllClassLayout, which will cause the compiler to print out the class and vtable layouts for all classes and functions in the translation unit. The other is /d1ReportSingleClassLayoutClyde which will cause the compiler to print out the class and vtable layouts for any class whose name contains "Clyde" (substitute "Clyde" for your own type name). These options are also undocumented and unsupported, and they too should only be used for diagnostic purposes.

Next Up...

In our next article (which will be the first "real" article), we'll introduce a simple C++/CX class and discuss how it maps to the Windows Runtime ABI.

Hopefully by now you have heard of C++ AMP. C++ AMP is a modern C++ library (plus a key new language feature) that ships with Visual Studio 2012 and it lets you take advantage of accelerators, such as the GPU, for compute purposes. Think data parallelism, but at a massive level, accelerated by powerful hardware. If you need more motivation on how using C++ AMP can speed up code, check out the nbody or the morph demo.

To follow the C++ AMP story, you should subscribe to the Parallel Programming in Native Code blog. Over the last year we have published (and updated for RTM) a number of Visual Studio sample projects, links to complementary open source libraries, and of course the C++ AMP open specification that any vendor can implement, so they can offer C++ AMP on other non-Microsoft platforms. If you have questions on C++ AMP, we welcome them at our MSDN forum.

In addition, this week we published on our blog two collections of links worth sharing more broadly

1. “Learn C++ AMP” is for you if you are a total C++ AMP newbie and have now decided to take the plunge.
2. “Present on C++ AMP” will help you give a presentation on C++ AMP, which I know some of you need to do even if you are not experts on a technology – we’ve got you covered.

Finally, if you already feel comfortable with C++ AMP, you can prove your skills and also win software and hardware by taking part in the C++ AMP coding contest.

See C++/CX Part 0 of [N]: An Introduction for an introduction to this series.

In this article we'll consider the basics of C++/CX by looking at a simple Windows Runtime class; we'll skim over some of the details, but don't worry: we'll come back and cover them in future posts. The code in this post is complete, though some namespace qualification is omitted for brevity; attached to this article is a Visual Studio solution containing the complete code for both the C++/CX and the WRL component, along with a simple test app that uses both.

Alright. Here's our simple class:

    public ref class Number sealed
    {
    public:
        Number() : _value(0) { }

        int  GetValue()          { return _value;  }
        void SetValue(int value) { _value = value; }

    private:
        int _value;
    };

This is a rather silly class, but it is sufficient to demonstrate some of the fundamentals of both C++/CX and Windows Runtime. Aside from the public ref and sealed in the class declaration, this class looks exactly like an ordinary C++ class. This is a good thing: our C++/CX code should look similar to similar C++ code, but should be sufficiently different that we (and the compiler!) can identify it as being different.

So, what does it really mean that this class is a sealed, public, ref class? A ref class is a reference type. Windows Runtime is built atop COM, and a Windows Runtime reference type is effectively a COM class type. Whenever we interact with a reference type object, we do so indirectly (by reference), via a pointer to an interface that the reference type implements. Since we never interact with a reference type by value, its implementation is opaque: so long as its existing interface remains unchanged, its implementation may be modified without affecting other components that depend on it (new functionality can be added, but not removed).

A public type is visible outside of the component that defines it, and other components may refer to and use this type. Types can also be private (which is the default); a private type can only be referred to from within the component that defines it. The Windows Metadata file for a C++/CX component only contains metadata for public types. There are fewer restrictions on private types than on public types because private types do not appear in metadata and thus are not constrained by some of the rules of Windows Runtime.

The sealed simply specifies that this class may not be used as a base class. Most public Windows Runtime types are sealed (currently, the only public types that may be unsealed are those derived from Windows::UI::Xaml::DependencyObject; these types are used by XAML apps).

The "Ref classes and structs (C++/CX)" page in the aforementioned Visual C++ Language Reference has a good roundup of other interesting facts about reference types.

Interfaces

I said above that whenever we interact with a reference type object, we do so via an interface that the reference type implements. You may have noticed that it looks like our Number class doesn't implement any interfaces: it has no base class list at all. Thankfully, the compiler is going to help us out here so that our Number class isn't useless.

The compiler will automatically generate an interface for our class, named __INumberPublicNonVirtuals. As its name suggests, this interface declares all of the public, nonvirtual member functions of our Number type. If we were to define this ourselves in C++/CX, it would look like so:

    public interface struct __INumberPublicNonVirtuals
    {
        int GetValue() = 0;
        void SetValue(int) = 0;
    };

The Number class is then transformed to declare this interface. If our class declared any new public virtual members (i.e., not overrides of base class virtual member functions) or any virtual or nonvirtual protected members, the compiler would generate interfaces for those as well.

Note that these automatically generated interfaces only declare members that aren't already declared by an interface that the class explicitly implements. So, for example, if we declared another interface:

    public interface struct IGetNumberValue
    {
        int GetValue() = 0;
    };

and defined our Number class as implementing this interface, the automatically generated __INumberPublicNonVirtuals would only define the SetValue member function.

Error Handling

In modern C++ code, exceptions are usually used for error reporting (not always, but they should be the default). A function is expected to return its result directly (as a return value) and throw an exception if a failure occurs. However, exceptions are not portable across different languages and runtimes; exception handling machinery varies quite a bit. Even within C++ code exceptions can be problematic, as different compilers may implement exceptions differently.

Since exceptions don't work well across different languages, Windows Runtime does not use them; instead, each function returns an error code (an HRESULT) indicating success or failure. If a function needs to return a value, the value is returned via an out parameter. This is the same convention used by COM. It's up to each language projection to translate between error codes and the natural error handling facility for that language.

There is overhead involved in catching and rethrowing exceptions, but the benefit is obvious even in simple scenarios involving interaction between components written in different languages. Consider, for example, a function in a C# component calling a function in a component implemented in C++/CX. The C++ code can throw an exception derived from Platform::Exception, and if the exception is not handled, it will be caught at the ABI boundary and translated into an HRESULT, which is returned to the C# code. The CLR will then translate the error HRESULT into a managed exception, which will be thrown for the C# code to catch.

The important thing is that both components--the C# component and the C++ component--get to handle errors naturally using exceptions, even though they use different exception handling machinery. We'll cover the details of which exceptions get translated at the C++/CX boundary, and how the translation takes place, in a future article (this topic is sufficiently complex that it warrants separate treatment). For the moment, it is sufficient to know that the translation happens automatically.

Member Functions

We've intentionally made our Number class very simple: neither GetValue nor SetValue can throw, and a call to either will therefore always succeed. We can therefore use them to demonstrate how the compiler transforms our C++/CX member functions into the real ABI functions. GetValue is a bit more interesting since it returns a value, so let's take a look at it:

    int GetValue()
    {
        return _value;
    }

The compiler will generate a new function with the correct ABI signature; for example,

    HRESULT __stdcall __abi_GetValue(int* result)
    {
        // Error handling expressly omitted for exposition purposes
        *result = GetValue();
        return S_OK;
    }

The wrapper function has an additional out parameter for the return value appended to the parameter list, and its actual return type is changed to HRESULT. Windows Runtime functions use the stdcall calling convention on x86, so the __stdcall annotation is required. By default, nonvariadic member functions ordinarily use the thiscall calling convention. (Calling convention annotations only really matter on x86; x64 and ARM each have a single calling convention.)

We've named our wrapper function __abi_GetValue; this is the name that the compiler gives to the function on the interface that it generates; in the class it uses a much longer name with lots of underscores to ensure that it doesn't conflict with any user-declared functions or functions inherited from other classes or interfaces. The name of the function doesn't matter at runtime, so it doesn't really matter what name the function has. At runtime, functions are called via vtable lookup, and since the compiler is generating the wrapper functions, it knows which function pointers to place into the vtables.

A wrapper is generated for our SetValue function following the same pattern, with the exception that no out parameter is added because it returns no value.

A Simple Class, without C++/CX

With what we've discussed so far, we already have enough information to implement our Number class using C++ with the help of WRL and without using C++/CX.

When using C++/CX, the C++ compiler will generate both the Windows Metadata (WinMD) file for the component and the DLL that defines all of the types. When we don't use C++/CX, we need to use IDL to define anything that needs to end up in metadata and use midlrt to generate a C++ header file and a Windows Metadata file from the IDL. For those experienced with COM, this should be quite familiar.

First, we need to define an interface for our Number type. This is equivalent to the __INumberPublicNonVirtuals interface that the compiler generated for us automatically when we were using C++/CX. Here, we'll just name our interface INumber:

    [exclusiveto(Number)]
    [uuid(5b197688-2f57-4d01-92cd-a888f10dcd90)]
    [version(1.0)]
    interface INumber : IInspectable
    {
        HRESULT GetValue([out, retval] INT32* value);
        HRESULT SetValue([in] INT32 value);
    }

Our INumber interface derives from the IInspectable interface. This is the base interface from which all Windows Runtime interfaces derive; in C++/CX, every interface implicitly derives from IInspectable.

We also need to define the Number class itself in the IDL file, because it is public and therefore needs to end up in the metadata file:

    [activatable(1.0), version(1.0)]
    runtimeclass Number
    {
        [default] interface INumber;
    }

The activatable attribute used here specifies that this class is default constructible. The details of how object construction works will be covered in a future article. For the moment, it's sufficient to know that this activatable attribute will generate the required metadata in the metadata file to report the Number class as default constructible.

And, that's all that is required in the IDL file. If you compare the WinMD file produced by this IDL file with the one produced for our C++/CX component, you'll see that they are largely the same: the interface has a different name, and there are a few extra attributes applied to types in the C++/CX component, but they are otherwise the same.

The class definition in C++ is straightforward:

    class Number : public RuntimeClass<INumber>
    {
        InspectableClass(RuntimeClass_WRLNumberComponent_Number, BaseTrust)

    public:
        Number() : _value(0) { }

        virtual HRESULT STDMETHODCALLTYPE GetValue(INT32* value) override
        {
            *value = _value;
            return S_OK;
        }

        virtual HRESULT STDMETHODCALLTYPE SetValue(INT32 value) override
        {
            _value = value;
            return S_OK;
        }

    private:
        INT32 _value;
    };

The RuntimeClass class template and the InspectableClass macro are both from WRL: together they handle much of the mundane, repetitive work to implement a Windows Runtime class. The RuntimeClass class template takes as its arguments a set of interfaces that the class will implement and it provides a default implementation of the IInspectable interface member functions. The InspectableClass macro takes as its arguments the name of the class and the trust level of the class; these are required to implement pieces of the IInspectable interface.

The two member functions are defined as is expected, given the discussion above: instead of directly using the __stdcall modifier, we use the STDMETHODCALLTYPE, which expands to __stdcall when using Visual C++ and the Windows headers, but could be changed to expand to something else if you were using a different compiler. You could also use the STDMETHOD macro.

Finally, because our Number type is default constructible, and because the default constructor is public, meaning that other components can create an instance of this class, we need to implement the logic required to enable other components to call the constructor of our class. This involves implementing a factory class and registering the factory so that we can return an instance of the factory when asked. There's a fair bit of work required here, but since we only have a default constructor, we can simply use the ActivatableClass macro from WRL:

    ActivatableClass(Number)

And, that's it! The WRL component requires a bit more than three times as much code as the C++/CX component, but this is just a small, simple component. As things get more complex, and as we use more features of Windows Runtime, we'll see that the WRL-based code both grows and becomes more complex much faster than the C++/CX-based code.

In our next post, we'll discuss hats (^) in detail, and in future posts we'll cover the details of construction, exception handling, and other interesting topics.