On August 16, 2014 12:27:20 PM EDT, Niall Douglas
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)