Re: [Boost-users] PolyCollection requiring copyable

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.

Is "copying" of the polymorphic types necessary for: a) Technical requirement otherwise it wouldn't compile b) Design decision because you think it's superior and helpful c) To facilitate copying of the PolyCollection object itself ....?

If (b) or (c), can there be a slightly altered version of PolyCollection which does not allow/require copying? I'm completely fine (and even happier) _not_ being able to copy the PolyCollection. When I use the list strategy, I tend to consider the list to be the owner of it's objects (and delete them when the list is deleted). There should be PolyCollection::emplace and the poly instances should "live" in the PolyCollection. Accessing the poly instances should be by [const] reference only (isn't this already the case? what benefit does the copy constructor bring?!?).

I didn't examine the source so maybe it's (a) after all, in which case I apologize for wasting precious time, bandwidth, and disk space.

In Christ, Steven Watanabe