Subject | Re: [Firebird-Architect] XSQLDA/XSQLVAR issues |
---|---|
Author | Jim Starkey |
Post date | 2005-01-12T15:48:39Z |
Dimitry Sibiryakov wrote:
discussion off to a good start.
First, the insult. Personal insults are part of the Internet tradition
and practice. Most insults disguise their insults in subtly or
cleverness or, at a minimum, include them at the end of the post after
demonstrating their own superior knowledge and intelligence. Dimity,
had you been paying attention, you would be aware than I use three
families of compilers on a daily basis: Visual Studio (version 6 for
Netfrastructure, version 7 for Vulcan, and version 8 for self abuse),
gcc (32 and 64 bit, versions 2.96 to 3.34), and the Solaris Forte
compiler. Had you been paying closer attention, you would have learned
that I wrote and support a Java Virtual Machine that spans two of those
platforms. Now, to you, perhaps, it is "obvious" that I only use one
compiler. But it is also wrong. So we must conclude, DimItry, that not
all that you consider obvious is in fact true, something that might give
you pause.
problem is not new. What COM (or DDE as the guys who invented it called
it) and the Java Native Interface (JNI) do is define an object as what
the C++ committee prosaically calls POD ("plain old data"). An object
starts with a pointer to a virtual function pointer vector followed
private data. By sheer coincidence (not), this also the layout of
Microsoft C++ objects. It's a mess in g++, which uses a different layout.
Exceptions should be thrown as object, described above. That mechanism
by which the API throw exception objects could include a callback to
perform the dirty deeds.
Vulcan uses C++ interfaces among components. The provider interface
and the security plugin are both examples. The policy is that all
components on a platform must be compiled with the same compiler
family. The external API, however, must be defined as a C interface for
any number of reasons including object layout, location of the virtual
function vector, and linker name mangling. That said, we still want the
API to be as C++ friendly as possible, as C++ is now the implementation
language of choice.
I wish I had an off the cuff answer to mapping a POD defined object into
a g++ class, but I don't. If anyone has any deep insight, I'd like to
hear about it.
There are probably other strategies worth exploring. But the
polymorphism and encapsulation properties of an object API do justify
the effort to solve the problems.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>On 7 Jan 2005 at 10:26, Jim Starkey wrote:Ah, nothing like a gratuitous personal insult to get a rollicking
>
>
>
>> 3. Exception based: Exceptions are thrown, not returned as
>> vectors or status codes.
>> 4. Object oriented: interface objects (SQL strings, data messasges)
>> are passed as objects
>>
>>
>
> Last two items obviously show that you work with only one compiler.
>
>
discussion off to a good start.
First, the insult. Personal insults are part of the Internet tradition
and practice. Most insults disguise their insults in subtly or
cleverness or, at a minimum, include them at the end of the post after
demonstrating their own superior knowledge and intelligence. Dimity,
had you been paying attention, you would be aware than I use three
families of compilers on a daily basis: Visual Studio (version 6 for
Netfrastructure, version 7 for Vulcan, and version 8 for self abuse),
gcc (32 and 64 bit, versions 2.96 to 3.34), and the Solaris Forte
compiler. Had you been paying closer attention, you would have learned
that I wrote and support a Java Virtual Machine that spans two of those
platforms. Now, to you, perhaps, it is "obvious" that I only use one
compiler. But it is also wrong. So we must conclude, DimItry, that not
all that you consider obvious is in fact true, something that might give
you pause.
> Are you sure that binary representations of object are the same inI said object oriented. I don't believe I even mentioned C++. The
>Borland and MS compilers (not to mention Intel and GNU zoo)? Have you
>ever tried to use object, created in MSVC-compiled DLL from BCC-
>compiled program? Or you are talking about COM?
>
>
problem is not new. What COM (or DDE as the guys who invented it called
it) and the Java Native Interface (JNI) do is define an object as what
the C++ committee prosaically calls POD ("plain old data"). An object
starts with a pointer to a virtual function pointer vector followed
private data. By sheer coincidence (not), this also the layout of
Microsoft C++ objects. It's a mess in g++, which uses a different layout.
Exceptions should be thrown as object, described above. That mechanism
by which the API throw exception objects could include a callback to
perform the dirty deeds.
Vulcan uses C++ interfaces among components. The provider interface
and the security plugin are both examples. The policy is that all
components on a platform must be compiled with the same compiler
family. The external API, however, must be defined as a C interface for
any number of reasons including object layout, location of the virtual
function vector, and linker name mangling. That said, we still want the
API to be as C++ friendly as possible, as C++ is now the implementation
language of choice.
I wish I had an off the cuff answer to mapping a POD defined object into
a g++ class, but I don't. If anyone has any deep insight, I'd like to
hear about it.
There are probably other strategies worth exploring. But the
polymorphism and encapsulation properties of an object API do justify
the effort to solve the problems.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376