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

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-07-28 06:29:01

Vladimir Prus wrote:
>Bronek Kozicki wrote:mechanism Garland wrote:
> >> This isn't really a re-invention of either -- just a very small library 
>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/