Vladimir Prus wrote:
This isn't really a re-invention of either -- just a very small library
Bronek Kozicki wrote:mechanism Garland wrote: that
does someskeletonsilar to what both do -- without all the baggage. COM is a Windows only option, for example. Both are big frameworks with gobs of stuff not needed to load a dll and call a function.
I think that similar motivation drove YAMI project, see http://www.msobczak.com/prog/yami/
Do you mean "without all the baggage" by "similar motivation"? What I see on the page is still very complex -- some network communication and the like.
I want just portable mechanism to access objects from shared libraries. This is much more lightweight than CORBA, which requires IDL, stubs, skeletons, supports talking to objects on other machines, a lots of other stuff.
Frameworks like COM and CORBA are designed to be language independent: this is why they use IDL for describing interfaces. Since what you require is C++-specific, you can skip the IDL language and use abstract base classes and/or virtual functions, which is what Volodya is doing. The frameworks also provide some means of generic exception handling. COM skips this by returning an error code (HRESULT) value because of the issues of dealing with exceptions across language borders (e.g. C++ to C). The C++ exception mechanism is fine for what Volodya wants because there will be no cross-language problems. The frameworks may provide some means of automation. COM uses a discriminant union type (VARIANT) and a dispatch interface to achieve this, as well as providing direct access via the interfaces. I don't think scripting is an important issue in this case, but it should be possible to implement using Boost.Spirit :). The frameworks provide a mechanism for managing object lifetimes. COM does this by the base interface supporting AddRef/Release with the DLL responsible for construction (via exposed object types) and the object responsible for deconstruction (deleting itself once the reference count is 0). As I see it, this is intended to be implemented using shared_ptr's, the issue being *how* to load the objects and DLL's. In COM the object is responsible for keeping the DLL alive (via a reference count on the DLL as has been mentioned in other posts). If there are two objects from the DLL alive, then the DLL's reference count is two (unless it is explicitly locked to keep it alive). The MS documentation on DllMain says: During initial process startup or after a call to LoadLibrary, the system scans the list of loaded DLLs for the process. For each DLL that has not already been called with the DLL_PROCESS_ATTACH value, the system calls the DLL's entry-point function. Thus, if the DLL is already loaded by a process, it will not reload it on successive calls to LoadLibrary. The documentation on FreeLibrary says: The FreeLibrary function decrements the reference count of the loaded dynamic-link library (DLL). When the reference count reaches zero, the module is unmapped from the address space of the calling process and the handle is no longer valid. Thus, there is no easy way to reload a DLL. The best solution would be to release the instance of the plugin you have loaded and let the system unload the DLL. It is best to only be concerned about the DLL when loading the plugin. If you want to alter plugins at run-time (e.g. removing or adding a plugin), just remove all references to the plugin to delete it or load the plugin into the plugin map from the DLL. The frameworks provide other facilities, but I think these are the main (core) facilities. I am not sure how this will map to Linux or MacOS systems. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/