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.
