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

Subject: Re: [boost] Checking interest in DynamicLoad/DLL/DSO/Plugin library
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-08-16 21:19:11

On August 16, 2014 12:27:20 PM EDT, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
>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.

Your reading too much into "plugin". I don't consider that term to require what you think it implies.

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

Did you notice that my paragraph began with ABI? The switch to API was accidental. I fully comprehend the two.

As for all that you described, it is not the minimum required to make such a library useful.

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

What you describe is fine, when you need all of it, but overkill when you don't. The OP has agreed to change the name. It doesn't need the features you describe to be useful and those features can be built atop this library.

___
Rob

(Sent from my portable computation engine)