Subject: Re: [boost] Review Request: poly_collection
From: Joaquin M LÃ³pez MuÃ±oz (joaquinlopezmunoz_at_[hidden])
Date: 2017-03-02 09:41:25
El 01/03/2017 a las 23:15, Vicente J. Botet Escriba escribiÃ³:
> Le 01/03/2017 Ã 09:32, Joaquin M LÃ³pez MuÃ±oz via Boost a Ã©crit :
>> I'd like to ask for formal review of (candidate) Boost.PolyCollection
> thanks for proposing this library JoaquÃ®n.
Hi Vicente, thanks for your interest.
> I've surely missed why base_collection is named this way. Is it
> because the parameter is a base class. Could you confirm?
Exactly. base_collection<Base> pretty much behaves as a container of
> wondering if a single class with specializations wouldn't help
> 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
This is mostly a naming issue. Indeed the three collections derive from
implementation and could be publicly provided as specializations of the
if this is what reviewers lean towards. Personally I like it better to
separated as in the current proposal.
> In your blog there were some comments about a collection of variants.
> Have you considered adding a variant_collection<Ts...>
I've thought about it. Such a collection would deviate from the others
both in terms
of its interface (no type registration, for instance) and implementation
structure detail::poly_collection relies on could be used to support
more efficient implementations exist for this particular case.
> As the collections are closer to multisets (unordered/not-hash), maybe
> it is worth using this name.
I'd say similarities with unordered_multiset are superficial (segments
buckets) and the interfaces ultimately are too different. I chose
the term is not overloaded in the STL or Boost.
> Have you think about using the same design for maps/unordered maps of
> polymorphic objet (where the key is not polymorphic)?
Same-type contiguity is an essential feature of PolyCollection: I fail
to see how this
could be preserved for an associative container. Care to elaborate?
> There is a C++ proposal for a polymorphic_value
> 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.
base_collection<T> behaves approximately as a
the crucial difference being that the former groups elements by concrete
contiguous chunks of memory, while the latter holds indirection pointers
scenes, so there is no real memory contiguity.
> 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?
These functions are passed a (const) value_type&, where
value_type=any_collection_value_type<Concept> for any_collection<Concept>
(see http://tinyurl.com/hmywnea , http://tinyurl.com/zh9ugl8 ). Now,
restitution is used (http://tinyurl.com/gopdpuz ), and only then, the
passed a (const) Ti& for each of the restituted types Ti: in this case,
a generic lambda
is a very convenient way of taking advantage of this, but you can also
resort to a
polymorphic functor if you wish.
JoaquÃn M LÃ³pez MuÃ±oz
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk