Re: C++ Gurus - Is C++ a good choice for public API(s)??? Are there
clean ways to solve known problems there?
On Jun 1, 2:41 am, blargg....@gishpuppy.com (blargg) wrote:
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?
Write a C wrapper. If your interface were
class Interface {
public:
virtual int f( double );
};
Interface* new_foo();
you could write a C wrapper as
typedef struct Interface Interface;
Interface* xyz_new_foo( void );
void xyz_delete( Interface* );
int xyz_f( Interface*, double );
and it would be accessible from many languages.
This
If you then wanted C++
users to have a more convenient interface, you could provide a client-sid=
e
wrapper for the C interface. :)
and this. Specifically, provide a small wrapper class in a header only
that implements itself in terms of the C API, and give this header to
clients. The class will be compiled by the client's compiler, and all
calls to your library will go through a stable C API. You gain the
stability of the C API and a nice C++ interface class.
Note that it's not always convenient, reasonable or practical to do it
this way, but many times it is.