Subject: Re: [boost] Severe shared_ptr limitation WRT dynamically loadedlibraries
From: J.D. Herron (jotadehace_at_[hidden])
Date: 2008-11-20 11:14:32
On Thu, Nov 20, 2008 at 3:25 AM, Arno Schödl <aschoedl_at_[hidden]>wrote:
> > I would like to see a solution that would make this simple example and
> > reasonable use case work for shared_ptrs. Note that the argument that
> > client code cannot know what the factory is actually returning requires
> > the factory library be in memory so that appropriate subclass destructors
> > can be called does not hold water here. This example uses simple
> > 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
> > able to come up with as well.
> There is one aspect that you did not comment on, which is the allocation of
> Whichever DLL allocates the memory must also deallocate it. If that DLL
> also provide the shared_ptr, the problem disappears.
> Granted, it is easy to make a shared DLL provide the memory by simply using
> CRT linking, so the shared_ptr behavior is probably still undesirable.
> Dr. Arno Schoedl · aschoedl_at_[hidden]
> Technical Director
> think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany
> http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US)
> Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht
> Charlottenburg, HRB 85229
> Unsubscribe & other changes:
Our architecture makes sure everything uses a shared CRT dll so actually as
my example shows with the raw pointer you can allocate in one dll and
deallocate in another executable.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk