如何使用在 dll 中的 exe 中实现的类

Question

I am building a simple game engine and a game in it. The idea is to have most of the functionality and basic class hierarchy implemented in the engine which should be an exe and then to have a dll which will implement specific game given the tools the engine provides. Similar to id engines such as idTech4 .

The engine would then load the dll, acquire an instance of the game, give the game pointers to whatever functions and data structures the game needs and call methods such as game->update(); on the game instance. So far so good.

I would like to have things like basic classes like Entity, Transform, Vector3 etc. implemented in the engine. Then in the game what I want is to for example derive my character from Entity.

class Character: public engine::Entity {...};

Things like this compile all right since I include the headers from the engine but they do not link since I do not use the obj files nor the cpp files form the engine. I know why this does not work. As far as I know my (reasonable) options are:

1. Make these classes header only - this way it will always compile everywhere.

I don't want this since it would increase compile times, binary size etc.

2. Put the common functionality into a lib or a dll.

This would work, but a lib file would mean that I have the same classes compiled (linked) both in the exe (engine) and dll (game) - this seems sloppy. Dll would work but it seems like a lot of work with all the exports and imports I would need to do to both the engine and game. Also probably most importantly both lib and dll approach share common issue which is that during development I may end up moving various class a lot from and to them since the class hierarchy may change a lot etc.

My question is, is there another way around this? For me this seems like a pretty useful feature to have a hierarchy of classes in exe usable from a dll. I tried even very silly things such as making the linker use the .obj files generated during engine compilation, but it did not work unless I specified all .obj files one by one (I am using Visual Studio 2017).

I do not want to give up the modularity of this design.

Edit : As dlls are platform specific let's consider Windows (although I guess other platforms would be similar).

Answer 1

It sounds like you are wanting to utilize dynamic loading, but I think you might have things flipped around the wrong way. The exe usually has the game code and the .dll has the game engine logic and classes. You load the .dll in the .exe code and register different things with the engine so your game code gets updated and rendered.

I'm thinking now as I type this if there is a way to flip it, but it would require a paradigm shift in your game design logic where the game only provides update and render functions to the game engine or something. That is really all you can rely on as the engine has to be generic enough to handle games.

If I think of anything ground breaking I'll post it here, but in the mean time here is some info on dynamic loading to help you get started. https://en.wikipedia.org/wiki/Dynamic_loading

Answer 2

Put the common functionality into a lib or a dll.

This would work, but a lib file would mean that I have the same classes compiled (linked) both in the exe and dll

nope, it wouldn't. The classes would be compiled and available on the shared library (.so on linux, .dll on windows, .dylib on mac), and your executable would call that particular method, from the shared library. it would not be compiled again in your executable.

Take a look on all frameworks or libraries in C++ are implemented:

• The public part is exposed on the headers
  • __dllexport(true) on the classes / functions.
• The private part is hidden
  • Private shouldn't even exist on the public headers unless it's a d-ptr
  • https://en.wikipedia.org/wiki/Opaque_pointer
  • This adds more security torwards binary compatibility
• Do not worry about increase of load times if you use shared library approach, it's negligible.