> On Mar 30, 2020, at 10:32 AM, Blake Bender <bben...@pivotal.io> wrote:
>
> Just want to +1 on the use of a dynamic library - this really has to be a
> shared lib, interop with most other languages demands it. On the other
> hand, I'm not a huge fan of making this a separate library from the native
> client itself, simply because proliferation of binary files makes life
> difficult for our users. native client on Windows already uses a
> mixed-mode assembly to avoid having separate C++ and .net DLLs, *and* we're
> potentially lugging around cryptoimpl with us if someone wishes to use
> SSL. Adding another library just for C bindings makes for a clean
> separation of the APIs, but I'm not certain how much value this adds, and
> it definitely adds complexity to any installation/setup.
To be clear I don’t think Mathew or I are suggesting the the C++ dynamic
library be dynamically linked to the C dynamic library so that your language
binding or application have to dynamically load both libraries. I would suggest
that the C library statically link the C++ library and hide the symbols from
export. This prevents users from seeing or using anything we haven’t written a
C wrapper for. I think statically linking to the C++ library is going to be
required anyway in order for the C library to use non-exported internals to
address issues like serialization between languages. For example, region
methods that take raw byte* that contain the serialized form of the data. These
methods wouldn’t be exposed via the C++ library exports.
The other rational for keeping them separate is that I wouldn’t want to mix the
C and C++ headers into my application. The C and C++ gods will clash and all
hell will break loose.
-Jake
