Question bank — Rule of Zero — prefer compiler-generated specials

True. Every member already knows how to copy, move, and destroy itself, so the compiler's memberwise generation composes correct behaviour — this is exactly Rule of Zero.

False. Declaring any destructor suppresses the implicitly generated move constructor and move assignment, so the class silently degrades to copying even though the body is empty.

False. Merely declaring the destructor — even as = default — still suppresses the implicit moves. The suppression is triggered by the declaration, not by whether you supply a body.

False. Rule of Zero forbids hand-written resource logic, not keystrokes. Declaring Widget() = default; to restore a default constructor after adding another constructor is perfectly within its spirit.

False. unique_ptr is not copyable, so the compiler implicitly deletes the copy operations of the enclosing class. It becomes move-only — which is usually exactly what you want.

True. The compiler-generated move operations are noexcept if and only if every member's corresponding move is noexcept, so the guarantee propagates automatically — see noexcept and move operations.

True. vector supplies a correct destructor, deep copy, and cheap move, so the destructor you were forced to write vanishes and the whole Rule-of-Five cascade collapses to zero.

False. Copying a shared_ptr shares ownership of the same object (bumps a reference count); it does not clone the pointee. The copy is correct but shallow-shared, per std::shared_ptr — shared ownership.

It is the opposite of Rule of Zero. The raw owning int* plus the hand-written ~S triggers the Rule of Five, and the still-default copy constructor now double-frees. Replace int* with std::vector<int>.

Declaring a copy constructor stops the compiler from generating the move constructor and move assignment. The class silently falls back to copying — you have re-entered the Rule of Five and must now write the moves by hand too.

= default on the copy constructor tries to copy a unique_ptr, which is non-copyable, so the defaulted copy is defined as deleted. The class is still not copyable and you've added noise. Use shared_ptr or a clone helper instead.

This scatters manual ownership across a business class, violating the Single Responsibility Principle. Wrap the FILE* in one small RAII FileHandle, then let Logger follow Rule of Zero.

The hand-written copy constructor is redundant (memberwise copy already does this) and it suppresses the implicit move operations, so A now copies where it could have moved. Delete the copy constructor entirely.

The debug destructor kills the implicit moves, so every "move" becomes a copy. Log from a scope guard or elsewhere; do not pay the move-suppression tax for a print statement.

A destructor usually signals manual ownership, so the default copy is now likely wrong (double-free), and post-C++11 the destructor also blocks implicit moves — so you must supply copy and move operations yourself.

Because it composes the already-correct copy/move/destroy of each member. The compiler simply calls each member's own vetted operation, so correctness is inherited rather than re-implemented and re-bugged.

Unique ownership means "exactly one owner," so a copy would be semantically meaningless. The compiler deleting copy for you enforces the intended single-ownership contract with zero =delete typing.

Isolating manual new/delete/handle logic into one small, audited RAII type means only that type risks ownership bugs. Every consumer stays a clean Rule-of-Zero class, applying single responsibility.

For a value type, copying the bytes yields an independent equal object. For a raw owning pointer, memberwise copy duplicates the address, so two objects share (and both later free) one buffer — a double-free.

Copy-and-swap is a technique for writing a correct assignment when you must write specials at all. Under Rule of Zero you write no assignment operator, so the idiom simply never arises.

All special members are generated and trivial. It copies, moves, and destroys as no-ops, so it fully satisfies Rule of Zero by default.

No. The reference count drops but stays above zero while other copies live. The pointee is freed only when the last shared owner is destroyed, so the surviving copies remain valid.

No. Declaring T() = default; to bring back the default constructor writes no resource logic, so you remain within Rule of Zero — "zero hand-written ownership," not "zero declarations."

Copy assignment and move assignment are implicitly deleted, because you cannot re-assign a const member or rebind a reference. The class stays constructible/copyable but not assignable — and you wrote none of that yourself.

Yes, but the "move" falls back to copying that member, since a move that can't move safely copies instead. The class still moves overall; it just isn't cheap for that member.

The class's generated move becomes non-noexcept, so std::vector growth will copy rather than move elements to preserve its strong exception guarantee — a silent performance loss traced back to that one member (see noexcept and move operations).