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
>below:
>
>
>
>

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]