A proof of concept of a semistable C++ vector container

New C++ “bookmark-safe” vector drops — fans cheer, skeptics cry overkill

TLDR: A new vector prototype keeps your “bookmarks” tracking items even after edits using an epoch trick. Commenters are split: clever idea vs. heavy overhead, missing invalidation checks, and thread‑safety gotchas—cool demo, but many ask for a clearer real‑world payoff.

Semistable::vector, a proof‑of‑concept C++ container, promises the impossible: your “bookmark” into a list stays on the same item even after you shuffle things around. It does this with an epoch trail—little history notes that help iterators (your bookmarks) adjust themselves after inserts, erases, or buffer moves. It’s header‑only, keeps data packed tight, and even offers a raw pointer mode so speed can match normal vectors when you need it.

Then the comments lit up. One camp cheers the cleverness—“debug‑style iterators done right”—while practical folks roll eyes: why not just copy the value when you need it? Others poke holes: no simple way to tell if a bookmark got invalidated, and thread‑safety caveats mean you can’t casually share iterators across threads. Tech historians cracked jokes: “You’ve reinvented Emacs markers,” while a veteran asked for a lighter design (just track the last valid element). Meanwhile, performance nerds questioned the real‑world payoff versus heavier iterators. The spiciest debate: genius for tricky editing workloads, or overengineered cosplay for standard containers? The mood: intriguing, divisive, and meme‑ready—one commenter swore the new end() is more stable than their sleep schedule.

Key Points

  • semistable::vector is a header-only C++ container that keeps iterators stable while storing elements contiguously and offering a std::vector-like API.
  • Iterator stability is achieved via epoch descriptors that record mutations; iterators traverse these epochs to adjust their positions on use.
  • Benchmarks (0.5M elements) compare traversal, end insertions, erase_if of odd elements, and sorting across std::vector, std::list, and semistable::vector.
  • Using iterator.raw() (or std::to_address) for traversal and sorting yields performance equivalent to std::vector in those cases.
  • Thread-safety limitations: iterators are not safe for concurrent use across threads or alongside thread-unsafe operations, though const member functions are thread safe.

Hottest takes

“Adorable: they've reinvented Emacs markers” — quotemstr
“Seems like a very heavy price to pay” — shin_lao
“No way to detect if an iterator was invalidated?” — unnah
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.