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