Unordered polymorphic collections
During Q3 2026, I’ve been working in the following areas:
Unordered polymorphic collections
The preexisting containers offered by Boost.PolyCollection
(boost::base_collection, boost::function_collection, boost::any_collection,
boost::variant_collection) do not provide full control over the global positioning
of an element, for the simple reason that each element goes to its dedicated,
type-specific segment. At the segment level, though, users can decide where an
element is inserted much as they would with a std::vector, which is, ultimately,
the data structure these segments are based on.
If the user can dispense with intra-segment positioning, segments can be implemented
with a different internal data structure.
Unordered polymorphic collections
(boost::base_unordered_collection, boost::function_unordered_collection,
boost::any_unordered_collection, boost::variant_unordered_collection) internally
use boost::container::hub-based
segments, giving these collections iterator and reference stability. Their performance
profile relative to the existing ordered collections is different: insertion is on
par or even faster, whereas iteration is definitely slower (nothing beats iterating
over a vector). My hypothesis is that iterator stability is a very desirable property
in the kind of scenarios targeted by Boost.PolyCollection — time will tell.
Unordered polymorphic collections will ship with Boost 1.93.
The internal design of Boost.PolyCollection is interesting: all eight collections
are instantiations of the same internal poly_collection class template,
parameterized by a so-called model that encodes:
- The type of runtime polymorphism used (OOP, function wrapping, duck typing,
std::variant-like). - Whether the collection is ordered or unordered.
- Whether the collection is closed (
boost::variant_[unordered]_collection) or open (the rest).
The result is a rich internal structure in which interoperable parts are combined across three independent dimensions. As a reference for interested readers (and for my future self) I’ve written the article “Inside Boost.PolyCollection”, which explains the design in some detail.
Boost.PolyCollection maintenance
boost::container::hub
Boost.MultiIndex
Papergate
(Not related to Boost.) Papergate is an AI tool that takes any WG21 proposal and determines
whether the paper itself answers a simple question: why is this worth standardizing?
Papergate looks at things such as the presentation of alternatives, cost/benefit analysis,
availability of a reference implementation, etc. The goal is not to assess the merits of a
proposal, but merely to check whether the paper addresses the basic questions a human reviewer
will ask before digging into the details. I’ve been working on the md prompt powering Papergate.
Papergate is integrated into wg21.org.
Support to the community
- I’ve been helping a bit with Mark Cooper’s very successful Boost Blueprint series on X.
- Working on a classification of Boost libraries according to their maintenance status (work in progress). This will help us point new volunteers toward those libraries most in need of attention.
- Supporting the community as a member of the Fiscal Sponsorship Committee (FSC).
All Posts by This Author
- 10/02/2026 Unordered polymorphic collections
- 07/01/2026 Hub is here
- 04/02/2026 Hubs, intervals and math
- 01/18/2026 Containers galore
- 10/09/2025 Working on Boost.Bloom roadmap
- 07/01/2025 Boost.Bloom ready for shipping in Boost 1.89
- 04/08/2025 New Boost library proposal and a talk on how to make C++ ranges faster
- 01/05/2025 New container in Boost.PolyCollection, additions to Boost.Mp11 and more
- 10/11/2024 Joaquín's Q3 2024 Update
- 07/06/2024 Joaquín's Q2 2024 Update
- 04/20/2024 Joaquín's Q1 2024 Update
- 01/10/2024 Joaquín's Q4 2023 Update
- 10/27/2023 Joaquín's Q3 2023 Update
- View All Posts...