Re: [Boost-users] PolyCollection requiring copyable

El 04/10/2017 a las 4:16, Steven Watanabe via Boost-users escribió:

AMDG

On 10/03/2017 06:56 PM, d3fault via Boost-users wrote:

...

I'm impressed with PolyCollection. I use the list strategy tons in my projects, and I didn't think NOT using a pointer there was even possible... but somehow you managed. It also makes sense why PolyCollection is faster to execute etc, the tutorial was well written.

The only 'con' is that it requires a copy constructor. You mention later that some copy traits thing can be used to move the "copy code" outside of the class, but I am questioning the need for copying altogether. PolyCollection uses contiguous storage (aka std::vector). This requires copying when the segment is resized.

Adding to Steven's answer, it'd have been feasible to not require move constructibilty/assignability (which is the minimum requisite) but I decided that the resulting available API was not worth it. You can simulate that scenario as follows:     #include     struct not_moveable:std::logic_error     {       not_moveable():std::logic_error("type not moveable"){}     };     struct base     {       virtual ~base()=default;       base()=default;       base(base&&){throw not_moveable{};}       base& operator=(base&&){throw not_moveable{};}     };     struct derived1:base{};     struct derived2:base{};     int main()     {       boost::base_collection<base> c;       c.reserve<derived1>(100);       c.reserve<derived2>(100);       for(int i=0;i<100;++i){         c.emplace<derived1>();         c.emplace<derived2>();       }     } This compiles and works fine; of course, if a segment reallocation is tried (when adding the 101st element) a not_moveable exception is thrown. Joaquín M López Muñoz