Exceptional C++ Style: 40 New Engineering Puzzles, Programming Problems, and Solutions

An index view reduces moving, but also introduces consistency responsibilities

Item 34 pp. 246–257; Item 35 pp. 258–266; Item 36 pp. 267–285

The index-table case in Item 34 shows that clarity and efficiency are not inherently in conflict. If the user only needs a new reading order, it is not necessary to move large objects or copy entire batches of records; sorting a lightweight index alone can preserve the original data layout. This is not a free abstraction: after the source container is erased or rearranged, indexes may point to different records; merely modifying a sort key can also make the old index unordered. Design should make explicit the validity period of the index and when to rebuild it. Item 35's criticism of unnecessary type restrictions likewise applies to not introducing unused frameworks for the sake of generality; Item 36's alignment and lifetime checks remain important today, but historical rules about union member restrictions cannot replace C++20 rules, and common variant values should prefer the standard variant.