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.