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