On 10/3/17, Steven Watanabe via Boost-users <boost-users@lists.boost.org> wrote:
PolyCollection uses contiguous storage (aka std::vector). This requires copying when the segment is resized.
Ahh that makes sense. Just throwing a random idea out here: would a semi-contiguous design be possible? PolyCollection could maintain a list of [contiguous] segments, something along the lines of how "extents" work in the filesystem world? You could get 99% cache hits and only a few misses when jumping to the next segments. idk maybe this idea sucks xD. On 10/4/17, Ion Gaztañaga via Boost-users <boost-users@lists.boost.org> wrote:
But I understand users don't care about the internal reallocation,
Usually that's the case, but PolyCollection is... more or less... just a more efficient way of storing/processing a list<interface*>. If you don't care about the internals, then you don't care about efficiency, and you should just use list<interface*> (or vector or whatever). Thanks for that workaround Joaquin M López Muñoz. It's interesting, but not quite what I'm looking for (want both move and copy constructors deleted). d3fault