Re: C++ Gurus - Is C++ a good choice for public API(s)??? Are there
clean ways to solve known problems there?
On May 31, 10:19 pm, ariji...@gmail.com wrote:
I needed to build up a public API for an application at hand.
The data I am modelling maps very well to object oriented design, so I
am little inclined towards a C++ public API (i.e. my deliverables
would be a <xyz>.hpp file which will have a bunch of pure virtual
functions forming the interface and a lib<xyz>.so which will basically
contain the implementation for those interfaces).
But, I can think of 2 problems there:
1) How do I guarantee that my shared library will work well with the
version of the C++ library/compiler my customer/user is having?
Issue in detail: I mean, I compile my shared library with version 'X'
of a Std CPP compiler and customer tries to use with version 'Y' of
StdCPP compiler. And then, if 'X' and 'Y' versions of CPP compiler are
not compatible, then we get into trouble. We have hit this several
times with different gcc versions. Just wondering, what is the best/
cleanest way to solve/get-around this problem?
If you ship a C++ interface, you will have to provide a different
binary for every different version of OS and compiler your clients
use. This is because C++ ABI differs across compilers and even
compiler versions (e.g. gcc3 vs gcc4, sunCC vs. sunCC -
library=stlport4).
On the other hand, if you ship a C interface, you will only need to
provide different binaries for each OS. This is because C ABI is
stable and your clients can link against your C API using any compiler
for that particular OS.
Note, that you can do OO design in C. For example, a C++ intreface:
struct Foo
{
int doSomething(int);
};
Would look like this in C:
struct Foo; /* incomplete in the public API */
Foo* fooCreate();
void fooDestroy(Foo*);
int fooDoSomething(Foo*, int);
2) Sometimes it happens that you are working on a C++ based product
which already has millions of lines of code and then, one fine day a
requirement comes that a part of that chunk needs to be made accesible
to users through a shared library. Now, which you work towards
building that shared library, you may want to ensure that only symbols
that *should be* exported to users/customers, needs to be exported in
the shared library, all others un-wanted globals should not be
exported in the shared library to ensure we don't un-necessarily
pollute customer's namesapce with whole lot of our internal/global
symbols. (Note: Ideal solution for this issue, probably would be to
ensure that we should never pollute our implementation namespace at
all, in the first place, but as I said, you may not be the one who had
written all these code and it's a million lines code, and you don't
have the option/bugdet for re-arch/re-write!). For such a requriement,
if it was a C library we could typically use 'objcopy' in linux or -M
compiler option in Solaris, to make sure only a given set of symbols
(defined by us) are made global. But if it's a C++ library, I wonder
how to achieve this goal?
By exposing a C interface, so that your .so only exports the functions
of the public C API, all other symbols are made local or stripped.
(Don't forget to statically prelink your .so with a C++ run-time, so
that your C API .so does not have any unresolved C++ run-time
symbols).
--
Max