Re: [boost] Re: additional boost libraries?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-07-21 06:04:20

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