2014-08-15 17:52 GMT+04:00 Klaim - Joël Lamotte
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