Re: [review] Reminder: The review of boost::container::hub ends April 26

On Fri, Apr 24, 2026 at 7:27 AM Ion Gaztañaga via Boost <
[email protected]> wrote:

> Dear all,
>
> A kind reminder, hub's review will end soon. Please consider taking a
> bit of time to review this interesting container ;-) The proposal is
> small enough anyone can review it and it might be useful for many people!


My vote: ACCEPT

I like the the idea of using bit masks to track occupancy, trading
flexibility for lower per-slot overhead compared to hive. The documentation
specifies: "minimum and maximum block size limits can't be specified and
are fixed to 64". I recommend to leave the block size unspecified (and
remove all mentions of 64 from the documentation).

The implementation is of very high quality, but there are a couple of
issues:

- In my reading the constructors will leak blocks if T's copy/move or the
allocator throws midway, because in this situation ~hub() will not be
called and block_list has no destructor.

- sort_iterator::operator[] uses operator*(*this + n), which I think won't
compile because it's invoking the free operator*.

- transfer_sort allocates the temporary via buffer<T, Allocator> which
allocates via operator new[](n * sizeof(T), std::nothrow), which is
incorrect for over-aligned T.

- the documentation for transfer_sort says that if an exception is thrown,
the order of the elements is unspecified but in fact the resulting state
could be worse than that -- the documentation should say "basic guarantee"
and leave it at that.

- get_iterator should assert if the user passes an invalid pointer. I'd
assert on the mask bit being set.

The biggest issue is the lack of exception-safety tests.

Emil
_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/RPT2LUQ32GNVLHBIU2D7UO552ENXBJ2P/