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