Re: [boost] [review] Review of PolyCollection starts today (May 3rd)

Subject: Re: [boost] [review] Review of PolyCollection starts today (May 3rd)
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2017-05-08 13:48:58

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