Question

Currently we have a body of code that allows service plugins which offer forms of communication to the core e.g tcp/ip, udp/ip, usb, etc... These service plugins feedback notifier class instances to the core for further processing.

In the current implementation a service project (which is a separate dynamically linked library brought in at runtime by the core via dlopen and friends) will compile against the notifier.cpp file that resides in the core source code (a separate project). This gives access to the notifiers method implementations. This works perfectly no complaints.

Two alternative options: 1. put the notifier method implementations in the header file. 2. declare the notifier methods virtual and delay binding until runtime.

Avoiding the issues of computational overhead what are the impacts of option 2?

Are there any other options available to us?

Thanks

Was it helpful?

Solution

Yes, exposing an interface with pure virtual functions to consumers is the standard way of exposing C++ objects from a Windows DLL. The client isn't aware of any implementation details: no member variables, no member function bodies, just virtual layout.

(Add reference counting and a language-agnostic version of dynamic_cast, which we'll call QueryInterface, and you have COM, which is pervasive on Windows)

This technique will work just fine on *nix shared libraries as well.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top