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

Subject: Re: [boost] [ptr_container] ptr_vector across DLL boundaries
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2009-06-26 10:21:52

Stewart, Robert skrev:
> On Friday, June 26, 2009 6:35 AM
> Thorsten Ottosen wrote:
>> Christian Schladetsch skrev:
>>
>>>> Types in object hierarchies usually don't expose their
>>>> copy-constructor to avoid slicing.
>>> But again, isn't this out of the scope? It's like the tail
>>> wagging the dog - ptr_container shouldn't really be concerned
>>> with object hierarchies or not.  That's up to the user.
> [snip]
>>>> Furthermore, and more importantly, you lose the concrete
>>>> type of the objects by having a container of pointers to the
>>>> base class. Virtual functions are the most elegant way to
>>>> ask the object for a copy of the right type.
>>> Isn't this about ptr_container? We can't really have the
>>> specific usage of OO hierarchies with containers of base
>>> pointers dictate the implementation of an otherwise general
>>> system.
>> Please understand that pointer containers are written almost for the
>> sole purpose of supporting OO programming better.
> 
> I know of use cases in which a similar container is used to hold
> homogeneous collections of objects by pointer, so cloning is
> irrelevant.  Indeed, I recall that Rogue Wave had such containers
> available.  Here's one: http://www2.roguewave.com/support/docs/hppdocs/tlsref/rwtptrvector.html.

Well, and the containers should also cnotinue to support that case.

> Can't cloning be handled using a smart pointer in a value-based
> container? 

Yes and no. The closest thing would be to write boost::clone_ptr<T>, but
there are additional differences like e.g.

- containers shrink instead of inserting null values
- ptr_vector<Base> b = ptr_vector<Derive>()
- completely disallowing null-values; clone_ptr<T> could do that too, 
but would not be movable in that case, which in turn would make
it horrible inefficient.

> That is, rather than make the pointer containers try
> to manage cloning, let them assume T is the most derived type
> rather than what might be a base type, and then supply a smart
> pointer for use with value-based containers to enable cloning.
> The smart pointer can call T::clone() or defer to a policy class
> to copy the T * it holds.

It's not that simple as I explain above.

Anyway, the question of where the objects' memory should come from
can possible be answered irrelevant of other issues. But I need lot of 
feedback from people using custom allocators to allocate everything.

-Thorsten