Question

Application is written in delphi 2010 and the underlying dll is a C++ dll.

In ideal case, when your application is in C++; The dll makes a callback to an application when an event occurs. The callback is implemented through an interface. Application developers implements the abstract c++ class and pass the object to the dll. The dll will then make a callback to a member function of your implemented class. A classic callback pattern it is.

But how do I pass a delphi object to the dll for it to make a callback.

Answer 1

I wouldn’t really call that ideal. It is selfish and short-sighted to make a DLL that requires its consumers to use the same compiler as the DLL used. (Class layout is implementation-defined, and since both modules need to have the same notion of what a class is, they need to use the same compiler.)

Now, that doesn’t mean other consumers of the DLL can’t fake it. It just won’t be as easy for them as the DLL’s designer intended.

When you say the callback is implemented through an interface, do you mean a COM-style interface, where the C++ class has nothing but pure virtual methods, including AddRef, Release, and QueryInterface, and they all use the stdcall calling convention? If that’s the case, then you can simply write a Delphi class that implements the same interface. There are many examples of that in the Delphi source code and other literature.

If you mean you have a non-COM interface, where the C++ class has only pure virtual methods, but not the three COM functions, then you can write a Delphi class with the same layout. Duplicate the method order, and make sure all the methods are virtual. The Delphi VMT has the same layout as most C++ vtables on Windows implementations, at least as far as the function-pointer order is concerned. (The Delphi VMT has a lot of non-method data as well, but that doesn’t interfere with the method addresses.) Just be sure you maintain clear ownership boundaries. The DLL must never attempt to destroy the object; it won’t have a C++-callable destructor that the delete operator could invoke.

If you mean that you have an arbitrary C++ class that could include data members, constructors, or non-pure methods, then your task is considerably more difficult. Follow up if this is the case; otherwise, I’d rather not address it right now.

Overall, I’ll echo Mason’s advice that the DLL should use plain C-style callback functions. A good rule of thumb is that if you stick to techniques you see in the Windows API, you’ll be OK. If you’re not in control of how to interact with the DLL, then so be it. But if you can make the DLL’s external interface more C-like, that would be best. And that doesn’t mean you need to abandon the C++-style interface; you could provide two interfaces, where the C-style interface serves as a wrapper for your already-working C++style interface.