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.
> 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
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 (18.104.22.168) 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
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 22.214.171.124 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,
"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
So, in the end, forward_list is *not* a container :-)
JoaquÃn M LÃ³pez MuÃ±oz