Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2005-01

VMT compatibility

13 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Alexey Barkovoy

Hi,

I where any chance to see FreePascal generating VMT's for classes that is more compatible with C++ / TurboPascal / Delphi one?
To explain mine question: recently I've been porting Delphi framework interfacing to C++ code to FPC and finded out that althrow Delphi VMT layout is compatible to C++ one, FPC is not. Let's see two examples: (1) is C++ and (2) is pascal one. In Delphi and C++ DoSomething method is located at ZERO offtet in VMT (i.e. PPointer(Self)^ == address of DoSomething). In FreePascal DoSomething is located with offset of 80 bytes (i.e. @PPChar(Self)^[80] == address of DoSomething).

(1)
typedef class IMyClass
{
public:

        __cdecl virtual void DoSomething()=0;

} *lpMyClass;

(2)
type
  IMyClass = class(TObject)
  public
    procedure DoSomething; virtual; cdecl; abstract;
  end;

Regards,
Alexey Barkovoy

Reply by email

Jonas Maebe
to Alexey Barkovoy
Alexey Barkovoy wrote 5 lines
I where any chance to see FreePascal generating VMT's for classes that is more compatible with C++ / TurboPascal / Delphi one? To explain mine question: recently I've been porting Delphi framework interfacing to C++ code to FPC and finded out that althrow Delphi VMT layout is compatible to C++ one, FPC is not.

Are you sure Delphi is compatible to "C++" or just to Borland C++? The latter would be logical, since both Delphi and C++ Builder use the same backend. Or are Delphi classes also binary compatible with Visual C++ and g++ classes?

Jonas

Reply by email

Alexey Barkovoy
to Jonas Maebe
Show quoted text 9 lines
> I where any chance to see FreePascal generating VMT's for classes that is > more compatible with C++ / TurboPascal / Delphi one? > To explain mine question: recently I've been porting Delphi framework > interfacing to C++ code to FPC and finded out that althrow Delphi VMT layout > is compatible to C++ one, FPC is not. Are you sure Delphi is compatible to "C++" or just to Borland C++? The latter would be logical, since both Delphi and C++ Builder use the same backend. Or are Delphi classes also binary compatible with Visual C++ and g++ classes?

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.

Alexey

Reply by email

Alexey Barkovoy
to Alexey Barkovoy
Show quoted text 14 lines
>> I where any chance to see FreePascal generating VMT's for classes that is >> more compatible with C++ / TurboPascal / Delphi one? >> To explain mine question: recently I've been porting Delphi framework >> interfacing to C++ code to FPC and finded out that althrow Delphi VMT layout >> is compatible to C++ one, FPC is not. > > Are you sure Delphi is compatible to "C++" or just to Borland C++? The latter > would be logical, since both Delphi and C++ Builder use the same backend. Or > are Delphi classes also binary compatible with Visual C++ and g++ classes? 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.

PS. I'm not insisting for compatibility on "internal" fields (with negative offset in Delphi case), but hope for layout compatibility of user defined virtual methods.

Reply by email

Michael Van Canneyt
to Alexey Barkovoy: Delphi is compatible at least with Borland C++ and MS VC++. And taking in accout how COM…
Alexey Barkovoy wrote 14 lines
>> I where any chance to see FreePascal generating VMT's for classes that is >> more compatible with C++ / TurboPascal / Delphi one? >> To explain mine question: recently I've been porting Delphi framework >> interfacing to C++ code to FPC and finded out that althrow Delphi VMT layout >> is compatible to C++ one, FPC is not. > > Are you sure Delphi is compatible to "C++" or just to Borland C++? The latter > would be logical, since both Delphi and C++ Builder use the same backend. Or > are Delphi classes also binary compatible with Visual C++ and g++ classes? 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++;

Michael.

Reply by email

DrDiettrich
to Alexey Barkovoy: Delphi is compatible at least with Borland C++ and MS VC++. And taking in accout how COM…
Alexey Barkovoy wrote
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.

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.

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

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?

DoDi

Reply by email

Alexey Barkovoy
to Michael Van Canneyt: That would be true only for interfaces, not for straight VMTs ? And Delphi's VMT's are…

----- Original Message -----
From: "Michael Van Canneyt"

Show quoted text 12 lines
> 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.

Earlier message 38 lines
----- Original Message ----- From: "DrDiettrich" > 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

Reply by email

Florian Klaempfl
to Alexey Barkovoy
Alexey Barkovoy wrote 28 lines
----- Original Message ----- From: "Michael Van Canneyt" >> 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.

Show quoted text 48 lines
----- Original Message ----- From: "DrDiettrich" > 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 - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Alexey Barkovoy
to Florian Klaempfl

----- Original Message -----
From: "Florian Klaempfl"

Show quoted text 7 lines
> 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.

Problem is here:

Show quoted text 7 lines
> 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.

Delphi and FreePascal simplest interfaces already includes IUnknown. So using raw interfaces is incompatible here too.
Actually I have working solution and it's based as you hinted on interface feature of object pascal, but after quering interface a have to patch object instance so pointer to VMT start pointing above IUnknown part of it. Something like this:

var
  AllocI: ID3DXAllocateHierarchy_Interface;
begin
  AllocI:= pAlloc;
  // Now patch interface VMT - so it will point to truncated interface (without
IUnknown)
  Inc(PInteger(AllocI)^, $C);
  // Call C++ function and pass to it our "special" interface
  Result := D3DXLoadMeshHierarchyFromX_FPC_{$}(Filename, MeshOptions,
pD3DDevice, AllocI, pUserDataLoader, ppFrameHierarchy, ppAnimController);
  Dec(PInteger(AllocI)^, $C); // Patch interface VMT - BACK
end;

But I really want FPC be compatible with Delphi in this situation.

Reply by email

Marco van de Voort
to Alexey Barkovoy
Show quoted text 8 lines
// Call C++ function and pass to it our "special" interface Result := D3DXLoadMeshHierarchyFromX_FPC_{$}(Filename, MeshOptions, pD3DDevice, AllocI, pUserDataLoader, ppFrameHierarchy, ppAnimController); Dec(PInteger(AllocI)^, $C); // Patch interface VMT - BACK end; But I really want FPC be compatible with Delphi in this situation.

If I recall correctly, this was all done because the linker had problems with symbols with negative offsets.

Reply by email

Michael Van Canneyt
to Alexey Barkovoy: ----- Original Message ----- From: "Florian Klaempfl" Problem is here: Delphi and…
Alexey Barkovoy wrote 23 lines
----- Original Message ----- From: "Florian Klaempfl" >> 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. Problem is here: >> 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. Delphi and FreePascal simplest interfaces already includes IUnknown. So using raw interfaces is incompatible here too.

No.
You could try to use CORBA interfaces, they don't have IInterface (or IUnknown) as the parent. There is a compiler switch for this.

Michael.

Reply by email

Michael Van Canneyt
to Marco van de Voort: If I recall correctly, this was all done because the linker had problems with symbols…
Marco van de Voort wrote 11 lines
> // Call C++ function and pass to it our "special" interface > Result := D3DXLoadMeshHierarchyFromX_FPC_{$}(Filename, MeshOptions, > pD3DDevice, AllocI, pUserDataLoader, ppFrameHierarchy, ppAnimController); > > Dec(PInteger(AllocI)^, $C); // Patch interface VMT - BACK > end; > > But I really want FPC be compatible with Delphi in this situation. If I recall correctly, this was all done because the linker had problems with symbols with negative offsets.

This is correct. In combination with smartlinking, I think.

Michael.

Reply by email