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


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.



Comments (2)

  1. AlisdairM says:

    "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."

    I’m not sure how relevant this is for the average code-writer, as if you depend on a CLI class, the interface you depend on introduces the CLI syntax, so you are already in a non-ISO world. I guess you can forward declare classes that later turn out to be CLI-based in the implementation, so CLI does not leak through a public interface unless those features are used.

    However, there is a significant benefit for generic code, as all those templates that manipulate pointers will just work with CLI types as well. That will be a big gain.

  2. Nemanja Trifunovic says:

    "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. "

    I believe you meant the other way around. I use Managed C++ for (i), and all I do is author new __gc types.