RE: [boost] Re: DLL library (Was: Re: additional boost libraries?)

Vladimir Prus wrote:
Reece Dunn wrote:
Would it be possible to have a mangle function, then you could do something like:
static imported_function<void()> apiFunc( mangle::mwcw( "ApiFunc" ), "OSLib" );
This would mean that imported_function need only know how to get the function (e.g. using GetProcAddress in Win32) and not worry about the name mangling scheme used.
I though more about a policy function/class. Something like:
boost::dll my_dll("foo", cpp_mangler); boost::dll my_dll2("foo", c_mangler);
The problem with this is if you need different mangling schemes for the same library then you will have several instances of the same library loaded (not sure how Windows handles this). A possibility is to have the mangler specified in the constructor (defaulting to extern "C" functions) be the default mangler and have another function where you can explicitly state which mangler you need: boost::dll mylib( "mylib", gcc3_mangler ); mylib.import< ... >( "get_id" ); // use GCC3 mangling mylib.import< ... >( "factorial", c_mangler ); // use extern "C" mangling
The name mangling could then be handled by a mangler/demangler library that would be useful in diagnostics, e.g.:
template< typename T > inline void print_type( const T & t ) { std::cout << demangle::gcc3( typeid(t).name()); }
That's for sure. And in other contexts too.
True. If you go for an external policy-based mangler like above then you don't need to worry about name mangler support (e.g. does the library have VC or GCC3 mangling?) immediately. You can provide a base set and add to that set later.
I also wonder if it makes sense to sumbit just "dll" library, or some additional plugin support need to be developed first.
What sort of plugin support are you looking for? Do you mean something like COM/CORBA support or wrapper, e.g. something that can target both (and others like them) in one implementation? Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

Reece Dunn wrote:
I though more about a policy function/class. Something like:
boost::dll my_dll("foo", cpp_mangler); boost::dll my_dll2("foo", c_mangler);
The problem with this is if you need different mangling schemes for the same library then you will have several instances of the same library loaded (not sure how Windows handles this).
I'm pretty sure on Linux only single copy of DLL can be loaded -- spend quite some time trying to circumvent this. I suspect it's the case on windows, too.
A possibility is to have the mangler specified in the constructor (defaulting to extern "C" functions) be the default mangler and have another function where you can explicitly state which mangler you need:
boost::dll mylib( "mylib", gcc3_mangler ); mylib.import< ... >( "get_id" ); // use GCC3 mangling mylib.import< ... >( "factorial", c_mangler ); // use extern "C" mangling
Yea, that's a possibility.
That's for sure. And in other contexts too.
True. If you go for an external policy-based mangler like above then you don't need to worry about name mangler support (e.g. does the library have VC or GCC3 mangling?) immediately. You can provide a base set and add to that set later.
I think the same is true for approach with 'mangler' function like you've suggested. The basic "extern_C_manger" is easy to write.
I also wonder if it makes sense to sumbit just "dll" library, or some additional plugin support need to be developed first.
What sort of plugin support are you looking for? Do you mean something like COM/CORBA support or wrapper, e.g. something that can target both (and others like them) in one implementation?
I'm not CORBA expert, but I think it's entirely different beast. To use CORBA object you use stub generated from IDL, how it's related to plugins? While there are some ways to find object dynamically, it's different mechanism from shared libraries, isn't it? I though more about at least some kind of map<string, BasePlugin*> which is updated automatically when you load new DLLs. - Volodya
participants (2)
-
Reece Dunn
-
Vladimir Prus