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

Subject: Re: [boost] Checking interest in DynamicLoad/DLL/DSO/Plugin library
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2014-08-15 09:52:24

​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"

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;
 - 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.
 - 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.
Anyway it looks as simple as it should so far.

I will play with it soon, see if I see any problem.

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?