Sven Van Echelpoel wrote:
* cdecl: (a work in progress) decorates a name using the compiler's name mangling scheme
The last decorator is the most ambitious and potentially the least portable. I'm still pursuing it because it can result better portability of user code.
Actually, I now think it will be very hard to do, and will give very little benefit....
Consider the following example of the loading plugins from a shared library:
std::vector< boost::shared_ptr<IPlugin> > LoadPlugins( std::string piLib ) {
import::function< std::vector< boost::shared_ptr<IPlugin> >()>
GetPluginList( "SomeApp::_3rdParty::GetPluginList", piLib );
std::vector< boost::shared_ptr<IPlugin> > plugins = GetPluginList();
return plugins;
}
Using only the function signature and the qualified name of the exported function the user could bind to the exported function on every supported compiler, without having to resort to workarounds like extern "C" functions that suppress name mangling, but also prohibit the use of non-POD types.
... because if you mostly load some classes, it does not really matter if the single function is extern "C" or not.
To improve the portability all decorators are composed of base decorators that can be combined to form more complex ones. Furthermore I think I can come up with a tool that (for a lot of compilers) generates the base decorators by analysing a map file produced by compilig and linking a source file with known function names/signatures.
You mean you'd write a tool which will automatically write name mangler, or I misunderstood you? In any way, http://www.codesourcery.com/cxx-abi/abi.html#mangling is complex.
Since this is a rather ambitious project and I can only work on it a couple of hours a week (at most), it will take quite a while to finish. But if you're interested, I can keep you updated.
Probably, you could start by explaining your vision of the library first. Of three points you've given: * a simple interface to load a library by name or path and query the address of symbols by name * a boost::function-like type that can bind to a function at runtime and call it * a scoped_ptr or smart_ptr-like type that can bind to exported PODs at runtime The two last seems very vague for me. For example, how the second is different from: boost::function<void (void)> f = static_cast<void (*void)>dlsym(h, "whatever") - Volodya