You replace new and delete for order objects with a bump pointer arena reset at the end of each session. State the four correctness requirements this puts on the order type and on the arena, quantify what it buys, and say what it forbids that the general allocator allowed.

You replace new and delete for order objects with a bump pointer arena reset at the end of each session. State the four correctness requirements this puts on the order type and on the arena, quantify what it buys, and say what it forbids that the general allocator allowed.

Approach: Think about where the object is constructed, who runs the destructor, what alignment the arena must return, and what happens to an object that outlives the reset.

The arena must hand back storage whose alignment is at least alignof of the type, the object must be constructed with placement new into that storage, the destructor must be called explicitly because resetting the pointer does not run it, and no object may outlive the reset. A bump allocation is an add and a bounds check, roughly 2 nanoseconds against 50 to 100 nanoseconds for a general malloc under contention, which is the reason to do it at all. Resetting is one pointer store, so any order still referenced afterwards becomes a dangling pointer, and any member holding its own allocation, such as a string or a vector, leaks unless the destructor ran. What the arena forbids is independent lifetimes: you can no longer free one order early and reuse its space, so a session with a long tail of live orders holds its peak footprint until the reset. Requiring the stored type to be trivially destructible removes the destructor obligation and is the usual discipline.

Follow-up: How would you make it a compile error for someone to add a string member to the arena-allocated type?

Key concepts: arena allocator, placement new, alignment, trivially destructible, dangling pointer.