C++/CLI keywords: Under the hood

C++/CLI specifies several keywords as extensions to ISO C++. The way they are handled falls into five major categories, where only the first impacts the meaning of existing ISO C++ programs. 1. Outright reserved words As of this writing (November 22, 2003, the day after we released the candidate base document), C++/CLI is down to…


Why “gcnew T” instead of “new (gc) T”?

On comp.lang.c++.moderated, Peter Lundblad wrote: I also don’t see the need for gcnew. Why not use placement new, i.e.: T^ h = new (CLI::gc) T(14); This would require an extension allows placement new overloads to return something other than void* and a standard way to get to the raw storage where to construct the object….


C++/CLI candidate base document now available

Today the C++/CLI candidate base document was posted, and it’s freely available for download. This is the spec that Microsoft is contributing to the newly-formed ECMA TC39/TG5 standards committee for consideration for the C++/CLI standards process. It covers all the main proposed features, and it gives a pretty thorough look at the scope and shape…


Why R^ instead of cli::handle?

Nicola Musatti asked the following excellent question: The hat symbol and gcnew could be replaced with a template like syntax, e.g. cli::handle<R> r = cli::gcnew<R>(); I agree that those are alternatives. Everyone, including me, first pushes hard for a library-only (or at least library-like) solution when they first start out on this problem. I think…


Why “ref class X”, not just “class X : System::Object”?

On comp.lang.c++.moderated, Andrew Browne wrote: The goals of the C++/CLI proposal are good ones, I think, but I wonder if it would be possible to achieve them without (most of) the new keywords and semantics? For example instead of: ref class R {/*…*/};        // CLR reference type value class V {/*…*/};     //  CLR value type…


Q: Why keywords instead of __keywords? A: We already tried __keywords; they failed.

Last week on comp.lang.c++.moderated, Nicola Musatti wondered why C++/CLI would use keywords that don’t follow the __keyword naming convention for conforming extensions: The standard already provides a way to avoid conflicts when introducing new keywords: prepend a double underscore. Right, and that’s what Managed C++ used, for just that reason: to respect compatibility. Unfortunately, there…


Q: Aren’t C++ pointers alone enough to “handle” GC? A: No.

A few days ago on news:comp.lang.c++.moderated, Nicola Musatti wrote: As for GC, pure implementations exist. [that add no new extensions to ISO C++] Not for a pure definition of “pure,” they don’t. 🙂 To explain why C++ pointers are insufficient (unless their semantics were to be changed at least a little, which would mean breaking existing…


Q: Could the CLI binding become required? A: No.

A few days ago on news:comp.lang.c++.moderated, “Chris” asked: Here is a paranoid question: Is there a possible future step, where compiling C++ on a Microsoft plaftform becomes impossible _without_ using the CLI binding? No. Doing that would mean throwing away all the ISO conformance work that Visual C++ just spent nearly the whole last release…


Help | About

Welcome! My primary day job these days is that I’m an Architect on the Visual C++ team at Microsoft, currently responsible for leading the redesign of the C++ Managed Extensions for .NET (aka “Managed C++”). I also do a fair amount of other C++ writing and speaking (including right now busily writing two new books due out in the…