Re: C++

* James Kanze:


Not sure which one you're referring to.


Windows has two (platform-) standard ABIs, namely COM and .NET. These
are language-independent ABIs, but COM was mainly designed for C++, with
extensions (called "OLE Automation", essentially the interface IDispatch
plus associated types) for Visual Basic and scripting languages.
Neither COM nor .NET supports C++ templates, so, essentially, the C++
standard library can only be used internally by components.

The cost of providing a component as a COM component is high, with
technical impact on three main areas. First, for the interface,
foregoing all use of the C++ standard library and all use of templates.
  Second, for the interface, designing all exposed classes with default
construction and init-method (required by COM) -- even though this is
technically only a question of wrapping a soundly designed class in an
unsound one, that wrapping is in practice so costly itself that it isn't
done, so that COM impacts directly on the design level. Third, adding a
lot of COM-specific machinery (in particular, the support for use of the
component from scripting languages), which must be sprinkled at all
levels of the code. To help with that Visual C++ provides a lot of
language extensions, in particular an #import directive, UUID-support
and so called "attribute" programming, attributes in square brackets
that in general serve to automatically generate COM support code.

With the cost so high one may may wonder whether COM is used at all.
The answer is that COM is so entrenched at all levels of Windows (like
DOS was... ;-)) that there's no way around. E.g., if you're scripting a
web page, then with execution of that script in Internet Explorer nearly
all the objects you're handling are COM objects (some made in C++), and
the scripting engine itself is a collection of COM objects (which would
likely have been written in C and/or C++). And for other platforms, the
basic COM design has been adopted in other ABIs, such the ABIs of
Mozilla software (XCOM) and in Linux GUI (I don't recall the name).
This means that COM's happily making a lot of both Windows and
non-Windows software extremely complex in order to provide a little bit
of interoperability, so little that generally you don't notice...

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.

In addition to having two different .NET specific C++-derived languages
(or language extension sets) to deal with, interfacing with the Windows
API generally requires involving COM, the older ABI...

It's about the same as going down to C in other C++ programming.

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.

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?