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

[Samisa Abeysinghe]

James Clark wrote:
> 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.
>   
The strongest argument for using C++, as far as I feel, is the ability 
to use inheritance.
May be we can identify where we need inheritance and use C++ in those 
cases only.

One of the dangers I see in using C++ is the control we have to have on 
the level of use of C++ features. If we expect outsiders to contribute, 
we are very likely to run into situations where we have to have tight 
controls on what C++ constructs people are using. As the size of the 
software grows, this would become a pain on its own - even to verify 
patches. How are we going to plan for that?

Also, in case we decide to use C++, does that mean we also choose the 
'revolution' path in terms of current Axis2/C as opposed to 'evolution' 
path?

Samisa...
> James
>
>
> _______________________________________________
> Wsf-c-dev mailing list
> Wsf-c-dev at wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev
>
>