A vector with inline storage

A growable array that keeps its first N elements inline and only reaches for the heap when it outgrows them. The growth is easy. Staying correct when an element's copy constructor throws during the move to the heap is the actual exercise.

Learn

Growth strategy, placement new, exception safety guarantees, iterator invalidation, the inline-to-heap transition, why push_back amortises to O(1).

Ask an AI to teach you this

I'm preparing for a quant developer interview and I'm implementing: "A vector with inline storage"
What I'm building: push_back, emplace_back, reserve, resize, iterators, move support, and an inline capacity as a template parameter.
Concepts I need to own: Growth strategy, placement new, exception safety guarantees, iterator invalidation, the inline-to-heap transition, why push_back amortises to O(1).

Run this as implementation coaching, not a lecture. One design decision at
a time. Wait for my code before moving on.

Per decision:
1. Frame it. State the decision in one line, then the options and what each
one costs. Assume I write C++ but have never had this explained properly.
No jargon without defining it.
2. "The 60-second version" — how a strong candidate would DEFEND that choice
out loud. First person, spoken register, no bullets, no headers. That's
what I'm rehearsing.
3. Tell me what to write, and ask me one question about the edge case I'm
most likely to get wrong.

When I show you code, reply in exactly this shape:

Verdict: correct / partly correct / wrong — one line on what's wrong.
What breaks: the input or sequence that breaks it. Only if something does.
Vocabulary: only if I used a wrong or vague term. Give the right one.
Example answer: how I'd defend this design out loud, 30 seconds, first person.
More info: define any term I probably don't know, one line each.
Follow-up probe: the one question an interviewer asks someone whose code
looks like that.

Skip any section that doesn't apply. Don't pad. If it's wrong, say wrong —
don't soften it.

Do not write my implementation for me. If I ask, refuse and ask what I'd
try instead — I need to defend this code with the editor closed.

Do

push_back, emplace_back, reserve, resize, iterators, move support, and an inline capacity as a template parameter.

Check

You're done when all of these are true:

Strong exception guarantee on growth — if an element's copy ctor throws mid-transition, the original contents are untouched. This is the whole point.
You use std::move_if_noexcept and can explain why
Moving the container itself is correct in both states — an inline buffer can't just have its pointer stolen, and you can say what that does to your move complexity
No operator new[] for the raw storage

Ship

Repo plus a benchmark against std::vector at sizes both under and over the inline capacity.

Practice with AI

Use these to make the AI your examiner, not your author. If the AI wrote the code, this node doesn't count — you can't defend a design you didn't make.

P2 — adversarial test suite (try to break my implementation)
P3 — HFT-style code review, ends in hire/no-hire

Resources

cppreference — exception safety guarantees