On Fri, Aug 15, 2014 at 6:44 PM, Niall Douglas
On 15 Aug 2014 at 15:36, Antony Polukhin wrote:
There is a basic implementation of a header only Plugin library: https://github.com/apolukhin/Boost.Plugin
Documentation with examples could be found here: http://apolukhin.github.io/Boost.Plugin/index.html
Is there an interest in such library in Boost community? What features are missing in the library?
Looking forward to hearing from you. Any feedback is more than welcomed.
It definitely has the wrong name because it doesn't implement plugins, it basically is a wrapper for the POSIX and Windows dynamic shared library functions. Boost.SharedLibrary is a far better name.
In my experience the "plugin" word is used as soon as a shared library could be loaded at an indeterminable time during execution (and be unloaded too). This is different from just "shared library" which is both a plugin implementation and a library linkage, including having the library automatically loaded at startup. To me plugin is far more precise than "shared library". You don't need such a library to make a shared library. You would need such a library to make a plugin (or extension, or module) library. Even CMake call them "module", not "shared" libraries. Even if implemented in unix-like systems as just "shared" libraries, it's still a special case of shared library, not the general case.
Now, if you did want to implement a Boost Plugins library, combining John Bandela's CppComponents (https://github.com/jbandela/cppcomponents) header only library which turns C++ objects into portable Microsoft COM compatible objects and Boost.ASIO as the event dispatch loop would probably be an optimal solution. Not only does that seamlessly plug into all Microsoft technologies, it also is an easy way of SWIG exposing your object into all the languages SWIG supports. If anyone is interested in implementing this solution to Boost quality, I believe I might be able to get you hourly funding to do it - contact me off list.
Could you clarify what you mean by plugin here? I don't see why ASIO would be a nice dependency for such a tool, but I don't understand what you mean either.
That said, I have no objection to your library or its design which is solid, so long as it is named more appropriately to what it provides. I suppose my only real qualm is that I wish your library did more.
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost