Ion Gaztañaga Via Boost wrote:
The formal review of Joaquín M. López Muñoz's PolyCollection library starts today.
I'd like to encourage your participation as the proposed library is small and focused, and reviewers don't need to be domain experts to appreciate the potential usefulness of the library and propose improvements.
PolyCollection implements fast containers of polymorphic objects. Typically, polymorphic objects cannot be stored directly in regular containers and need be accessed through an indirection pointer, which introduces performance problems related to CPU caching and branch prediction. Boost.PolyCollection implements a novel data structure that is able to contiguously store polymorphic objects without such indirection, thus providing a value-semantics user interface and better performance. Three polymorphic collections are provided:
The library looks very well and I think it'd be a valuable contribution
to Boost.
But I'm wondering, would it make sense to expand the scope of the
library? Besides storing polymorphic data of the same type based on
run-time info to improve caching there are situations when data might be
divided into hot and cold data based on compile-time info. E.g. a
"vector" of tuples could internally store tuple of vectors and provide
interface allowing to access tuples more or less transparently. Storing
hot and cold data in different but contigeous parts of memory would also
improve caching. Since the principle is similar, would it have sense to
have both types of collections in one library? Not necessarily now, but
if this was a good idea then the name of the library would have to be
changed into something more general.
I noticed that in the documentation a word "container" is used WRT poly
collections. AFAIU this is not correct because poly_collection doesn't
meet the requirements of C++ container as defined in the standard, i.e.
allocator_traits