Re: [boost] Checking interest in DynamicLoad/DLL/DSO/Plugin library

Subject: Re: [boost] Checking interest in DynamicLoad/DLL/DSO/Plugin library
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2014-08-16 04:12:53

I'll try to answer all common questions in a single letter:

2014-08-16 3:39 GMT+04:00 Hartmut Kaiser <hartmut.kaiser_at_[hidden]>:
<...>

> From our experience a plugin library should additionally to your design
> support:
>
> - arbitrary constructor arguments to the plugin object created:
>
>     typedef boost::shared_ptr<my_plugin_api> (pluginapi_create_t)();
>     boost::function<pluginapi_create_t> creator =
>         boost::plugin::shared_function_alias<pluginapi_create_t>(
>             shared_library_path, "create_plugin");
>
>     boost::shared_ptr<my_plugin_api> 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 <s_sourceforge_at_[hidden]>:
<...>
> 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