Re: [boost] [ptr_container] ptr_vector across DLL boundaries

Subject: Re: [boost] [ptr_container] ptr_vector across DLL boundaries
From: Robert Dailey (rcdailey_at_[hidden])
Date: 2009-06-25 18:36:21

If you want to provide a stateful clone allocator, it would allow me to do
something like this:
class clone_allocator
{
public:
  clone_allocator()
  {
    dll_clone_object = GetProcAddress();
  }
  MyClass* operator() ( MyClass const& node )
  {
    return dll_clone_object( node )
  }

private:
  MyClass* (*dll_clone_object)( MyClass const& );
};

Note that the above is pseudocode. The point is, it would allow me to
abstract the DLL factory function for creating clones, thus giving me full
control over which 'delete' and 'new' method is called (In this case, it
would be the one from the DLL's memory manager).

On Thu, Jun 25, 2009 at 4:26 PM, Thorsten Ottosen <
thorsten.ottosen_at_[hidden]> wrote:

> Christian Schladetsch skrev:
>
>> How does a clone_allocator make a new clone, if it needs access to the
>> allocator in the parent ptr_container? I had this problem when I tried to
>> write a clone allocator for monotonic to support ptr_containers:
>>
>>        struct inline_clone_allocator
>>        {
>>            template< class U >
>>            static U* allocate_clone( const U& r )
>>            {
>>                // can't allocate clone without access to the allocator??
>>                return 0;
>>            }
>>
>> What am I missing?
>>
>
> Nothing, I think. This seems like something it was not designed for,
> on the cnotrary the clone is currently always allocated by someone else.
>
> The current design uses static functions, and so there can be no stateful
> allocator.
>
> I thought a little about this, but have not come up with a solution.
> For example, how do we design an allocator that knows how to clone a
> class hierarchy? Only the class itself knows how to clone itself because it
> knows the exact type. OTOH, the classes in the class hieararchy doesn't know
> about the allocator.
>
> We might try a new way to clone objects by replacing
>
>  virtual Base::clone() const = 0;
>
> with
>
>  virtual Base::clone( boost::clone_allocator& ) const = 0;
>
> Now, if the containers stored a clone_allocator instance, it could be
> implemented like
>
> struct my_clone_allocator : boost::clone_allocator
> {
>  template< class U >
>  U* allocate_clone( const U& r )
>  {
>    return r.clone( *this );
>  }
> };
>
> (remark: boost::clone_allocator would have two virtual functions: void*
> allocate(unsigned) and void deallocate(void*)).
>
> That might work, but it still gives you no guarantee or possibility that
> derived classes use the container's allocator for all its data members
> (reqursively). Maybe that is not required; I just don't know.
>
> So feedback on what we want to do is most welcome.
>
>
> -Thorsten
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>