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

Subject: Re: [boost] Checking interest in DynamicLoad/DLL/DSO/Plugin library
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2014-08-15 14:56:53

On Fri, Aug 15, 2014 at 8:42 PM, Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

> 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++.
>
>
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.

> > 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.
>
>
Indeed. (I wasn't proposing such name, for the same reason).

> > > 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.
>
>
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.

But otherwise I see your general point now.

> 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/
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>