Boost logo

Boost :

Subject: Re: [boost] Checking interest in DynamicLoad/DLL/DSO/Plugin library
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-08-15 15:17:28

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

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


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at