Re: [boost] Review Request: poly_collection

Subject: Re: [boost] Review Request: poly_collection
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-03-01 22:15:03

Le 01/03/2017 à 09:32, Joaquin M López Muñoz via Boost a écrit :
> Hello,
>
> I'd like to ask for formal review of (candidate) Boost.PolyCollection, 
> a library providing
> fast containers of polymorphic objects:
>
> https://github.com/joaquintides/poly_collection
> http://blincubator.com/bi_library/polycollection/?gform_post_id=1643
> http://rawgit.com/joaquintides/poly_collection/website/doc/html/index.html 
>
>
> 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:
>
> * boost::base_collection
> * boost::function_collection
> * boost::any_collection
>
> dealing respectively with classic base/derived or OOP polymorphism, 
> function
> wrapping in the spirit of std::function and so-called duck typing as 
> implemented by
> Boost.TypeErasure.
>
> The library compiles and runs succesfully in Visual Studio 2015, GCC 
> 5.2.1 and
> Clang 3.7. Ion Gaztañaga has kindly volunteered to act as the review 
> manager for
> (candidate) Boost.PolyCollection.
Hi,

thanks for proposing this library Joaquîn.

I've surely missed why base_collection is named this way. Is it because 
the parameter is a base class. Could you confirm?

On the documentation you compare

     base_collection<T> and ptr_vector<T>

     function_collection<T()> and vector<function<T(U)>>

     any_collection<Concept> and vector< |type_erasure::|any<Concept>>

wondering if a single class with specializations wouldn't help

     collection<polymorphic<T>>
     collection<function<T(U)>>
     collection<any<Concept>>

In this way we could have

     collection<Model, Allocator>

BTW, I see that you have in the implementation a 
detail::poly_collection<Model, Allocator> that is the base of the 3 
collections.

In your blog there were some comments about a collection of variants. 
Have you considered adding a variant_collection<Ts...>

This collection could support ordering and hash. In addition, it could 
be preregistered.

As the collections are closer to multisets (unordered/not-hash), maybe 
it is worth using this name.

Have you think about using the same design for maps/unordered maps of 
polymorphic objet (where the key is not polymorphic)?

There is a C++ proposal for a polymorphic_value 
(https://github.com/jbcoe/polymorphic_value/blob/master/draft.md). Your 
base_collection<T> corresponds quite well to this polymorphic_value<T>, 
isn't it?
Maybe polymorphic_collection<T> or collection<polymorphic<T>>
The main difference is the memory management, polymorphic_value can be 
adapted to use an Allocator.

What are the function types passed to for_each whee we have a 
function_collection or a any_collection? Is a reference to the
|value_type? |Do we need generic lambdas?

Best,
Vicente