I agree with Jim is probably the easiest way to respond to this. I have
no interested in shooting down the C++ API - I just want to ensure that
Firebird continues to be accessible from other languages and a handle
based API is the easiest lowest common denominator.
I would just add that C++ is notoriously binary incompatible between
different C++ compilers and the worse cases are those that appear to be
the same - but with minor differences. When binaries are published the
C++ compiler and version supported needs to be very clearly stated and
my point about exporting 'fb_get_master_interface' as a C++ function may
well be the easiest way to protect the innocent.
Tony Whyman
MWA
On 15/07/14 13:56, James Starkey wrote:
> There appears to be an impass: The desire to define an interface in
> C++ and the problems of cross compiler and cross language access to
> the API. Here are some thoughts.
>
> First, defining an API as an abstact object interface is the correct
> approach. The original 30 year old interface took exactly this
> approach, but as OO language didn't yet exist, the API used handles to
> represent abstract objects rather than waiting for C++ and vtables to
> be invented. Subsequent database systems have used either a C++
> binding of JDBC (adequate, bordering on OK) or a formal "pure virtual"
> interface (Amorphous).
>
> The problem of cross compiler issues is very easy to overstate. There
> are only two signficant C++ compilers -- gcc and Microsoft (OK, Intel
> has a compiler, but is Microsoft compatible). And the two compilers
> only coexist on a single platform, Windows. But even there, each
> compiler is careful to define incompatible globals so it is not
> possible to intermix potentially incompatble object modules. There is
> no reasonable that the client side API could not be compiled twice,
> once with the Microsoff compiler an once with gcc. No big deal.
>
> Use of the API with other languages is, however, problematical, but
> has a simple solution: Define an ultra-thin layer properly layered on
> the C++ API modelled on the original API: Add a handle pointer on
> each analog of an interface method function. It should take somebody
> the better part of a morning with time off for coffee. If this isn't
> trivial, then there is something terribly wrong with the new API that
> should be fixed, ASAP.
>
> Trying to convince other language to interpret a C++ interface or
> vtable is a fool's errand. The Java Native Interface (JNI) worked
> around it by defining a non-OO interface that "just happened" to be
> compatible with both the MS and gcc compilers (this was not always so:
> gcc originally put the vtable pointer at the end of an object, which
> was so dim that even the gcc guys noticed). Even so, JNI is a pain in
> the butt to implement, and I strongly recommend against this approach.
>
> In summary, I believe the original approach to the API is correct -- a
> pure virtual interface is the correct interface methodology. Other
> languages can be accomodated by a thin, non-OO, layered interface.
>
>
> --
> Jim Starkey
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
>
>
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
