On 15 Aug 2014 at 19:22, Klaim - Joël Lamotte wrote:
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.
A plugin/extension implies a well defined exported symbols and event processing ABI. Something adhering to Microsoft COM is a good example. Antony's library is far more low level, it really does just thinly wrap the two popular shared library APIs into a portable API. It says nothing about what the ABI should be other than C compatible, any form of inspection other than C format symbols, or anything about any event model. I wouldn't mind calling his library a plugin solution for C, but it isn't up to task for C++.
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.
Unfortunately Boost.Module might get confused with forthcoming C++ Modules. Otherwise I wouldn't object to that name.
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.
ASIO is shortly to become the officially endorsed C++ event loop and dispatcher. As event processing is by definition part of any plugin or extension ABI - even if defined to be "no event processing", that means ASIO. So, just to be clear, if you load a Qt Plugin, the Qt event pump gets routed through ASIO's event pump. That way we can extend Vicente's monadic continuations framework easily to interoperate with all Qt threading and event objects. That also goes for all third party C++ libraries, and now you can mix and match loading Qt plugins with WinRT plugins with wxWidget plugins. You may find my C++ Now 2014 position paper useful. http://arxiv.org/pdf/1405.3323.pdf, starting from page 15 onwards. Just to be clear though, my earlier offer of potential paid work for a CppComponents based plugin system integrated with ASIO is a small subset of the C++ Now 2014 paper proposal, and is much, much easier. My current employer may decide on a Microsoft COM driven SWIG language bindings, and CppComponents is a quick way of metaprogramming the C++ compiler to spit out Microsoft COM compliant binaries. As always, there is a lack of available sufficiently experienced engineers on this. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/