Re: [Boost-users] PolyCollection requiring copyable

Subject: Re: [Boost-users] PolyCollection requiring copyable
From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2017-10-05 11:30:50

El 05/10/2017 a las 10:08, Thorsten Ottosen via Boost-users escribió:
> Den 04-10-2017 kl. 21:10 skrev d3fault via Boost-users:
>
>>
>> Thanks for that workaround Joaquin M López Muñoz. It's interesting,
>> but not quite what I'm looking for (want both move and copy
>> constructors deleted).
>
> Perhaps
>
> http://www.boost.org/doc/libs/1_64_0/libs/ptr_container/doc/reference.html 
>
>
> can help. boost::ptr_vector should be one's default choice.

Absolutely :-)

Thorsten, regarding Boost.PolyCollection I've given a thought or two to 
the request
that copy/assignment of elements be externalized to a configurable 
traits class:

http://www.boost.org/doc/html/poly_collection/future_work.html#poly_collection.future_work.copy_traits

and I'm not sure how/whether this can be done. The typical copy interface of
a virtual hierarchy is through some clone() member function like this:

 Â virtual base* clone()const;

which is BTW what you adopt in Boost.PointerContainer. The problem with this
is that clone() not only constructs the derived object but also 
allocates memory for
it, which is against Boost.PolyCollection approach, where memory is 
allocated
through the collection's allocator and passed to construction code. This 
implies the
cloning interface should look like:

 Â  // OOP member function
 Â  virtual void construct(void *p)const; // p alocated/aligned OK for 
derived

 Â  // As embodied in the copy traits
 Â  void construct(void* p,cont derived& x){x.construct(p);}

which doesn't seem like OOP usual practice. In particular, I don't see 
how clone() can
be used (without changing the OOP code) to implement copy_traits::construct.
Thoughts on this?

Thank you,

Joaquín M López Muñoz