I disagree both with the interface design and this critique. Neither, to my
experience, makes any sense.
It is the normal to define interfaces as pure virtual classes, in short, as
abstract interfaces. The Java guys had the intelligence and insight to define
language constructs that define abstract interfaces. It is a pity that C++
hasn't picked up with basic idea in 15 years, but there you have it.
The argument that a pure virtual interface is compiler specific has no merit.
The various C++ implementations have take the necessary and obvious steps so
that object modules compiled with different compilers cannot be mixed. There
is no risk of compiler incompatiblities if the objects modules can't be mixed.
A pure virtual interface in gcc works with a library compiled with gcc. A pure
virtual interface in the MS compiler works with a library compiled with the MS
compiler. Neither works with a library compile with an incompatible compiler.
This has been pointed out and can be experimentally verified. To come back
time and time again with a bogus agument (are you listening, Tony?) does no one
any service.
The argument against a pure virtual interface is that it is language specific.
This is corect. It is both convenient and rigorously correct for a C++ program
to use a pure virtual interface. It is also crazy for a non-C++ program to
attempt to use an implicit and invisible vtable. Crazy, nuts, insane, bonkers.
It makes no sense to inconvenience all programnmers to avoid showing trivial
(and formal) favoritism to C++. C++ and Java are the winners; the other
languages, less so. It makes complete sense to define a natural and easy to
use interface for C++ and machine generate a flat interface for all other
languages.
As mentioned, I'm off in the wilds of maritime Canada with an insane cellular
data plan that is $25/100MB, so despite kind and thoughtful suggestions, I
don't have access to the new interface. I do have some questions:
1. Does it reflect a plan to introduce schemas, i.e. two level name spaces.
It not, it should be rejected out of hand. The rest of the database world
accepted that name space control as obligator a decade and a half ago.
Changing the interface without make it better, i.e. future proof, makes no
sense.
2. Does the new interface get rid of fixed interface structures? I introduced
them 30 years ago for compatibility with DB2 as the only published dynamic SQL
interface. This was a terrible mistake. The SQLDA, friends, and relations
were, are, and always will be disasters. Static data structures become
obsolete in a blink of an eye. The history of Firebird is sufficient living
proof. The API has been changed many times without making it better.
Gentlemen, it is time to learn from past failures.
3. A good interface has strict differentiation from structure and semantics.
A bad interface requires incompatible tweaking with the semantics are extended.
4. Do all interface objects have methods to interogate the object (not API!!)
version? If not, how can the object me made upwards compatible?
>From what I have seen, the new interface is neither compatible nor well
>thought out. It looks to me like it will be a condidate for replacement in
>the next major version. I believe a new, better, more general, extensible is
>warranted. Don't blow it.
> On Jul 21, 2014, at 7:03 PM, Tony Whyman <tony.why...@mccallumwhyman.com>
> wrote:
>
> 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
------------------------------------------------------------------------------
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
