Subject: Re: [boost] Checking interest in DynamicLoad/DLL/DSO/Plugin library
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2014-08-15 10:28:01
2014-08-15 17:52 GMT+04:00 Klaim - JoÃ«l Lamotte <mjklaim_at_[hidden]>:
> âI read the documentation and it looks good starting point, it's complete
> enough to start working with.
> Some typo:
> - Getting Started page: "just *cunstruct* that class with a path to the
> library as a parameter" should be "construct"
> - There is a missing '*' in this line in the tutorial page: "Linking
> plugin into the executable has the advantages of * reducing common size of
> distibution * simplification of installation of distribution * faster load
> times of plugin"
I'll fix that soon. Thanks!
> Some suggestions for the doc:
> - provide some pages to help with declaring correctly plugin targets with
> some commonly used (meta-)build system, using this library macros.
> For example a CMake and a VS projects pages would be useful additions (I
- clarify early what should happen when you use the library incorrectly
> (link errors most of the time): this in particular can help a lot
> understanding issues when you first try to setup a plugin system
> and don't have yet a good understanding of how it works;
Build plugin just like a usual shared library. Plugin library is actually a
wrapper around native functions to DLL/SO. You can use it to import C
functions from any DLL/SO.
I'll try to clarify that somewhere in docs.
> - some typical examples on when using "modes" on constructing
> shared_library can be useful (at least it's not clear to me when it is
> - there is no reference page for the modes and no link generated when it
> appears in shared_library reference page.
Hm... Docs for modes are inplace, looks like doxygen failed to parse the
markup. I'll fix that.
> - a note clarifying that BOOST_SYMBOL_EXPORT is not defined by this
> library but by boost.config would be nice,
> also if you clarify that you could use your own symbol export/import
> macro if you already have one, it wouldn't change a thing
> for boost.plugin;
> - a page gathering the platform-specific warning per platform would be a
> useful reference, in particular if it describe the important/noticeable
> difference in behaviours of the different platforms;
> I took a very quick look at the implementation but it seems that some parts
> are temporary (FIXME comments) so I'll ignore that for now.
Those "FIXME" are because the dll2.hpp header must be moved into the
Boost.Winapi library with the name dll.hpp. I've postponed that, because
dll2.hpp still may change a little bit and I do not wish to spam
Boost.Winapi admins with pull requests.
> Anyway it looks as simple as it should so far.
> I will play with it soon, see if I see any problem.
> - would have it been possible/better to not expose the shared_ptr<> s in
> the interfaces? Maybe using concept-based type-erasing type instead?
If you are talking about shared_ptr in DLL ("shared_ptr create_plugin()"
examples), then it is up to user what functions to export from DLL and what
signatures those functions have.
If you are talking about the boost::plugin::shared_variable() methods, then
there is a "core" part of the library that does not use shared_ptr or
boost::function. In "Refcountable" part of the library shared pointers are
essential for internal needs. In theory a better solution would be to
return unique_ptr from shared_variable() functions, however there is no
unique_ptr at the moment in Boost and forcing user to use C++11 is not
-- Best regards, Antony Polukhin