Wrap an OS handle in RAII

Take a raw resource the operating system hands you as an integer — a file descriptor — and give it a C++ owner. Small, unglamorous, and it exposes ownership faster than any amount of talking about it.

Learn

RAII, move semantics, the rule of five, explicit constructors, why a close policy belongs in the type rather than at the call site.

Ask an AI to teach you this

I'm preparing for a quant developer interview and I'm implementing: "Wrap an OS handle in RAII"
What I'm building: Implement an FdHandle: move ctor/assign, release, reset, get, operator bool, deleted copy operations, and a close policy supplied as a template parameter so the same type can own a socket or a mapped region.
Concepts I need to own: RAII, move semantics, the rule of five, explicit constructors, why a close policy belongs in the type rather than at the call site.

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

Implement an FdHandle: move ctor/assign, release, reset, get, operator bool, deleted copy operations, and a close policy supplied as a template parameter so the same type can own a socket or a mapped region.

Check

You're done when all of these are true:

Self-move neither leaks nor double-closes
Copy operations are `= delete`, not merely private
close() errors are handled rather than swallowed — say what your destructor does when close fails, and why that's the only sane option
Clean under ASAN, and no descriptor leaks under a loop that throws

Ship

A repo with your implementation and its test suite, including the throwing case.

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.

P1 — Socratic tutor (refuses to write code)
P2 — adversarial test suite (try to break my implementation)
P3 — HFT-style code review, ends in hire/no-hire
P6 — defend your design decisions with the code closed

Resources

cppreference — RAII