I'll try to answer all common questions in a single letter:
2014-08-16 3:39 GMT+04:00 Hartmut Kaiser
From our experience a plugin library should additionally to your design support:
- arbitrary constructor arguments to the plugin object created:
typedef boost::shared_ptr
(pluginapi_create_t)(); boost::function creator = boost::plugin::shared_function_alias ( shared_library_path, "create_plugin"); boost::shared_ptr
plugin = creator(42, "foo", 3.14);
Yes, you may export/import *any* functions with any signatures in any namespace using the Plugin library. ABI problem and name mangling is solved by BOOST_PLUGIN_ALIAS macro, that produces a portable C name of an exported function or variable. That's all what can be done. Constructing a C structures from C++ classes for each C++ class in attempt to make std::string/std::vector portable across library boundaries looks very unreasonable to me. Compiler developers and library users must take care of it, not the library itself. I'll add this notes from above to the docs.
- the ability to extract the full file system path of a loaded shared library (this is not always the same as the file name you specified to load the library)
This would be a good addition. Thanks!
- the ability to extract a list of plugin object names from a given shared library ( I assume that your library allows to have several plugin types in the same shared library)
Could be queried using the bool res = lib.search_symbol("some_name_of_the_plugin")
- support for binding/instantiating plugin objects even if the plugin is linked as a static library (some HPC systems do not support dynamic/shared libraries and this functionality allows to keep the code which using the plugins unchanged)
Yes, it is supported via shared_library::load_self()
- it is important that the pointer to the plugin object keeps the shared library loaded
Supported via shared_* functions.
2014-08-15 20:44 GMT+04:00 Niall Douglas
Now, if you did want to implement a Boost Plugins library, combining John Bandela's CppComponents (https://github.com/jbandela/cppcomponents) header only library which turns C++ objects into portable Microsoft COM compatible objects and Boost.ASIO as the event dispatch loop would probably be an optimal solution.
Let's take a look at the situation from a bigger distance. There are 3-5 known open source plugin libraries based or proposed for Boost. There are hundredths plugin systems in commercial products. All those plugins have a common part - shared_library class. Other parts differ a lot: * factory methods signatures * plugin api * plugin names * event loops * OS specific techlologoies support (COM) Almost all of those differences can not be unified/solved in a common way. Any solution would not be generic enough. That's why Plugin library does not force any plugin API or does not specify event loops. It just stopped at the point where the differences begin. There are interesting things in each existing plugin system. Example from cppcomponents looks great: #include "library.h" int main() { Person p; std::cout << p.SayHello(); } I'll take a deeper look into it. Thanks for the good hint! HPC's plugins have some good functions that are missing in subject library. I'll take a deeper look into it. Thanks for the good hint! Answering to all the naming proposals: SharedLibray/DLL/DynamicLinkLibrary sound too platform specific. Plugin sounds more generic, thou it confuses users. How about Dynamic Library Load and namespace boost::dll:: ? -- Best regards, Antony Polukhin