...one of the most highly
regarded and expertly designed C++ library projects in the
world.
— Herb Sutter and Andrei
Alexandrescu, C++
Coding Standards
A number of features asked by reviewers and users of Boost.PolyCollection are considered for inclusion into future versions of the library.
Boost.PolyCollection can be extended to use Boost.TypeIndex
in RTTI-challenged scenarios. Taking this idea further, it is not unusual
that some environments (game engines, for instance) provide their own RTTI
framework: an even more ambitious extension to Boost.PolyCollection would
then be to make it configurable for user-provided RTTI through some sort
of traits class specifying replacements for std::type_info
and typeid
.
boost::base_collection
requires that stored objects
be MoveConstructible
and MoveAssignable
;
unfortunately, it is customary to restrict copying in OOP hierarchies to
avoid slicing, which would force users to revisit their class definitions
in order to use Boost.PolyCollection. This can be alleviated by offering
a configurable traits class where copy and assignment can be defined externally
template<typename T> struct copy_traits { void construct(void*,T&&); void assign(T&,T&&); };
with default implementations resorting to regular placement new
and T::operator=
.
C++17 introduces parallel
algorithms, like for instance a parallel version of std::for_each
;
it is only natural then to provide the corresponding Boost.PolyCollection-specific
algorithms. The segmented nature of polymorphic collections makes
them particularly amenable to parallel processing.
Closed polymorphism is a kind of dynamic polymorphism
where the set of implementation types is fixed at definition time: the prime
example of this paradigm in C++ is std::variant
.
Although boost::any_collection<boost::mpl::vector<>>
can act as a sort of replacement
for std::vector<std::variant<T1,...,TN>>
, this is in fact more similar to
a std::vector<
std::any
>
, and a collection class boost::variant_collection<T1,...,TN>
could be designed to better model closed polymorphism and take further advantage
of the fact that implementation types are fixed (for instance, internal virtual
calls can be completely eliminated). From a conceptual point of view, this
would require introducing a new ClosedPolymorphicCollection
notion and renaming the current PolymorphicCollection
model to OpenPolymorphicCollection
.
Users have expressed interest in polymorphic collections where elements are
kept ordered within their segment and optionally duplicates are excluded,
much like boost::flat_set
/boost::flat_multiset
do over their internal data vector. The open question remains of whether
these collections should also guarantee some order between segments (current
ones don't) to allow for the definition of container-level operator<
and related operators.