The point is not how specific C++ compilers behave, it is that there is
no standard for a vtable layout, and you cannot publish an interface
that depends on disassembling the output of an example compiler, and
expect it to be a stable interface to work with. The compiler devs will
change the vtable layout whenever they see a need to do so, roll the ABI
version number, and regard it as your problem and not theirs when code
that depends on their internal structures fails.
There is nothing necessarily wrong with publishing an interface that is
a table of function pointers - but if that is what you want then that is
how you should define it and not as a C++ class hierarchy albeit limited
to virtual functions.
The problem that you have when accessing the current FB3 API from
another programming language is that you have to make assumptions about
the vtable layout of the C++ compiler used to compile the shared object
and somehow map it into your programming language structures. This
problem becomes multiplied for portable code by every platform/target
compiler that you need to support, as each will need to be verified.
Every time a new version of the compiler comes out, the vtable will need
to be checked to make sure that it hasn't changed.
This is asking too much of the Firebird user, especially when the
solution is so straightforward.
Tony Whyman
MWA
On 21/07/14 15:04, Alex Peshkoff wrote:
> On 07/21/14 17:09, Dmitry Yemanov wrote:
>> 21.07.2014 16:32, Alex Peshkoff wrote:
>>
>>> 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.
>> >
>> > [snip]
>> >
>>> in C++ we get exactly same binary layout for any known to us C++ compiler.
>> Is this really so? This is why I'm asking:
>>
>> https://gcc.gnu.org/ml/gcc-help/2003-11/msg00257.html
> Please pay attention to the year when a question was asked - probably
> this is what Jim mentions about vtable position in the end of an object?
> Anyway such old versions make no practical interest for us.
>
>> http://stackoverflow.com/questions/5712808/understanding-the-vtable-entries
>>
>> i.e. GCC has a different vtable layout and moreover it's version-dependent.
> Ahh - it's related with multiple inheritance and rtti. Luckily we do not
> use both in interfaces.
>
> The test I've written some time ago to check how does interface upgrade
> run at different systems does work with C++ classes as with pure virtual
> interfaces - this is what makes possible to upgrade interface version.
>
> http://web.firebirdsql.org/download/rabbits/alex/checkAbi.tgz
>
> Run
> sh build.sh
> ./ldr
>
> Expected output is:
> C1-f1
> C1-f2
> int 75
> C2-f1
> C2-f2
> C2-f3
>
> I've rechecked it right now starting with
> gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) // was used to
> build FB 1.5,
> definitely 32-bit std RH8 layout, and ending with
> gcc version 4.8.2 (GCC) // was used to build FB3 Alpha2
> 64-bit compiler.
> Both work as expected.
>
>> As for Free Pascal, they also reserve 12 bytes at the beginning of the
>> vtable, hence the compatibility issue.
> 12 byte? On 64-bit system?
> They are crazy!
>
>
> ------------------------------------------------------------------------------
> 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
