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<allocator_type>::construct should be called only for the element type (23.2.1.3) but poly_collection contains std::unordered_map and packed_segment contains std::vector which constructs objects of their own value types. Also Models call operator new in make function. If that's correct and I'm not missing anything then I suggest using the word "collection" consistently in the docs. Regards, Adam