C++/CLI (Ecma 372) support in Clang

Hi,

What is the opinion of the list / community in regards to adding
support for the C++/CLI language standard to Clang?

More info about it: http://en.wikipedia.org/wiki/C%2B%2B/CLI

I've started adding some early parsing support for C++/CLI, but would
like to know if this is something that would be accepted. The syntax
also overlaps a bit with the new C++/CX extensions used in WinRT, so
some of it can be reused.

PS: I know someone already did some work on it
(http://www.atoker.com/blog/2012/04/12/llvm-europe-2012-cli-compiler/)
but since open sourcing that work does not seem on their plans, I'd
like to work a little on this.

Hi,

What is the opinion of the list / community in regards to adding
support for the C++/CLI language standard to Clang?

More info about it: http://en.wikipedia.org/wiki/C%2B%2B/CLI

I suspect that opinions on the list will differ, so I think it's good to have this discussion.

I've started adding some early parsing support for C++/CLI, but would
like to know if this is something that would be accepted. The syntax
also overlaps a bit with the new C++/CX extensions used in WinRT, so
some of it can be reused.

My personal opinion is that C++/CLI is not a good match for Clang. It's a fairly extensive and complicated extension to C++, and it seems unlikely that Clang will ever actually be a useful C++/CLI compiler. Moreover, the advent of C++/CX and the recent push toward native code makes the long-term future of C++/CLI completely unclear, and I'd rather not have us chasing yesterday's technology.

C++/CX seems like a more reasonable goal for Clang as a project, because (1) it's more conceivable that we could actually provide a useful C++/CX compilation environment, and (2) it seems to be the new direction for Microsoft. Plus, I think it might be a little smaller and, therefore, slightly easier to implement.

  - Doug

It's a fairly extensive and complicated extension to C++, and it seems unlikely that Clang will ever actually be a useful C++/CLI compiler. Moreover, the advent of C++/CX and the recent push toward native code makes the long-term future of C++/CLI completely unclear, and I'd rather not have us chasing yesterday's technology.

Native and managed code have different advantages, so I don't see
managed code getting replaced by native code soon. What I see is
native code being used for the lower level parts of software where
performance really matters, with a managed layer for extensibility-
and C++/CLI is the bridge. I do get your point though, and agree that
the drawbacks might outweigh the benefits.

C++/CX seems like a more reasonable goal for Clang as a project, because (1) it's more conceivable that we could actually provide a useful C++/CX compilation environment, and (2) it seems to be the new direction for Microsoft. Plus, I think it might be a little smaller and, therefore, slightly easier to implement.

In terms of complexity, they both seem really similiar syntax-wise. MS
has re-used most of their previous work on C++/CLI for C++/CX, here is
a summary of differences:

Basic types:
CLI: From mscorlib.dll (System::* types)
CX: From vccorlib.dll (Platform::* types)

Lifetime management:
CLI: Garbage collected
CX: Refcounted

Cycles Broken:
CLI: By garbage collector
CX: Broken by user (weak references or explicit delete)

Code generation:
CLI: MSIL + native code. Can create a cross-platform binary if MSIL-only.
CX: Native code only. Binaries target a specific platform.

Object Creation:
CLI: gcnew
CX: ref new

interior_ptr:
CLI: Supported
CX: Not supported

pin_ptr:
CLI: Supported
CX: Not supported

V% (% when it refers to a byref (kind'a like an "interior_ref") ):
CLI: Supported
CX: Not supported

R% (% when it refers to an implicitly dereferenced ref type):
CLI: Supported
CX: Supported

Ref to ^:
CLI: R^%
CX: R^&

Boxing:
CLI: syntax V^
CX: IReference<V>^

Dereferenced box type:
CLI: V%
CX: const V

Generics:
CLI: Generics classes, interfaces & delegates allowed.
CX: Generic interfaces & delegates only.

Static constructors:
CLI: Supported
CX: Not supported

Address of member of ref class:
CLI: Returns an interior_ptr
CX: Returns a type*

friends:
CLI: Not supported
CX: Supported

C++ class embedded in ref class:
CLI: Not supported
CX: Supported

ref class embedded in C++ class:
CLI: Not supported
CX: Supported (R-on-stack)

^ embedded in C++ class:
CLI: Not supported (Needs GCHandle)
CX: Supported

^ embedded in value class with value class on native heap:
CLI: Not supported
CX: Supported (for String^)

Global ^:
CLI: Not supported
CX: Supported

Global R-on-stack:
CLI: Not supported
CX: Supported

Finalizer:
CLI: Supported
CX: Not supported

Destructor:
CX: Runs on IDisposable::Dispose (delete / stack unwind) only
CLI: Runs on IDisposable::Dispose (delete / stack unwind) -or- last
release (never both)

T::typeid:
CLI: Supported
CX: Not supported

It's a fairly extensive and complicated extension to C++, and it seems unlikely that Clang will ever actually be a useful C++/CLI compiler. Moreover, the advent of C++/CX and the recent push toward native code makes the long-term future of C++/CLI completely unclear, and I'd rather not have us chasing yesterday's technology.

Native and managed code have different advantages, so I don't see
managed code getting replaced by native code soon. What I see is
native code being used for the lower level parts of software where
performance really matters, with a managed layer for extensibility-
and C++/CLI is the bridge. I do get your point though, and agree that
the drawbacks might outweigh the benefits.

Just so my point hasn't been lost: for the Clang community, I believe that C++/CX is both more tractable and more useful than C++/CLI.

C++/CX seems like a more reasonable goal for Clang as a project, because (1) it's more conceivable that we could actually provide a useful C++/CX compilation environment, and (2) it seems to be the new direction for Microsoft. Plus, I think it might be a little smaller and, therefore, slightly easier to implement.

In terms of complexity, they both seem really similiar syntax-wise.

Syntax is the easy part.

MS
has re-used most of their previous work on C++/CLI for C++/CX, here is
a summary of differences:

Lifetime management:
CLI: Garbage collected
CX: Refcounted

Clang has lots of infrastructure for dealing with refcounted types (see Objective-C ARC) that could easily be generalized. GC would require quite a bit of work.

Code generation:
CLI: MSIL + native code. Can create a cross-platform binary if MSIL-only.
CX: Native code only. Binaries target a specific platform.

Targeting MSIL, and doing it well, would be a pile of work.

Ref to ^:
CLI: R^%
CX: R^&

This makes my eyes bleed :frowning:

Generics:
CLI: Generics classes, interfaces & delegates allowed.
CX: Generic interfaces & delegates only.

Eliminating generic classes simplifies semantic analysis and IR generation quite a bit.

  - Doug

For Windows 8 the WinRT projections for .NET and C++/CX seem to replace C++/CLI.

http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-690C

Best regards
Mello

I don't see how "replace" is a suitable verb, as one is for targetting a
rather strange and locked-down toy platform, while the other is for
producing good native interop for the .NET platform, for real native
applications.

The only relation between C++/CLI and C++/CX is the prefix.