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.
Good. Nice to hear that I can have 'virtual' constructors with your library.
- 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")
That's not what I meant. You're suggesting to find a known symbol. I was suggesting to find the list of names for the existing (unknown) plugins. Thanks! Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu