Hi boosters, I developed a fairly simple prototype of a dll loader which mangles functions names automatically. But there are limitiations: you cannot call function which have template class parameters or return value, e.g. void test(std::string const &str) will not work. I do not get the mangling scheme used to decorate such a type, maybe someone knows a good source where I can look that up?! For class mangling I use the string returned by type_info::name(), but that seems very hacky. Microsoft Visual C++ does not always return correct strings (e.g. typeid(int &).name() returns "int"). Sorry that I attached the source code to that mail as I know that only a few will look at it, but I don't have a homepage handy to upload it there. - nico
Vladimir Prus wrote:
Reece Dunn wrote:
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 am not sure how CORBA works. COM generally uses a different mechanism to load COM objects via CoCreateInstance, although DirectX exposes creation functions that circumvent this. I was thinking about being able to use COM/CORBA as a platform for object lifetime and dll lifetime management (as well as things like interface extension, etc.).
I though more about at least some kind of map<string, BasePlugin*> which is updated automatically when you load new DLLs.
So the dll implements some function:
__declspec(dllexport) BasePlugin * GetMyPlugin();
so you can do something like:
void load_plugins( map< string, BasePlugin * > & pi ) { for( map< string, BasePlugin * >::iterator i = pi.begin(); i != pi.end(); ++i ) { boost::dll plugin(( *i ).first ); ( *i ).second = plugin.import< ... >( "GetMyPlugin" ); } }
It is possible to keep the DLL in memory until all instances of a class (or set of classes) by incrementing/decrementing a global object count variable on construction/deconstruction as is done when using COM. You then check this variable in the DllCanUnload function.
You may need some reference counting mechanism to keep the plugin alive, but this is not necessary if you load all plugins on startup and release them at the end of the run.
It should be possible to implement these facilities in a library, e.g.:
class object_counter { private: static int objectCount = 0; public: inline int get_object_count(){ return( objectCount ); } public: inline object_counter(){ ++objectCount; } // make MT aware inline ~object_counter(){ --objectCount; } // make MT aware };
class reference_counter { private: int refCount; public: inline void add_ref(){ ++refCount; } // make MT aware inline void dec_ref() { if( --refCount == 0 ) // make MT aware { delete this; } } public: inline reference_counter( int rc ): refCount( rc ){} inline ~reference_counter(){} };
allowing:
class plugin: public object_counter, public reference_counter, public BasePlugin { // ... };
__declspec(dllexport) BOOL DllCanUnload() { return( object_counter::get_object_count() == 0 ); }
I'm not sure what the Linux equivalent would be.
Regards, Reece
_________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
***************************************************************************** ** ** ** WARNING: This email contains an attachment of a very suspicious type. ** ** You are urged NOT to open this attachment unless you are absolutely ** ** sure it is legitmate. Opening this attachment may cause irreparable ** ** damage to your computer and your files. If you have any questions ** ** about the validity of this message, PLEASE SEEK HELP BEFORE OPENING IT. ** ** ** ** This warning was added by the IU Computer Science Dept. mail scanner. ** *****************************************************************************