Add resize_and_overwrite (reworked #53)

[martinus]

Reworks #53 by @Andersama. Their original commit is preserved as the first commit here, so merging this closes #53 as merged.

The idea is good and matches where the discussion in #49 landed. The implementation had three defects, all verified by running it.

1. op received the wrong number

std::string::resize_and_overwrite(count, op) calls op(p, count) — the requested size. The original called op(p, current_size) — the old size:

resize_and_overwrite(8) on a size-3 vector:
  libstdc++ std::string  ->  callback gets n=8
  #53 as submitted       ->  callback gets n=3

Same signature, different meaning, no diagnostic. A callback written against the cppreference example the PR cites as its guide would think it has 3 writable slots when it has 8. This is the defect that most needed fixing, since it is silent.

2. Double destruction if op throws while shrinking

The tail was destroyed via destroy_n but the stored size was left untouched while op ran, so ~svector() destroyed those elements again:

ERROR: AddressSanitizer: attempting double-free
  #9  svector<std::string, 2>::destroy() svector.h:525
  #10 svector<std::string, 2>::~svector() svector.h:600

3. Full element leak if op throws while growing

Elements were moved into the new storage and set_indirect was called, but the size stayed 0 until after op returned, so an exception lost all of them: Direct leak of 190 byte(s) in 5 object(s).

The rework

reserve() first, commit the shrunken size before calling op, commit op's result after. At every point where op can throw, the stored size describes exactly the live elements. This also makes it a lot shorter, since reserve() and the non-template set_size() already handle the direct/indirect split.

Also dropped constexpr — svector uses reinterpret_cast, memcpy and placement new, so it can never be constant-evaluated, and nothing else in the API claims it.

Tests

New test/unit/resize_and_overwrite.cpp, 11 cases: the op(p, count) contract, growth within and past inline capacity, shrinking, returning less than count, resize to 0, non-trivial element types, that no value-initialization happens, and both throwing-op paths. Counter verifies every element is destroyed exactly once.

5 of the 11 fail against the original implementation (n == 0 gets 10, n == 50 gets 2, plus ERROR at ~Counter(): got 2 objects still alive! / SIGABRT), so they are real regression guards rather than decoration.

Full suite: Ok: 2, Fail: 0. Lint clean.

Note on scope

resize_and_overwrite is string-only in C++23, so this is a non-standard extension to a vector either way — that part is your call. If it goes in, it should match the standard signature exactly, which it now does.

Depends on #56 for CI; this branch is based on the pre-fix main, so its checks will be red until that merges.

🤖 Generated with Claude Code

[Andersama]

Apologies about the exception safety, I tend to work with POD-like types where destruction is trivial and exceptions don't tend to get thrown.