Delphi libs can be used in C++ ?

[JernejL]

P.S: all exported DLL routines need STDCALL calling conventions

don't be uninformed.. you can use ANY calling convention, as long as they match in C and pascal, most libraries actually use cdecl.

[Pyrogine]

Hi, maybe you can try this:

1. Create a class in Delphi with all virtual methods. Use STDCALL for compatibility.

2. Create the same class in C++ with all virtual methods. Make sure the methods are in the same order. Again, use STDCALL.

3. Export a routine in the Delphi DLL to create/destroy instances of your classes. In my implementation I pass an integer ID to tell which class I want.

4. Pass the pointer of the C++ class in and it will return a fully qualified object that you can then use in C++ or any language that supports standard COM.

5. When your done, pass the object pointer to the destroy routine to free the class instance. (needed because of memory management and DLL boundary issues)

6. This works because Delphi supports COM which means the VMT (virtual method table) is binary compatible (laid out in memory the same) with the VMT of the C++ class.

7. What I've also done too was to export these interfaces out of the DLL and on the host side wrap them up (in this case Delphi classes) in classes so that I can extend them just like a normal class.

This gives you a lightweight (and much easier) COM across different languages. There are a number of articles on the NET about this concept for more information.

Hope this helps.

[arthurprs]

chronozphere:~
.lib are a file that C/C++ compilers use for static linking, and its required on win

pyroengine:~
im not returning an int, but the class pointer, take a look at the demo, returning a int is best?

i don't know how create them from an existing dll, so im now using dynamic loading to avoid using them

i will use pure virtual classes, easy and works well

after some search and some tests its done
http://www.mediafire.com/?5bd9ydbj992
(60kb demo including binary and source)

again sorry my english

[Pyrogine]

The ID is the integer id of the class you wish to create. So you only have to export two routines from you DLL. If you have a CreateInterface type routine where you pass the ID and it will create an instance of the object and return it to the calling application. Like such:

procedure CreateInterface(aIID: Integer; var aObj); stdcall;
begin
  case aIID of
    0: TMyClass0(aObj) := TMyClass0.Create;
    1: TMyClass1(aObj) := TMyClass1.Create;
  end;
end;

procedure DestroyInterface(var aObj); stdcall;
begin
  FreeNilObject(aObj);
end;

You now have a factory that can create and return any of the interfaces you support.

[arthurprs]

I was saying that you only have to export two routines from you DLL. If you have a CreateInterface type routine where you pass the the ID and it will create an instance of the object and return it to the calling application. Like such:

procedure CreateInterface(aIID: Integer; var aObj); stdcall;
begin
  case aIID of
    0: TMyClass0(aObj) := TMyClass0.Create;
    1: TMyClass1(aObj) := TMyClass1.Create;
  end;
end;

procedure DestroyInterface(var aObj); stdcall;
begin
  FreeNilObject(aObj);
end;

You now have a factory that can create and return any of the interfaces you support.

sorry my english, now i understand ops:

a very good tip! Thanks


Edit: i don't understand the "var aObj" where is the type ?

[Pyrogine]

NP, glad to help.

Note: if you get an AV on the C++ side or if you find that when you call a C++ method it seems to be calling the wrong method from the DLL side, keep in mind the the order and number of virtual methods much match (you do not have to have all of them, but down to the one you are calling must match). Remember that TObject defines a few virtual methods by default where as a C++ class does not. So you may have to create a few dummy methods on the C++ side. Look at the TObject class implementation in the System.pas unit for the version of Delphi you are using. The latest version of Delphi (d2007) has I think 3-4 virtual methods in TObject including Destroy. So keep this in mind if you have problems on the C++ side.

[Pyrogine]

var aObj allows you to pass any type as a variable parameter. Otherwise the compiler will complain about the wrong types. This is the same technique used by the FreeAndNil routine. If the param for this routine was a TObject type for example it would complain saying the types much match for a var param when you tried to FreeAndNil any type of class other than TObject.

When you pass a var param you are able to make changes to inside the routine which is what we will be doing. So to prevent bad things from happening the compiler make sure the types match. By specifying an unknown type, you are saying, bypass strict type checking and I will be responsible for the object types myself.

[arthurprs]

NP, glad to help.

Note: if you get an AV on the C++ side or if you find that when you call a C++ method it seems to be calling the wrong method from the DLL side, keep in mind the the order and number of virtual methods much match (you do not have to have all of them, but down to the one you are calling must match). Remember that TObject defines a few virtual methods by default where as a C++ class does not. So you may have to create a few dummy methods on the C++ side. Look at the TObject class implementation in the System.pas unit for the version of Delphi you are using. The latest version of Delphi (d2007) has I think 3-4 virtual methods in TObject including Destroy. So keep this in mind if you have problems on the C++ side.

Is there something that i can do to avoid that?

[Pyrogine]

If you use TObject (class) you will have to deal with the dummy methods because as I've stated, TObject automatically defines a few virtual methods. But, you can use the old object declaration rather than class, then you do not have to worry about the dummy methods.

[pascal]TMyClass = class vs. TMyClass = object[/pascal]

NOTE, the old object interface is not guaranteed to be around in future version of Delphi so you have use at your discretion. You loose some benefits but like I said, there are no default virtual methods defined so it will be 1 to 1 like a pure virtual c++ class.

You can also use interfaces (TMyClass = interface) which is very easy to do in Delphi as interface support is build into the language, but it gets hairy and narley on the C++ side.

If you do use interfaces, then what I've done is to disable automatic reference counting by overriding AddRef/Release to do nothing in my base interface class. Then I can build a hierarchy of interfaces just like you would do a normal class and continue to use deterministic destruction. In this case, I was using Delphi on both sides.

But all you have to do is add the dummy methods to your c++ base class once. No big deal compared to what you gain, but yes they will be there and if someone tries to call one of them it will call the methods that corresponds to the ordered ones on the Delphi side.

So in summary:

1. You can use pure virtual methods using class - you have to deal with the dummy virtual methods on the host side.

2. You can use pure virtual methods using object - it will be 1 to 1 on the c++ side, but you loose all the automatic stuff of TObject.

3. You can use pure interfaces - easy to do on Delphi side, kinda of a pain to setup/use on the c++ side. You have to use macros and other shenanigans.

4. You can export flatten methods from the dll - easy and simple, but when the number of routines become large it becomes a pain to manage.

Over the years I've tried each one and various combinations. All have pros and cons. You have to decide which one will work for you. It would be so much easier if Delphi had better support for this. Sure packages, but its those HUGE run-time DLLs that I don't want to distro with my games. RTL + VCL package dll become larger than some of our downloadable games. Arrrg. I've been struggling with these problems for a long time. If you put the RTL and VCL into your own package and link to it at run-time, fine, but then your run-time package can not be used with other packages as the same units can not exist in multiple packages. Again, arrrg. So.... *sigh* you have pick something that works for you and go with it.

[arthurprs]

C++ are good but some things makes me hate it :evil:

i will stay with "1. You can use pure virtual methods using class - you have to deal with the dummy virtual methods on the host side. "

i just need to declare create, destroy etc.. on the c++ class ?

thanks for your attention you are giving me a HUGE help