I was at vacations when this discussion took place and therefore could
not take part in it in time. Let me try to answer some questions that
appear important to me too.
First of all - formal definition of API is certainly not a set of C++
classes. Each firebird interface is a single pointer, pointing to the
table of virtual functions that are contained in this interface. First
parameter of each function is always a pointer to an interface itself.
This definition in plain english may be rewritten in C:
struct ISample
{
struct VTable
{
void functionOne(ISample* this, Type1 par1, Type2 par2, /*
other parameters */);
void functionTwo(ISample* this, TypeA parA, TypeB parB, /*
other parameters */);
/* other functions ... */
};
VTable* vTable;
};
Such definition of pure virtual interface should work and be correct for
any working C compiler.
I've specially repeated this trivial and well known thing here - just to
be able to state that all C++ tests (not sure how is Delphi related)
mentioned here by Adriano
> 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.
were to make sure that writing
class ISample
{
virtual void functionOne(Type1 par1, Type2 par2, /* other
parameters */) = 0;
virtual void functionTwo(ISample* this, TypeA parA, TypeB parB,
/* other parameters */) = 0;
/* other functions ... */
};
in C++ we get exactly same binary layout for any known to us C++ compiler.
It's definitely a guess but somewhy I think that professional in any
programming language can easily describe such data structures using his
favorite language.
> 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?
This is very serious question, but it's _absolutely_ unrelated with
mostly discussed here interface layout. I suggest to continue with it in
separate thread.
>
> 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).
It's very hard to say something against such reasonable suggestion. One
desire - make it better compatible with debuggers than gpre.
> But now even internally, we have manual checks of status vector
> everywhere, which is not C++.
If we agree that we use C++ classes only as a method to describe pure
virtual interface layout requirement to have everything as '++' as
possible becomes less strict. As a minimum it's not a showstopper.
Please do not treat it as suggestion not to try to find better ways to
check status. BTW, I suppose with mentioned IDL this problem is also
decidable?
> 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.
Do not see any links between status vector/warnings and ABI compatibility.
>
> 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
no
c++ is just used as a convenient way to describe pure virtual interfaces
>> 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.
It's not documented (btw, was documented by MS approx 15 years ago - if
you find MSDN disks so old you will see that pure virtual interface
descriptions in C and C++ were that time mentioned as exactly same)
>> 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.
Sorry, not:
>> The ABIs are not compatible enough.
but:
fpc + uib produces layout not matching low-level pure virtual interface
description
g++ compatibility for linux64 has no problems, historically first checks
were done exactly for it
>> (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.
This question should be asked not here but at FPC forums/lists. I can
only suggest to access pure virtual interfaces from free pascal programs
using C-style. I did not work with pascal for >20 years but as far as I
remember it should be possible. Can you have a function/procedure
pointer in pascal?
>>
>> 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".
Once again - we still did not find any incompatibilities in C++ classes
using them to describe pure virtual interfaces. Mentioned function is
described exactly as all the rest of our (old) API calls.
I omit the rest cause it relies on the wrong fact that fb3 API is C++
API - it's language independent, C++ classes is just an easy to use and
de facto portable way to describe it.
------------------------------------------------------------------------------
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
