Page History

...

The C bindings must reside in a shared library or DLL, as required by the method(s) used by various languages to interact with C code.  They can either be incorporated into their own library, or compiled into the existing native client library.  There is a tradeoff in this decision between ease of use on the part of an end-user and ease of use for developers of language bindings.  We will initially use a separate library, and make a final decision after the team has had some experience with the new code and binaries.Our initial plan to organize the code is as follows:

i. Code for C bindings shall reside in the existing geode-native repository

ii. The code for C bindings will be organized under its own top-level directory, alongside the existing cppcache and clicache directories, with separate include directory for public headers and src directory for the implementation.

iii. The C bindings will consume the geode-native classes as a static library, rather than importing them from a shared library.  

iv. Only C bindings will be exported from the new shared library, i.e. geode-native C++ classes will be hidden

We will be adopting a specific naming convention for the C bindings to attempt to ensure unique names, since we can't take advantage of namespaces.  Tentatively, we will prefix function names with `apache_geode_`, followed by 'Create' for methods that allocate a 'class instance', i.e. an opaque context pointer, and 'Destroy' for the dealloc/free function.  For class methods, we will use 'apache_geode' + class name + '_' + method name.  As a trivial example, a partial CacheFactory implementation with just new/delete and the method getVersion would be exported via C functions as follows:

apache_geode_CreateCacheFactory

apache_geode_CacheFactory_getVersion

apache_geode_DestroyCacheFactory

Performance Impact

Any performance impact of calling through a C binding should be very minimal.  A C function exposing a native client method should only involve a pointer cast and a call to the "wrapped" C++ API.  Additionally, there will be no performance impact whatsoever for existing applications, since we're not proposing to modify any of the existing C++ code.  Eventually we should be able to benchmark the C vs C++ calls to quantify the performance difference, but this is a fairly low priority.  Benchmarking API performance from another language calling through the C bindings is a much more interesting and necessary task, which we believe will be undertaken as part of any future support for said language.

...