[fpc-devel] VMT compatibility
F.Klaempfl at gmx.de
Sun Jan 30 11:23:32 CET 2005
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++
>>> 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
>> 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.
> Alexey Barkovoy
> fpc-devel maillist - fpc-devel at lists.freepascal.org
More information about the fpc-devel