On 15 Aug 2014 at 20:56, Klaim - Joël Lamotte wrote:
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++.
I see. To me it's a good starting point and I fear that a more C++ than C library ends-up like boost.extension. But if it's not too hard to match your definition of plugin, it would be a win for me too as a user.
My objection is purely to the use of the name "Boost.Plugin" given what the library currently does. Even "Boost.BinaryLoader" is a better name.
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.
I would prefer to be able to use any event loop implementation instead of forcing asio, personally, because it's not a depencency of my projects right now and I already have another event loop which is specifically designed for my case (and is not general at all and require a very specific impl, for a very specific feature). Basically I prefer composing library instead of using a library that assume that everybody uses the same event loop. I might be wrong though, I don't see the whole picture with asio yet.
Sorry, I didn't explain myself clearly: ASIO is the *master* event loop. All other event loops remain themselves, it's just that they can adapt into the master event loop which is ASIO. You can compose as many custom event loop implementations as you like, that's up to you. This is possible because it turns out that ASIO's design is a superset of all other event loop designs I could find during when I researched this at BlackBerry. Therefore all other event loop designs can plug into ASIO with no loss of functionality, though with potential loss of low latency admittedly. I don't know if Chris intended this, but he achieved it nonetheless. And of course because ASIO will enter the C++ standard, it'll simply be there in the STL all the time. No dependency problems (in the future). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/