22.07.2014 0:03, Tony Whyman wrote:
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
On 22/07/14 01:10, Jim Starkey wrote:
snip
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
On 07/22/14 04:10, Jim Starkey wrote:
I do have some questions:
1. Does it reflect a plan to introduce schemas, i.e. two level name spaces.
Yes. It's designed to be expandable to as many new field properties as
will be needed in the future.
It not, it should be rejected out of hand. The
22.07.2014 12:27, Alex Peshkoff wrote:
Reviewing API from this POV I've found 2 plain structures.
You missed message data buffer which IS a plain structure of non-documented
structure.
--
WBR, SD.
--
Want fast
21.07.2014 18:04, Alex Peshkoff wrote:
Ahh - it's related with multiple inheritance and rtti. Luckily we do not
use both in interfaces.
Just for clarity - besides that, we must neither use virtual destructors
nor overloaded methods to guarantee the stable vtable layout.
Dmitry
On 07/22/14 14:41, Dmitry Yemanov wrote:
21.07.2014 18:04, Alex Peshkoff wrote:
Ahh - it's related with multiple inheritance and rtti. Luckily we do not
use both in interfaces.
Just for clarity - besides that, we must neither use virtual destructors
Definitely not.
Instead dtor release()
On 22/07/2014 07:54, Alex Peshkoff wrote:
On 07/22/14 14:41, Dmitry Yemanov wrote:
21.07.2014 18:04, Alex Peshkoff wrote:
Ahh - it's related with multiple inheritance and rtti. Luckily we do not
use both in interfaces.
Just for clarity - besides that, we must neither use virtual destructors
22.07.2014 14:54, Alex Peshkoff wrote:
Not sure how does presence of overloaded methods affect stability of
vtable layout, but agree that we should better avoid them in public
interfaces.
Even if you put an overloaded method at the end of the interface, its
vtable entry will be placed in the
Two steps. First, define a pure virtual interface for C++. Second, machine
generate a flat, i.e. non-object interface for other languages.
Each will be easier to use that the current proposal from any language.
On Jul 22, 2014, at 5:11 AM, Tony Whyman tony.why...@mccallumwhyman.com
On 07/22/14 15:03, Adriano dos Santos Fernandes wrote:
On 22/07/2014 07:54, Alex Peshkoff wrote:
On 07/22/14 14:41, Dmitry Yemanov wrote:
21.07.2014 18:04, Alex Peshkoff wrote:
Ahh - it's related with multiple inheritance and rtti. Luckily we do not
use both in interfaces.
Just for clarity
Public interface objects should be reference counted with a protected virtual
destructor.
There are no issues with overloaded functions, though they do complicate the
mapping from object method to flat function names. On balance, it's probably
best to avoid them.
Rtti is intended to salvage
Why do you care? The vtable is an implementation artifact that by design and
architecture is invisible.
Stop trying to be cute. Use the language in the manner it was designed to be
used.
In nearly two decades of heavy C++, the only time I've even look at it is the
JVM side of JNI.
If you
My current AmorphousDB API (pure virtual) is defined without destructors. It
compiles and works just fine on Visual Studio 10 and whatever the current gcc
is on Linux.
Earlier versions of the compilers required the the inline definition of a
protected destructor to compile without warning.
22.07.2014 15:31, Jim Starkey wrote:
Why do you care?
If the C++ interface (pure virtual) is expected to be used outside the
Firebird project (by other C++ applications) or even by different
Firebird versions (e.g. newer server loading the older engine), then we
must care. You cannot extend
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,
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
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
21.07.2014 18:04, Alex Peshkoff wrote:
Ahh - it's related with multiple inheritance and rtti. Luckily we do not
use both in interfaces.
I didn't try your test app, but I can confirm the expected vtable layout
(at least for IProvider) in the debugger (for gcc 4.8.2).
As for Free Pascal, they
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
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
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
On 14/07/2014 15:29, Tony Whyman wrote:
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
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
14.07.2014 17:19, Adriano dos Santos Fernandes wrote:
But unfortunately, I think we did the thing wrongly.
It is not too late yet to withdraw the announcement about new official API
and win some
time to rethink these things.
--
WBR, SD.
DS 14.07.2014 17:19, Adriano dos Santos Fernandes wrote:
But unfortunately, I think we did the thing wrongly.
DSIt is not too late yet to withdraw the announcement about new official
API and win some
DS time to rethink these things.
Sorry if I'm mistaken, but afaiu, withdrawing it would
14.07.2014 19:56, Carlos H. Cantu wrote:
Sorry if I'm mistaken, but afaiu, withdrawing it would imply to not
have a way to create dbCrypt plugins in FB 3.0. If so, I think this is
not an option, since the (crypt) feature is already announced and very
expected by a lot of people.
It is easy
26 matches
Mail list logo
