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-16 12:27:20

On 15 Aug 2014 at 17:34, Rob Stewart wrote:

> >A plugin/extension implies a well defined exported symbols and event
> >processing ABI. Something adhering to Microsoft COM is a good
> >example.
> 
> What that term implies is based upon one's experience. "Plugin", to me
> is any dynamically loaded component.

I agree. But this library doesn't load components, it loads shared 
object binaries.

> The ABI you mention depends
> entirely upon the ubiquity of the plugin. If it must be usable by many
> applications and customers, it must have a documented, even
> standardized, API. Just as easily, however, one can create plugins based
> solely upon dlopen() (or LoadLibrary()) and friends of the plugins are
> used only for one application. 

API != ABI.

ABI is standardised way of describing an API to external code. 
dlsym/GetProcAddress adhere loosely to the C ABI, and aren't 
particularly useful for C++. Even if you added a mangled symbol to 
partial AST decoder you still only have a toolkit with which one 
/could/ build a Plugin library, because one has yet to implement a 
dynamic invocation and lifetime management layer, plus an event 
processing standard. One also would find that some additional 
metadata is needed above what can be deduced from what the C ABI and 
RTTI makes available.

John Bandela's CppComponents library has done a huge amount of all of 
this grunt work already, plus it's all header only and is a very easy 
way of making your C++ 14 code available to anything which can speak 
Microsoft COM. He's presented at both the 2013 and 2014 C++ Now's, 
his talks are well worth viewing. I agree that Microsoft COM reduces 
your C++ API to an early 1990s level of C++, but that unfortunately 
is still the current state of the art because of the wider C++ 
community's continuing failure to resolve Exported Templates - 
though, with C++ Modules we are most of the way there now, indeed 
Chandler was joking last C++ Now that clang might just implement 
exported templates for fun as they are trivial once Modules are fully 
implemented.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/