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-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
> think)
>
 - 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
> useful);
>  - 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;
>

Good points!

>  - 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.
>

Thanks!

> Question:
>  - 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
preferable.

-- 
Best regards,
Antony Polukhin