Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
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.
Comments
- Anonymous
December 15, 2003
"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. - Anonymous
December 18, 2003
"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.