Subject Re: [Firebird-Architect] Re: External procedures: implementation
Author Jim Starkey
Vlad Horsun wrote:

> I found that pure-virtual classes with all stdcall methods worked
>fine at least between MSVC 7.1 and Delphi 6 and Delphi 9. If it will
>not work on another platform or compiler we can implement plain C
>functions on the top of this classes and export it. Something like
That's probably true because Delphi decided to mimic the Microsoft C++
and COM convention of putting the virtual function vector pointer as the
first word in an object. The Java Native Interface (JNI) does the same
thing. Gcc/g++, however, put the virtual function vector pointer after
the data items. C++ is official agnostic about implementation issues,
so there is no standard.

>>For engine extensions, I don't have any problem defining the interface
>>using C++ classes. If somebody wants to produce an external procedure
>>facility in Delphi, for example, it's not big deal to expect them to
>>code a tiny interface modules to handle the calling sequence coming in and throwing the proper exceptions on the way out.
> Oh no, please, exceptions must not cross unit boundaries. There are
>mechanism to carry exception information (better than status vector, i hope).
>So - all exceptions must be handled in compilation unit which raised it
You're right. Exception can't cross link boundaries with any
certainty. The status vector is the way to go for the call to the
external procedure facility. I would hope that any facility that
supported exceptions would adopt exceptions as the preferred method to
signal an error, but I agree this is an internal issue to the facility.

I'll take on the error reporting issues a little later.

[Non-text portions of this message have been removed]