: I'm developing a software product with a C++ API.
: My concern is how to design the API so that future versions of the API
: will be binary compatible with applications that use the older API
: version.
:
: E.g., suppose a customer application calls version 1 of the API. I
: develop version 2, which has more public methods and variables. How can
: I make sure that the old application works properly with the new API
: version, without forcing the customer to recompile the appl?
:
: The API should work on Windows + Unix, so I cannot use COM to resolve
: this problem.
The C++ language is well specified at the source code level,
but the object code is totally up to the implementation.
One issue is that class layout could change from release to
release of your libraries.
Another one is that on some platforms (notably x86), some
compilers do not use the same ABI (e.g. implementation and layout
of virtual functions, name mangling, exceptions, etc)
[ => incompatibility of Borland C++ and VC++ ].
Last but not least, on almost every platform, different compilers
(and even consecutive releases of the same development environment)
use implementations of the C++ standard library that differ
in class layout: so unless the exact same tool chain is used,
you cannot use std::string or any container/iterator in your
interface.
So if you distribute your library in binary form,
prepare for a serious challenge...
Very few (large) C++ libraries are distributed in binary form.
The famed BeOS is a notable exception. But Be controlled the
platform (defined ABI and library). Yet it had to use special
tricks to allow for future extensions (such as adding dummy
unused virtual functions to work around the Fragile Base Class
issue).
In my previous job I was developing high-level interface libraries
for haptic devices (
www.xitact.com). Although everything was
developed in C++, I have pushed for providing a pure C interface
( within #ifdef __cplusplus extern "C" { #endif etc.
Implement opaque object handles that are internally converted
to a class instance to which calls are forwarded within
a try...catch(...) clause ).
This definitely was the right choice.
Initially, we did provide a C++ interface in source code form,
as a thin wrapper over our C-called interface DLL.
But our experience confirmed that different customers/developers
all wanted in any case to provide their own kind of wrapper
around our library, and would be encapsulating our interface
within their own C++ class in any case.
So they would end up going straight to the C api level.
If you really want to provide a C++ interface AND distribute
your library in binary form only, be prepared to re-compile
your library for every customer who will want to use it.
I wouldn't want to head in this direction.
And as a potential customer, I wouldn't tolerate such a level
of vendor-dependence either...
I hope this helps, Ivan