[wsf-c-dev] Use of C++

[James Clark]

If you build a C++ shared library that makes unrestricted use of C++,
then it will have a runtime dependency on the shared C++ library.  If we
do that, then we're basically doomed especially on Linux (see
http://plan99.net/autopackage/Linux_Problems#cxx).

To avoid taking a runtime dependency implies the following restrictions:

1. no use of the Standard C++ library (and I mean *none*, no STL, no
iostreams, nothing)
2. no use of global operator new/delete
3. no use of of exceptions
4. no use of RTTI (including no dynamic_cast)
5. no static constructors/destructors

Restriction 2. is not as bad as it sounds. You just define an empty
class Base which provides operator new/delete. If class Foo is derived
from Base, then new Foo will use Base's operator new/delete rather than
the global new/delete.

There's also a certain amount of effort needed to ensure that the right
compiler-dependent options are used to disable exceptions/RTTI and to
avoid linking in the normal C++ library.

A bigger issue is how you do the API.  One possibility is to do a pure C
API.  That is, you use extern "C", and the API looks exactly like an API
that would be provided by a library implemented in C.  This combined
with the above restrictions on C++ can give you a shared library that
is indistinguishable from something written in C.  The big problem with
this approach is extensibility.  If you want to provide extensibility
through dynamically loading shared libraries, it's going to be very
awkward if those shared libraries have to interact with everything else
through a pure C API. Similarly, if you want to split things into
multiple independent shared libraries, then it would be awkward to have
those libraries communicate without using any C++ functionality.

However, once you allow shared libraries to export APIs that use C++
features, then you get problems.  First of all, there are problems
especially on Linux with a shared library exporting certain constructs
in C++ that have what's called "vague linkage"; these include template
instantiations and inline functions
(see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1976.html#problem_04). Second, all the functionality needs to be accessible from C, so you'll end up doing a pure C alternative to any C++ functionality in the API.

There are non-technical issues as well:

- because of all the restrictions, the C++ that we would write would be
unidiomatic, and probably unappealing to people who like C++

- there's a significant segment of the open source community that is
virulently anti-C++

- C++ has become an extremely complicated language with many traps for
the unwary; use of C++ would be an extra barrier that potential
contributors must overcome

Of course, use C++ has substantial benefits.  Particularly, I would
mention

- support for object-orientation (no more manual coding of vtables)

- destructors, which when used appropriately are a very effective way of
avoiding memory leaks.

If we do decide to stick to C for the shared library, we should provide
a C++ veneer for it.  The veneer would consist purely of header files
(nothing in a shared library) providing a thin C++ layer on top of the
shared library, which made it more pleasant and natural to use from C++.

So what's the conclusion? I think there are good arguments for and
against C++.  I have a view, but I would like to hear other people's
opinions first.

James