Re: [Boost-users] PolyCollection requiring copyable

Subject: Re: [Boost-users] PolyCollection requiring copyable
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-10-04 02:16:57

AMDG

On 10/03/2017 06:56 PM, d3fault via Boost-users wrote:
> I'm impressed with PolyCollection. I use the list<interface*> 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<interface*> 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