I'm also thinking about to write an application with an plugin system. So frase has destroyed my naiv dreams of an easy and object oriented interfacemodel. Yesterday i asked some fulltime c++ developer in my firm and they confirm with frase. No interfaces in standard c++. But what is with directx and office? They using interfaces and com. But com is only for windows and this interfaces are an microsoft extension for c++. So nothing for linux and com is needed.

Virtual Classes: Nearly 8 Years ago i worked in an firm they had an client/server application. Client was written in delphi and server in c++. The client used some dlls from the server (communications and more). And in these dlls we used virtual abstract classes. If the classes are correct all works fine. But if not its nearlly impossible to debug or find the error. All methods and parameters are sequentially stored in the VMT (Virtual Method Table). If the deklaration of one method is different the size of the definition (inside VMT) is different between delphi and c++. So calls to this or following function maybe jump somewhere else. It dosn't care if the definition of the method is correct. It's enough if one method before is incorrect. So in my old firm i spent a lot time in comparing sourcecode and try to find the differents. If you are still developing the interface it will change several times.

So if interfaces dosn't work and i still have bad dreams of virtual functions i think i will have an look at some plugininterface like sdl, libpng etc are using for they removeable codeparts. They using records with functionspointers. The plugin returns an record which contains some functionspointers. If you call some function from the record the first parameter has to be the record themselve. The record comes from the dll so the dll has the right to attach some additional data to the record. Inside the dll the functions from the record has to be global functions. But this functions take the pointer of the record (first parameter) and extract the delphi or c++ classes from it (additional data) and call the methods from the object. So the interface is c like and compatible to delphi and c++. This way meens more works inside the dll but if one function has different definitions only this functions is crap. I think i prefer something like this then. But i dosnt need really object in the plugin interface. Just my personal meaning.

Stucuk: stdcall is typical for windows api. If you wants to developing your application for several platforms (win, linux) you should better use cdecl. Many OpenSource librarys (also windows binarys) using cdecl as calling convention. The important thing is to have the same convention. The differents between dosnt care really much.

I was actualy using Virtual Abstracts with CDECL before i made the original post. I don't have any intentions of porting my current application, but i am trying to make more Generic classes this time which arn't application specific, so it would be best for me to make as much of the code portable just incase i use the code in the future for something.


If you write proper changelogs(I.E Each time you change something write it in the top of the file like the DGLOpenGL.pas has) then anyone making a plugin should be able to tell when you have changed a certain object's structure. So you shouldn't need to compare source code.

_________________
Free Map Editor - Game Requirements - Stucuk.Net
-Stu

This was primary more my meaning and what way i will prefer for my application.


Yes. Thats right. You have to log every little change. And if you miss only one you get errors on different places and not on the one they is wrong. That was the meaning of my story. Ive spent to much time for it.