Exercises — Rule of Zero — prefer compiler-generated specials

Both members are int — plain value types, no resource. Memberwise copy/move/destroy is correct. So Rule of Zero holds. The compiler generates all 5 specials (plus the default constructor). Hand-written specials needed: 0.

(a) No — std::string is RAII, self-managing → Rule of Zero. (b) Yes — raw owning pointer, non-RAII → forces Rule of Five. (c) No — unique_ptr is RAII → Rule of Zero. (d) Yes — FILE* has no standard RAII wrapper → must wrap it. Count of members that break Rule of Zero: 2 (b and d).

False. Rule of Zero means zero hand-written resource logic (no bodies babysitting a raw resource). Writing T() = default; to keep a default constructor after adding another constructor is perfectly within the spirit — you wrote no ownership code.

Log() is a default constructor, which is not one of the five specials — it does not trip the suppression rule. So:

• User-declared specials (of the five): 0.
• Compiler-generated specials: 5 (dtor, copy-ctor, copy-assign, move-ctor, move-assign), all correct via vector<string>. Adding a member function like add never affects special generation.

Replace the raw int* + size_t with a self-managing std::vector<int>:

class Buffer {
    std::vector<int> data;
public:
    explicit Buffer(size_t n) : data(n) {}
};

We removed the 5 declared specials. Counting the special-function lines shown (dtor, copy-ctor, copy-assign, move-ctor, move-assign = 5 declarations), all are gone. Hand-written specials: from 5 → 0.

Declaring any destructor trips the suppression gate: the compiler no longer generates the move constructor and move assignment. It still generates copy-ctor and copy-assign.

• Generated: dtor (user's), copy-ctor, copy-assign = the class becomes copy-only.
• Bug: every "move" of a Session now silently deep-copies the whole vector<char> — potentially huge and slow. See the gate figure. Fix: delete the logging dtor, or explicitly = default all five to restore moves (but prefer to log elsewhere).

unique_ptr is movable but not copyable; std::string is both.

• Copy: the implicit copy-ctor would need to copy every member. Since unique_ptr's copy is deleted, the compiler implicitly deletes Widget's copy-ctor and copy-assign. So Widget is not copyable.
• Move: both members are movable, so the compiler generates a correct move-ctor/move-assign. Widget is movable. Result: Widget is move-only, exactly as intended, with 0 hand-written specials.

shared_ptr is copyable (bumps refcount) and movable; int is trivially both. No member disables anything. So the compiler generates all 5 specials, all correct: copy shares ownership, move transfers it, destroy decrements the count. Hand-written: 0.

Isolate the danger in one RAII type (Single Responsibility Principle):

class FileHandle {                     // the ONLY class with specials
    FILE* f;
public:
    explicit FileHandle(const char* p) : f(std::fopen(p,"r")) {}
    ~FileHandle()                       { if (f) std::fclose(f); }
    FileHandle(FileHandle&& o) noexcept : f(o.f) { o.f = nullptr; }
    FileHandle& operator=(FileHandle&&) noexcept;
    FileHandle(const FileHandle&)            = delete;
    FileHandle& operator=(const FileHandle&) = delete;
};
 
class Logger {
    FileHandle h;                      // Rule of Zero here!
    std::string name;
};  // Logger writes ZERO specials; move-only, copy disabled — inherited from FileHandle.

• Classes writing specials: 1 (FileHandle).
• Specials FileHandle declares: dtor, move-ctor, move-assign, deleted copy-ctor, deleted copy-assign = 5.
• Specials Logger writes: 0. Logger is move-only because FileHandle is.

When a vector grows it reallocates. It will move existing elements into new storage only if the move is noexcept — otherwise it copies them to preserve the strong exception guarantee. But Logger/FileHandle are non-copyable! So without noexcept, vector<Logger> growth would fail to compile (no copy available) or be forced down the copy path. Marking moves noexcept lets the vector move safely. See noexcept and move operations.

• Value (deep) copy, Rule of Zero: use a value-semantic wrapper that clones on copy (e.g. a "polymorphic value" type, or store std::vector<Node> directly so children copy deeply). Copy produces an independent subtree; still 0 hand-written specials because the member's own copy is deep.
• Shared semantics: use std::shared_ptr<Node>. Copy is cheap and shares the same children (refcount++), not an independent subtree. The choice of member dictates copy behaviour — you never write the copy constructor; you pick it. Compare with Rule of Three and Rule of Five, where you'd hand-craft the deep copy instead.

• Vec3: three doubles → 0 hand-written.
• Mesh: vector + string, both RAII → 0.
• GpuBuf: raw unsigned OS-like handle → must write specials: dtor + move-ctor + move-assign + 2 deleted copies = 5 declared.
• Model: members are Mesh (Rule of Zero) and unique_ptr<GpuBuf> (RAII) → 0. Because unique_ptr is move-only, Model is move-only automatically. Total hand-written specials across the system: 5, all confined to the single resource-owning GpuBuf. Every other class writes 0. Verdict: the system is "Rule of Zero throughout" in the intended sense — resource logic is isolated to exactly one audited type, and no business class writes a special. This is Rule of Zero + Single Responsibility working together.

The reflex ::: Ask "does this class directly own a non-RAII resource?" — if no, write zero specials. The gate ::: Declaring any of {dtor, copy-ctor, copy-assign} silently deletes the free move-ctor and move-assign.