Re: DLL library (Was: [boost] Re: additional boost libraries?)
Vladimir Prus wrote:
Hi Mattias,
On Fri, 23 Jul 2004 13:49:22 +0400, Vladimir Prus <ghost@cs.msu.su> wrote:
static imported_function<void()> apiFunc( "ApiFunc", "OSLib" );
Couldn't find a nice point in the thread at which to insert this comment, so I'll just spit it out: Since we have both the name of the function and the function type, and given that a lib such as this should provide a platform-independent interface, would it be useful if the library automatically mangled the name according to the type?
I think you've missed something ;-) Even my initial reply inthe "additional boost libraries" thread mentioned the possibility of calling functions which are not "extern "C". At least two other persons seems to want this. I find this would be nice, though not critical at all.
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. 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()); } Also, wouldn't it be better to have import as a function of shared_library, so you could do something like: boost::shared_library mylib( "user32.dll" ) typedef ... msgboxA_fn; msgboxA_fn mbA = mylib.import< msgboxA_fn >( "MessageBoxA" ); msgboxW_fn mbW = mylib.import< msgboxW_fn >( "MessageBoxW" ); With the possible Win32 implementation of, but using boost::function: namespace boost { class shared_library { private: HANDLE hDLL; public: template< typename Function > inline Function * import( const char * fn ) { if( hDLL == 0 ) return( 0 ); return( reinterpret_cast< Function * >( ::GetProcAddress( hDLL, fn ))); } public: inline shared_library( const char * fn ): hDLL( ::LoadLibrary( fn )) { } inline ~shared_library() { if( hDLL ) { ::FreeLibrary( hDLL ); hDLL = 0; } } }; } 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:
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 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.
Also, wouldn't it be better to have import as a function of shared_library, so you could do something like:
boost::shared_library mylib( "user32.dll" ) typedef ... msgboxA_fn;
msgboxA_fn mbA = mylib.import< msgboxA_fn >( "MessageBoxA" ); msgboxW_fn mbW = mylib.import< msgboxW_fn >( "MessageBoxW" );
Hmm... I've made the same remark in reply to Sven. The syntax is up for discussion, though. I also wonder if it makes sense to sumbit just "dll" library, or some additional plugin support need to be developed first. - Volodya
On Mon, 26 Jul 2004, Vladimir Prus wrote:
Reece Dunn wrote:
Would it be possible to have a mangle function, then you could do something like:
This is all well and good, but how about a simple C symbol loading interface to start, where we just cast the things into what we want, and then build on that? :) I only suggest this because on all the dll-loading projects I worked in, we just made all the "plug in" dlls export some single predefined function or two. Upon loading the dll, the application calls these extern "C"'ed functions. Within this, the dll then continues to "register" its objects and other facilities within this function, all in a nice C++ manner. But if you really must do some mangling, perhaps some kind of trickery done with macros and extern "C" (or extern "C" and little template functions) can be used to define your own multiplatform/compiler independant mangling scheme? -- // scopira.org | ninjacoder.com //
participants (3)
-
Aleksander Demko -
Reece Dunn -
Vladimir Prus