How much C++/CLI syntax do you need to use all of the .NET Frameworks?

  • Article

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<br> the CLI binding: "i/ I want to write all my code in ISO conformant C++, and will use CLI binding<br> 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<br> .NET, and I get to use all the familiar goodies of C++ along with all the new<br> goodies in .NET and the binding. "Clearly, market (ii) will be much happier with the more sugary extension such<br> 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.