@Glen: I had a chance to ask Herb about that - Here is what he sent me:
"First, we definitely provide two ways to access WinRT from VC++:
· The C++/CX language extensions, which give arguably simpler syntax, and definitely give better optimization opportunities because the compiler is aware of more of what’s going on. The syntax is basically the same as C++/CLI which is already an Ecma standard (Ecma-372) produced mid last decade with the gracious help and input of a who’s-who of the ISO C++ committee, and that is already open so that any compiler vendor can freely implement it, and if ISO C++ or any other standard wants to incorporate any of it we are happy to support that – in fact, several features from C++/CLI and C++/CX, such as nullptr and enum class, have already been adopted into ISO C++ and are part of the new ISO C++11 standard.
· The WRL template library provides a library style that also works if you prefer that.
I would encourage you to try both, and see which you like best.
We support both in our compiler wherever WinRT is available. For other questions about where WinRT is available (e.g., in Metro vs. desktop apps) you need to ask the Windows team since they own that – but wherever they make it available, our compiler will support it.
As for the specific question about the C++CX model regarding why we chose ^ and ref new: Definitely please see section 3.3 of my paper A Design Rationale for C++/CLI. Many of the same considerations apply that I mentioned there, even though WinRT is definitely not .NET.
· Type system: It’s important to have clear and simple statements about the type system. Today in Standard C++, the type of a new-expression is a raw pointer (*). Likewise, it’s important to be able to say something like, “the type of a ref new-expression is a ^.”
· Distinguishing different conceptual heaps: It’s nice to be able to distinguish the WinRT allocation from native allocation (i.e., ref new vs. new) as they are conceptually different heaps. The difference may not be as big as “CLR heap vs. native heap” but they are different.
I’ve been asked several times, “why not just reuse ‘new T’ so that it returns a ^ if T is a WinRT type?” This has been tried; the original Managed Extensions binding C++ and .NET about 10 years ago did try to make “new T” simply do (and return) different things based on the kind of type T is. This turned out to be a bad idea for two main reasons:
· It was the primary source of design problems: We realized that many of the problems were actually secondary problems stemming from one primary problem, namely that this design conflated two things that should be independent: a) the kind of type; and b) how it’s allocated.
· It ran counter to Standard C++: Tying those two things together actually ran counter to today’s Standard C++, because Standard C++ already allows you to express different kinds of types (e.g., reference types having virtual functions, value types that are copyable, POD types which are bit-copyable) and makes it completely orthogonal where you can allocate them (e.g., any of them can be allocated on the stack, or as a directly embedded class member, or on the heap with new and managed with a raw pointer, or on the heap with make_shared and managed with a shared_ptr, and so forth). We felt it’s important to keep those things orthogonal.