The ABI compatibility (including C, Delphi [but not sure about FPC] and C++ in HP-UX) was tested a number of times, IIRC by Nikolay, Vlad, me and Alex.
But unfortunately, I think we did the thing wrongly. Till now I don't know what's the better way to work with status vector. Who should initialize, caller or called function? What if a function is called with a marked as error status vector? The idea as I see was to create something like IDL (with macros or with a self-made compiler) and have C++ wrappers around the interfaces (with may be defined in C). But now even internally, we have manual checks of status vector everywhere, which is not C++. The inconsistencies with status vector initialization, and the way to report warnings, was a big factor for these problems we have, including guessing all ABIs would be compatible. Adriano Em 14-07-2014 10:29, Tony Whyman escreveu: > Yesterday I posted an appeal for help with suggestions on using the new > Firebird 3 API from a Free Pascal program, mainly to see if I had missed > something in my analysis of the new interface. I did get one pointer to > "UIB". However, that did nothing more than confirm my suspicions that > there are some serious problems with the API as presented in the alpha 2 > release. > > In summary, I have the following issues with the new Firebird 3 API: > > 1. It is a C++ Object Oriented API and needs to be understood as such. I > have no problem with it as a C++ API, but it is not a general purpose > API and does not provide platform/compiler/language independence. As > presented in 'firebird/interface.h', the API provides pointers to C++ > Classes and is always dependent on the vtable layout internal to each > C++ compiler. > > 2. There is no such thing as a standard ABI or even a standard C++ ABI > and you cannot rely on the output of one compiler being able to navigate > the vtable produced by another, or even by a different version of the > same compiler. > > 3. A regular feature on the Free Pascal wish lists is the ability to use > C++ shared objects from Pascal. If it were simply a matter of defining a > canonical class structure in Pascal and passing pointers to classes then > this would be easy. Unfortunately it is not. UIB contains such a > canonical set of classes, translating the C++ Firebird 3 API classes > into Pascal, getting a pointer to IMaster and taking it from there. This > may work if the C++ and Pascal compilers have the same ABI and this may > even be the case with some Windows compilers (the UIB code was specific > to Windows). However, I tried it out with FPC 2.6.4 on 64-bit Linux and, > as expected, it didn't work. The ABIs are not compatible enough. (Note: > For C++Builder to work, it has to come with Delphi and Borland C++ > compilers with compatible ABI - this is maybe why the UIB code appeared > to work on Windows). The current status of calling C++ from FPC is > summarised here > http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-How-to-access-C-and-C-libraries-td4036118.html. > > > 4. 'fb_get_master_interface' should be exported as a normal C++ function > and not extern 'C'. By exporting it as extern 'C' you lose the > protection offered by Name Mangling and which alerts the user to > potential ABI incompatibility - and which avoids lots of hard to find > "bugs". > > 5. If a C++ interface is provided by the Firebird Client then the number > of binaries available will need to multiply exponentially as different > versions of the client library should be provided for each > platform/compiler variation available including different versions of > the same compiler with a different ABI. > > 6. The Firebird 3 API is a low level C++ API in the sense that the > database data is passed in an unstructured buffer. It begs the question: > if a C++ API is offered then why not offer a higher level API at the > level of say, Oracle OCCI or Firebird's very own IBPP. Indeed, given > that IBPP is effectively the standard C++ interface to Firebird then why > not integrate it into the Firebird library? Note: the IBPP maintainers > recommend compiling IBPP into each project rather than making it > available as a standard library - this might have something to do with > ABI compatibility issues. Note: Oracle OCCI is only available/supported > on a strictly limited set of platforms. > > 7. The release notes present the current API as a "legacy API". If this > is true then reliable use of new Firebird features is restricted to C++ > - which is undesirable. > > 8. The release notes also criticise COM interfaces for performance > reasons. I will not necessary argue with this but do observe that COM is > an open, reliable and compiler independent API (for Windows) and there > may well be performance costs associated with this. > > 9. All APIs will have some ABI dependencies and to meet the criteria for > "open, reliable and compiler independent" these need to be minimised by > keeping to a very known and widely supported calling convention and > limited well defined data types. This is what COM does (on Windows). > This is what the existing 'C' interface to Firebird does. Firebird 3 > needs such an API. Unfortunately, an API based on pointers to C++ > classes does not meet that requirement. > > Tony Whyman > MWA > > > ------------------------------------------------------------------------------ > 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
