Why Iterators Got It All Wrong
summary
Argues that C++ iterators conflate two distinct concepts — elements vs borders — and that ranges/views/adapters (transform, filter, reverse) expose ambiguous semantics when you call base or mix searches with upper/lower bounds. Tests against ~1M LOC show concrete patterns: find yields 201 unique-match uses, find_if 67 single matches, lower_bound 89 predicate checks, upper_bound 17 border uses (7 decremented). Proposes typed nullable elements, distinct border APIs and refinements like find_unique, element_before/after and return-specifiers to make code correct and clearer.
AI-written summary · about
chapters (21)
- 0:00Introduction to iterators
- 1:49Containers vs views in C++20
- 3:13Problems with iterator pairs
- 5:22Transform adapter for projections
- 8:53Base iterator semantics
- 10:18Borders vs elements in reverse
- 13:08Filter adapter ambiguity
- 16:59Why reverse adapter fails
- 19:29General adapter problems
- 21:57Need for border and element types
- 23:00Analysis of real-world code
- 26:09Symmetry in borders and elements
- 27:13Nullability of elements
- 28:14Element and border functions
- 30:20Nullable elements and find
- 31:22Find unique and trimming
- 32:45Advanced range utilities
- 35:11Implementation details
- 35:52Why iterators are flawed
- 36:35Library improvements needed
- 37:00Q&A
related talks
31mWhy Iterators Got It All Wrong — and what we should use instead
57mRange Algorithms, Views and Actions: A Comprehensive Guide
01h 13mFrom Iterators to Ranges — the Upcoming Evolution of the Standard Library
01h 28mUnderstanding the Filter View to Use It Right
01h 25mComparing 'Classic C++' and 'Modern C++' Ways to Solve Programming Tasks
57mSome Things C++ Does Right
50mWhat a View! Building Your Own (Lazy) Range Adaptors (part 1 of 2)
01h 36mC++ Standard Views