Re: [boost] Checking interest in DynamicLoad/DLL/DSO/Plugin library

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

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/