On Fri, Apr 24, 2026 at 7:27 AM Ion Gaztañaga via Boost < boost@lists.boost.org> 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