2 posts tagged with "Code"

This document supplements, rather than replaces, the original pop_range design document. It covers three points a reviewer raised after that document was published, the verification done for each, the resulting code changes, and the measured before/after behavior. The original document's design rationale, history section, and prior-art research are unchanged and still apply; only the three areas below have moved since that write-up.

0. Context​

The original pop_view<A>::operator* returned a copy (value_type), the supported container shape was fixed to pop() + top()/front() (i.e. only stack, queue, priority_queue), and size()/sized_range was deliberately left unimplemented. A reviewer pointed out that all three of these were more conservative than necessary. Each point below was checked independently — against the actual wording of the relevant concepts, and against a compiled, sanitizer-clean test — before being adopted.

1. Motivation​

std::stack, std::queue, and std::priority_queue are container adaptors: thin wrappers around an underlying sequence container (vector, deque, list) that expose a deliberately restricted interface — push, pop, top/front, empty, size. None of them expose begin()/end(). This is not an oversight; it is a design decision inherited from the original SGI STL, whose documentation states outright that priority_queue "does not allow iteration through its elements." The rationale is that the adaptor's whole contract is "you may only ever see the current top/front element," and exposing arbitrary iteration would leak the underlying container's storage order (vector's heap layout, in the case of priority_queue), which is not part of the abstraction.

The consequence is that these three types cannot participate in the modern iteration and composition idioms C++ has accumulated since C++11 — range-based for, and since C++20, the <ranges> view/pipe machinery — because both require some notion of begin()/end(). This document describes pop_range, a small header-only library that closes that gap by giving these adaptors a well-defined, honestly-named destructive view: iterating it doesn't just read the adaptor, it drains it, one pop() per increment.