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 06:34:42

Christian Schladetsch skrev:
>> [snip]
>>> Then what is the point of clone_allocator?
>>>
>> It does provide some room for customization. But it was deliberately kept
>> very conservative, so we can extend it when we need to in light of user
>> experience.
> 
> 
> Isn't being able to create a clone using the parent containers' allocator a
> practical necessity? The originals are made using that allocator - isn't it
> natural to make clones using the same allocator?

It might be. I don't know. But see below why it is not that easy.

>> Types in object hierarchies usually don't expose their copy-constructor to
>> avoid sliving.
> 
> 
> 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.
> 
> Surely, copy construction must be the best default way to make a clone? The
> user can make their types noncopyable if needed.
> 
> 
>> Furthermore, and more importantly, you loose 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.

>> [snip] This requires a public copy-constructor which we must not impose as
>> a requirement, and even so it would not work because the concrete type is
>> lost. (let's ignore that it is not exception-safe).
> 
> 
> How will you make a clone without using a copy-constructor? Are you
> suggesting something like is_convertible<base *, T*> then switching to a
> virtual-method-based-scheme for clone??
> 
> I don't fully understand what you mean by "the concrete type is lost". Do
> you mean in this sort of case?
> 
> struct Foo
> {
>     vector<Base *> bases;
>     Foo(const Foo &other) { ... /* how to clone bases? */ }
> };
> 
> If so, isn't that way out of the domain being addressed by ptr_container?

When you assign

   Base* p = new Derived;

the concrete type of Derived is lost.

> I think I see that you wanted a way to help with the Foo case above, but
> perhaps that really shouldn't be a part of ptr_container at all?

It's one reason the containers exist. But it's not just for the 
copy-construtor case.

>> And, as stated above, we also need to make sure that implementers of
>> clone() get the allocator.
> 
> 
> It seems that you added clone_allocator to help with cloning of
> containers-of-base-pointers, but I can't see that working in general.
> Attempting to do so is really reaching from system library space into
> application space.
> 
> If needed, the user can make their own clone() system, and use it to
> implement their own copy constructors, which would then be used by
> allocator::construct in a ptr_container to make a clone and clone_allocator
> then isn't even needed.

I don't want to repeat myself, but pointer containers need to support 
non-copyable types. Period.

> PS. Perhaps just porting ptr_container to use boost::container rather than
> std::container would solve Roberts problem?

No. He needs to "install" his own new/delete with the container.

-Thorsten