Boost logo

Boost Users :

Subject: [Boost-users] PolyCollection requiring copyable
From: d3fault (d3faultdotxbe_at_[hidden])
Date: 2017-10-04 00:56:34

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

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

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.


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