[fpc-devel] VMT compatibility

[Alexey Barkovoy]

----- Original Message ----- 
From: "Michael Van Canneyt" <michael at freepascal.org>

>> Delphi is compatible at least with Borland C++ and MS VC++. And taking in 
>> accout
>> how COM intefaces are implemented in C++ (I'm supposing here all C++ 
>> compilers
>> support the same syntax) - each C++ compiler supporting MS way to declare COM
>> interfaces has compatible VMT layout.
>
> That would be true only for interfaces, not for straight VMTs ?
>
> And Delphi's VMT's  are not compatible with GCC's;
> At least, kylix cannot use GCC classes.
> I'm not even sure they are compatible with the ones from MS Visual C++;

Well, interfaces are really C++ abstract classes. COM model adds some bell and 
whistles above that (including IUnknown that is integrated in object pascal 
language interfaces).

For example "DECLARE_INTERFACE_(IClassFactory, IUnknown)" in C++ is expanded to 
"struct FAR IClassFactory : public IUnknown", so really public parts of VMT 
(with positive offset) are always [should be] compatible. Surely we can't talk 
about FULL compatibility of classes, but exposing "interfaces" to other 
languages should be possible.


----- Original Message ----- 
From: "DrDiettrich" <drdiettrich at compuserve.de>


> The layout of C++ classes is compiler specific. In so far BCB and MSVC
> may be compatible, or MSC and BC, but only for specific compiler
> versions.
>
> OPL (fpc, Delphi...) classes are different from C++ classes, not only in
> the VMT layout, but also in other significant details. That's why BCB
> provides special support for TObject based classes, but these classes
> still are different from the C++ classes.

Yes, VMT implementation of private fields are different in C++ and pascal. And 
public parts of VMT are compatible for ALL versions of MS and Borland C++ 
compilers!

> COM (ActiveX...) is not related to C++, it defines another object model,
> data types, and class layout.

This is totally incorrect statement. Inprocess COM is heavy relayed on C++ 
abstract classes. I'm not talking here about ActiveX (it's really just a 
framework above COM), marshalling, etc.

> If you really need portable classes, then you should use COM/ActiveX on
> Windows, or possibly CORBA for more platform independence. Though I
> don't know whether fpc supports CORBA?

Problem here is what I'm forced to use some these COM incompatibe "interfaces" 
exposed by MS programmers in DirectX API. These interfaces look like real COM 
interfaces but without IUnknown embedded. In Delphi I can use them just by 
creating abstract class just like in C++, but in FPC it's impossible to do so. 
And I've seen other reports when people were forced to use similiar cripped 
interfaces exposed by C++ programmers. So it's the real problem not just 
artificial one.

Regards,
Alexey Barkovoy