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

[Damitha Kumarage]

James,
 In one of your early mails I found the following
"

We would hope to have Axis2/C eventually becoming a standard system
shared library shipped with major distributions.  Binary application
packages will use the binary of the shared library included with the
distribution instead of their private version. This means we need to
think seriously about not just API compatibility between versions but
A*B*I compatibility between versions.  This is one of the big wins of C
over C++: you can have real ABI compatibility."

So it seems that using C++ means some A*B*I compatiblity issues. 
Damitha


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.
>
>James
>
>
>_______________________________________________
>Wsf-c-dev mailing list
>Wsf-c-dev at wso2.org
>http://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev
>
>  
>