Re: [boost] Severe shared_ptr limitation WRT dynamically loadedlibraries

Subject: Re: [boost] Severe shared_ptr limitation WRT dynamically loadedlibraries
From: Arno Schödl (aschoedl_at_[hidden])
Date: 2008-11-20 05:25:45

> I would like to see a solution that would make this simple example and very
> reasonable use case work for shared_ptrs.  Note that the argument that the
> client code cannot know what the factory is actually returning requires that
> the factory library be in memory so that appropriate subclass destructors
> can be called does not hold water here.  This example uses simple integers.
> The root of the issue is not one of the virtual function table for the
> wrapped type getting corruped on library unload but rather the virtual
> function table for a member of the shared_ptr itself.  I will put some
> thought toward this but am interested to see what boost developers might be
> able to come up with as well.

There is one aspect that you did not comment on, which is the allocation of memory.
Whichever DLL allocates the memory must also deallocate it. If that DLL could
also provide the shared_ptr, the problem disappears. 

Granted, it is easy to make a shared DLL provide the memory by simply using dynamic 
CRT linking, so the shared_ptr behavior is probably still undesirable.

Arno

--
Dr. Arno Schoedl · aschoedl_at_[hidden] 
Technical Director 
 
think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany 
http://www.think-cell.com · phone [phone] · toll-free (US) [phone]
Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229