The short answer to the question in the title is: In Whidbey, ^ and gcnew are mostly all you're likely to use, if all you're doing with .NET is consuming (using) .NET Frameworks types and services. Post-Whidbey, you could even dispense with those and use * and new, because we intend to support allocating CLI objects on the native heap with new and pointing at them with *'s.

Alisdair Meredith recently asked me:

  • "I am still trying to work out the target audience [...] I can see 2 ways of approaching the CLI binding:

    "i/ I want to write all my code in ISO conformant C++, and will use CLI binding as a public interface layer to handle targetting a .NET environment.

    "ii/ I write all my code in this new C++ .NET dialect, as I only want to target .NET, and I get to use all the familiar goodies of C++ along with all the new goodies in .NET and the binding.

    "Clearly, market (ii) will be much happier with the more sugary extension such as for each, abstract etc."

This is a very good point, and I'll use it as a hook to talk about the two major categories of use I see for the C++/CLI extensions.

I do think the current design serves both markets well. In particular, note that nearly all of the extensions will only be used by people authoring CLI types, so:

  • Group (ii) is going to go whole hog using .NET and authoring new types, and is well served by more elegant/sugary syntax.
  • Group (i) is simply going to be consuming the CLI types, probably not author them, and will probably only ever need ^ and gcnew.

What's more, in the post-Whidbey timeframe when we complete the support for allocating any object (including CLI objects) on the native heap using new, people could actually consume CLI / .NET Frameworks types seamlessly in their application without any new syntax. Of course, under the covers we'll be creating a proxy object each time, so there's a probably-slight performance impact to doing it this way, but it's worth noting that you'll be able to do this eventually.

Finally, I should also add that we intend to emit warnings by default when any of the extensions are used with native (i.e., normal C++) types, so that people will know when they are using a nonstandard (well, non-ISO-C++-standard at any ware) extension in a class that would otherwise be portable.