Learn More
Resend Email
6
Ranchonyx
3d

I've started messing with C++ again, and it's kinda fun :)

I'm a fan of modular systems, so I've decided to build a little proof of concept for plugin loading.

A plugin is basically just a shared library which exposes a class that extends the Plugin abstract class and implements some lifecycle methods.

Then a plugin file has a system specific PLUGIN_EXPORT create_plugin()... function that just returns an instance of the plugin.

I've decided to use a super simple event bus for communicating from the host system to the plugin and vice versa, it's supplied in a PluginContext class which is supplied to the plugin upon initialisation.

Loading the plugins is done via LoadLibraryA(...) or dlopen(...).

Of course I'm freeing/closing them again at the end of the host system lifecycle. I hope to eventually implement some form of HMR.

Idunno why I'm sharing this; The system has zero purpose other than learning, but I've figured that implementing plugins in a "lower" level language, rather than typescript with node is more fun :)

random

plugin

shared_library

hmr
Favorite
Ranter
Comments
  • 4
    3d
    You share this because recreational coding gives mood a good boost in general. Every little issue that you resolve, you'll get a bit happier until you start posting high on devRant like I do.
  • 1
    2d
    What is your approach to stable ABI? pure virtual classes, serialization to C ABI, or some interesting mix?
  • 0
    2d
    Rust doesn't have a very good equivalent to C++'s pure virtual ABI, so I load plugins as child processes and communicate via IPC.
  • 1
    2d
    @lorentz I went with a virtual class :)
  • 1
    2d
    @lorentz
    I had some major issues with the vtable though. Apparently I fucked up somehow and fixed it by using the appropriate compiler flags and using RTLD_GLOBAL in my dlopen call. Kind of a hassle to understand some things but eh.
Related Rants
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment