Boost logo

Boost Users :

Subject: Re: [Boost-users] [ptr_container]delete_clone and shared libraries
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2009-06-25 10:30:59


Hi Robert,

Robert Dailey skrev:
> On Windows, I plan to create a ptr_vector in a separate DLL and
> propagate it to the executable for ownership (Factory-style). The
> executable will be responsible for the lifetime of this ptr_vector, and
> will eventually result in "delete" being called on each element in the
> ptr_vector. However, this 'delete' will be from the executable's memory
> manager, when the memory was originally allocated in the shared
> library's memory manager, causing serious issues.
>
> It would be ideal to specify a delete_clone class that ptr_vector would
> use (via ADL) and would force those objects in the ptr_vector to use the
> 'delete' call from the DLL's memory manager, and not the executable's.
>
> I don't see that this is going to be possible, or at least able to be
> done easily. Since the delete_clone's operator will have to be
> implemented in a CPP file, so it will be included into the shared
> library. This also implies that I'll have to import the delete_clone's
> interface, since this DLL will be loaded dynamically with LoadLibrary()
> in Windows. I just don't see this happening.
>
> Now, if ptr_vector had a function like so:
>
> ptr_vector::set_deleter()
>
> I could give it a pointer to a global function in my DLL, and the
> deleter becomes fully transparent to my executable. It just has to keep
> the ptr_vector around and let it fall out of scope and the deleter from
> the DLL will be used to delete each object in the ptr_vector. However,
> it isn't this simple and I need advice on how I can make this work.

Well, we need to make the clone_allocator stateful, which is currently
not supported. I always was lacking a good argument, so let's work on
the design of this on the dev list.

-Thorsten


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net