Katkat

Repair Unsafe C++ Ownership with Smart Pointers

WayveSoftware Engineer · Technical Screen

Last updated

Review a C++ ownership sketch with raw allocations and redesign its interfaces around RAII and appropriately restrictive smart pointers. Discuss factory ownership, copying and moving, exception safety, non-owning access, shared lifetimes, cycles, and polymorphic destruction.

Repair Unsafe C++ Ownership with Smart Pointers

Review this ownership sketch:

class Engine {
public:
 void start();
};

class Controller {
 Engine* engine_;
public:
 Controller() : engine_(new Engine()) {}
 Engine* engine() const { return engine_; }
};

Controller* make_controller() {
 return new Controller();
}

Identify the lifetime and ownership defects. Redesign the interfaces using RAII and the most restrictive appropriate smart-pointer types. Discuss copying, moving, exception safety, non-owning access, and what would change if an Engine had to be shared by several controllers.

Clarifying Questions to Ask

  • Is a controller the sole owner of its engine in the normal design?
  • Must controllers be copyable, movable, or polymorphic?
  • Can an engine outlive every controller that uses it?
  • Does the factory transfer ownership to its caller?

Follow-up questions

  • When is a raw pointer acceptable in the redesigned API?
  • Why is replacing every raw pointer with `shared_ptr` not a safe default?
  • How would you represent an optional, non-owning observer whose target may disappear?
  • What happens to object layout and destruction through a polymorphic base?