Boost logo

Boost Users :

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
> 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:

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
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

 Â  // 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

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at