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.
>>>> 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
>> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk