Hello together!

After I sent the first Native NT patches to the bugtracker I found some time to test the cppclass-feature.

The following class compiles with 2.5.1:

   TestClass = cppclass
     procedure Test1; external 'cpplib.so';
     function Test2: LongInt; external 'cpplib.so';
   end;

The 'external' after each method is required as you can't add a 'external' after the class definition (I think I'll have to look at Jonas' objc branch to see how he solved that...).

Adding a method with a parameter results in an internal error 2103001. This is in symdef.tprocdef.cplusplusmangledname in the local method getcppparaname. The reason is the hidden self parameter which isn't checked for in cplusplusmangledname. I've attached a patch were I added a check for hidden parameters in the parameter-for-loop. If you think that patch is ok I'll post it to the bugtracker.

The following program compiles and runs (the result of Test2 is printed
- in my case 42 ^^), but there is a runtime error 217 after FreeClass (with "after" I mean that a Writeln after FreeClass is executed)

program cpptest1;
{$mode objfpc}{$H+}
type
   TestClass = cppclass
     procedure Test1; external 'cpplib.so';
     function Test2: LongInt; external 'cpplib.so';
     procedure Test3(aArg1: LongInt); external 'cpplib.so';
   end;
   PTestClass = ^TestClass;
function NewClass: PTestClass; cdecl; external 'cpplib.so';
procedure FreeClass(aUser: PTestClass); cdecl; external 'cpplib.so';
var
   c: PTestClass;
   i: LongInt;
begin
   c := NewClass; // internal error
   try
     i := c^.Test2;
     Writeln(i);
   finally
     FreeClass(c);
   end;
end.

The Pointer type is required, because a cppclass does not seem to be handled as a implicit pointer. When I don't use a pointer type I get an internal error 200301231 (x86/cpubase.cgsize2subreg) on the line "c := NewClass".
As I'd like to have a cppclass behave like a normal class, I'd like to know where I can setup a cppclass reference as an implicit reference inside the compiler.

All in all I have the following goals for (my) future work on this:
* make a cppclass an implicit pointer
* use only one "external 'foo'" after the class declaration

Regards,
Sven

PS: when answering, please CC me, because I'm using digest mode :)

All in all I have the following goals for (my) future work on this: * make a cppclass an implicit pointer

I don't like this idea because C++-classes aren't an implicit pointer either.

At first I wanted to disagree with you... philosophing about the Pascal way of doing things, bla, bla...

But after 8 km of deep thinking (as I'm riding those by bike, I have much time :) ), I came to the conclusion that you are right. We are interfacing with a foreign language here and if we are in Rome, we shall do as the Romans do...

so: forget the idea of implicit pointers ^^

Another question though: Do you want me to write tests for the compiler for this feature (e. g. those in the tests directory)? If so, how do you suggest to write those tests, especially as they (currently) rely on a external library...

Regards,
Sven

Pascal has also objects which are no pointers ;)

Yes, this is also my point.

tests/test/tcppclass1.pp, tcppclass2.pp etc.

If so, how do you suggest to write those tests, especially as they (currently) rely on a external library...

Libraries or object files? FPC does similiar testing for C linking: the C sources are checked in into
http://svn.freepascal.org/svn/fpc/trunk/tests/test/cg/obj/ Compiled object files lay in the appropriate sub dir of this dir.

Testing C++ class linking should be done similiar imo.

Hi again!

I know... I know... that might have contributed a bit to my decision to give up implicit pointers ^^

In theory that is possible, but I found a practical problem: C++ code requires libstdc++ or at least libsupc++ which implements the "new" and "delete" operators. And to make things worse: this library isn't available in the Windows release of the compiler... (not a real problem for me as I'm working on Linux...)

While I could be able to simulate the needed functionality of the library through Pascal units with correct named procedures/functions, I don't think that this is the way to go. A better solution (at least for compiler tests) would be to just compile but not link those test units. Does the test framework support such an option?

The following is the syntax I'm currently trying to implement:

TMyTestClass = cppclass
   procedure MyTestMethod1;
   procedure MyTestMethod2; name 'SecondMethod';
end; external 'foolib.so' name 'MyTestClass' namespace 'Foo::Bar';

This corresponds to this C++ class interface:

namespace Foo::Bar {
class MyTestClass {
public:

       void MyTestMethod1();
       void SecondMethod();
   };

}

The "external foo name bar"-part should be pretty easy (thanks to Jonas' objc branch which enabled me to find the right spots to include my code ^^ ). The 'name' for methods shouldn't be that complicated, too. But for namespace support I'll need to introduce a new keyword "namespace".

Any comments on this proposal?

Because of the LLVM thread, I think I'll also check the LLVM API to order the priority of needed features (e. g. virtual methods).

Greetings,
Sven

A lot name mangling etc. can be tested without new/delete: just make the classes static. Further, fpc must be able to create c++ classes on the heap anyways.

Yes, but this is imo a bad idea, better get it running with some hacking.