|
Boost : |
Subject: [boost] poly_collection (was sentinels vs iterators)
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2014-08-23 18:16:32
El 23/08/2014 20:53, Joaquin M Lopez Munoz escribió:
> Mathias Gaunard <mathias.gaunard <at> ens-lyon.org> writes:
>
>>
>> On 21/08/2014 12:12, Joaquin M Lopez Munoz wrote:
>>> Some
>>> months ago I explored a container-like construct for polymorphic
>>> objects that group elements by run-time type so as to greatly
>>> speed up for_each processing:
>>>
>>> http://bannalia.blogspot.com.es/2014/05/fast-polymorphic-collections.html
>>
>> IMHO you're comparing oranges and apples, the memory layout and
>> traversal properties are entirely different.
>
> Absolutely, this is precisely the point of the article: if you are managing
> collections of polymorphics objects and traversal order is not relevant,
> you are probably better off using something like poly_collection (or the
> intrusive structure you mention) rather than
> std::vector<std::unique_ptr<Base>> (or boost::ptr_vector<Base>, for that
> matter).
An interesting data structure. Erasure also seems a bit curious. I guess
you could implement it with an iterator that maybe contains a pointer to
a base class and:
-> calls each segment::erase(it);
-> if the segment detects the address of the base is inside vector's
memory, then :
a) Derived *pderived = static_cast<Derived*>(it.base)
b) vec_it = segment.vector.begin() + (pderived - &vector[0])
c) segment.vector.erase(vec_it);
A container that is not a sequence, unordered but not associative.
unordered_collection might be an alternative name. An interesting
addition to Boost.Container? ;-)
Best,
Ion
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk