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

Subject: Re: [boost] [review] Review of PolyCollection starts today (May 3rd)
From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2017-05-08 19:18:53

El 08/05/2017 a las 15:48, Adam Wulkiewicz via Boost escribió:
> Ion Gaztañaga Via Boost wrote:
>> The formal review of Joaquín M. López Muñoz's PolyCollection library 
>> starts today. [...]
> The library looks very well and I think it'd be a valuable 
> contribution to Boost.

Thank you!

> 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.

IMHO this is an entirely different beast that happens to share the same 
underlying data
structure as Boost.PolyCollection, but the apropriate interface would 
look different: no
type registration, no type restitution, typed local_iterator's should 
have to go, etc. I think
this would be best served by another, unrelated library.

> 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.

Throughout the docs the word "container" is used in a non-standardese 
sense, as you
correctly point out. On the reference, however, the concept 
PolymorphicCollection is
defined as a refinement of PolymorphicContainer 
(http://tinyurl.com/m9yh3hq ), which
is explicitly defined as resembling, but not the same as a standard 
Container. The part
about 23.2.1.3 is not listed among the differences, and I should include 
it as well (thanks!).
BTW, the standard itself is rather lousy with respect to the Container 
concept. For instance,
[forwardlist.overview]/1 says

   "A forward_list is a container that supports forward iterators..."

only to state in the next parapragh that

   "A forward_list satisfies all of the requirements of a container 
(Table 96), except that
   the size() member function is not provided and operator== has linear 
complexity."

So, in the end, forward_list is *not* a container :-)

Joaquín M López Muñoz