Re: C++
In message <fprp8f$jl2$02$1@news.t-online.com>, Rolf Magnus
<ramagnus@t-online.de> writes
Alf P. Steinbach wrote:
[...]
For .NET the situation isn't quite that bad because .NET is a more
modern VM-based ABI. However, also for .NET, language extensions are
key to managing the inherent complexity as seen from the C++ level. And
Microsoft defines 2 sets of such language extensions: "Managed
Extensions" for .NET is the older one, and "C++/CLI", essentially a new
/language/ that is a superset of C++, is the currently favored one.
I have no idea why anyone would use "C++/CLI".
If you need to provide a .NET interface layer wrapping existing C++
code, it's the only option.
Either use real C++, or use
C#. Essentially "C++/CLI" looks to me like C# pressed into a syntax that is
closer to C++, but isn't really C++.
But you can use it as a glue to bind .NET classes and "real" C++. It's a
mess, but sometimes it's the only way .
The C++/CLI language is essentially the brainchild of the chair of the
international C++ standardization committee Herb Sutter (he was the lead
architect), plus, .NET isn't completely restricted to Windows (the Mono
project, sponsored by Novell, "provides the necessary software to
develop and run .NET client and server applications on Linux, Solaris,
Mac OS X, Windows, and Unix"), so I don't think we should forget .NET as
C++ ABI, even though .NET is language independent.
It will never become "the single C++ ABI", considering that it's not based
on translating the C++ source code directly to native code.
Exactly. The CLI abstract machine doesn't provide efficient ways of
doing some things that C++ takes for granted.
--
Richard Herring