Re: [boost] Severe shared_ptr limitation WRT dynamically loadedlibraries

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
> 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
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

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.

J.D.