Alexey Barkovoy wrote:
----- Original Message ----- From: "Michael Van Canneyt"
<[EMAIL PROTECTED]>
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"
<[EMAIL PROTECTED]>
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@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
