[fpc-devel] VMT compatibility

[Florian Klaempfl]

Alexey Barkovoy wrote:
> ----- 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.

Use raw interfaces for such a purpose.

> 
> 
> ----- 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
> 
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel