Do any Ranges view-adaptor types (from `std::views`) rely on heap allocation?

Question

I know that at least most Ranges view types don't require any heap-allocation. For example, you can take a C array on the stack and pipe it through std::views::take(42) without causing any heap-allocation.

But I know that there are lots of obscure view adaptors, e.g. views::join, views::istream, views::chunk_by, with more coming every year, and just because most view adaptors today clearly don't allocate (in common situations) doesn't mean that all view adaptors will never allocate.

By way of analogy: I know that most Standard Library algorithms don't require any heap-allocation. For example, you can take a C array on the stack and std::ranges::partition it without causing any heap-allocation. But there are a few algorithms (std::inplace_merge, std::stable_sort, std::stable_partition; and their std::ranges counterparts) that do perform runtime heap-allocation. We've already got an SO question tracking which algorithms heap-allocate.

Therefore, I'm asking for an up-to-date answer (that might even be maintained/updated in the future): Do any of the std::views:: adaptors require heap-allocation, on any major STL vendor's implementation? If so, which ones and why?

Answer 1

No view currently in the standard library or expected to be proposed for C++26 (see P2760) is required to allocate memory on its own.

• generator of course may allocate for the coroutine machinery (the exposition-only unique_ptr<stack<coroutine_handle<>>> member won't be present in any high-quality implementation)
• many views need to hold user-provided objects that themselves can dynamically allocate memory (e.g., a single_view<vector<string>>.

any_view - if it were to be proposed - would.