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