I know it's been asked before, but I ask again because maybe the answer will be different this time.
How can I code an external assembly routine as an object method? And is it possible to declare a C++ object and import it into Pascal or vice-versa without having to re-write the code?
See ya! Orlando Llanes
"Meine Damen und Herren, Elvis hat soeben das Gebaeude verlassen!"
"Look out fo' flyeeng feet" O__/ a010111t@bc.seflin.org /|____. O <__. /> / \ ____________|_________ http://ourworld.compuserve.com/homepages/Monkey414
According to Orlando Llanes:
How can I code an external assembly routine as an object method?
If your object reads
MyObj = object Procedure MyMethod; virtual; (* or not virtual - that's not the question ;*) end (* MyObj *);
then your external assembly routine must be named
Myobj_Mymethod
with one capital letter at the beginning of the object's and the method's name, each. Parameter and return value conventions are the same as with GNU C.
And is it possible to declare a C++ object and import it into Pascal or vice-versa without having to re-write the code?
That's possible, but not recommended. All OOP info gets lost on the transport between both languages; you have to import a Pascal method from C++ using names like described above, manually invoke virtual methods through the VMT, etc. In the other direction, you have to declare C++ methods through cryptic `AsmName' declarations ... it's a pain. Better write some non-OOP wrapper functions.
If someone understands the GNU C++ OOP backend, we could perhaps change this. Perhaps. It might also be that, due to the way multiple inheritance is implemented in C++, GPC's code is more efficient and should therefore better stay like it is.
Peter
On Sun, 3 May 1998, Peter Gerwinski wrote:
then your external assembly routine must be named ... the same as with GNU C.
Thank you!!! 8~) The dream of OOP <sniffle, wiping tear from eye> is once again reality =B) BTW, I found that external assembly routines (I'm using NASM) allow one to use the EBP register as long as its value is preserved at the start of the routine and restored at the end. To reference the values on the stack, I used [ESP+8] for the first parameter, [ESP+n] for the next ones.
If someone understands the GNU C++ OOP backend, we could perhaps change this. Perhaps. It might also be that, due to the way multiple inheritance is implemented in C++, GPC's code is more efficient and should therefore better stay like it is.
This brings me to another question. I don't care too much for C++ OO in GPC, tho it might be cool to find a subset OO of both Pascal and C++ objects and at least support that. Which brings me to my question, let's say I have the Win32 port of GPC, is it possible to write DirectX applications? The reason I ask is because a lot of DirectX is written in C++ OO.
See ya! Orlando Llanes
"Meine Damen und Herren, Elvis hat soeben das Gebaeude verlassen!"
"Look out fo' flyeeng feet" O__/ a010111t@bc.seflin.org /|____. O <__. /> / \ ____________|_________ http://ourworld.compuserve.com/homepages/Monkey414
According to Orlando Llanes:
This brings me to another question. I don't care too much for C++ OOin GPC, tho it might be cool to find a subset OO of both Pascal and C++ objects and at least support that. Which brings me to my question, let's say I have the Win32 port of GPC, is it possible to write DirectX applications? The reason I ask is because a lot of DirectX is written in C++ OO.
As I said, I recommend to write a non-OOP wrapper. You can do it in a clever way such that the C++ wrapper functions carry names that are directly recognized as the names of methods of a Pascal object by GPC.
But I cannot seriously believe that DirectX shall not be accessible without OOP, is it? I suspect that the standard API libraries are written as a C++ class library, but those should be ported or rewritten for Pascal anyway. Somebody knows?
Peter
-
Orlando Llanes -
Peter Gerwinski