Question 1

C++ destructors: how many arguments does a destructor take?

Accepted Answer

Introduction / Context: Destructors release resources and perform cleanup when an object’s lifetime ends. Understanding their signature is essential for writing correct RAII classes (Resource Acquisition Is Initialization) in C++. This question asks about the parameter list for a destructor. Given Data / Assumptions: A destructor is written as ~ClassName() in C++. We focus on its parameter rules and overloading possibilities. We consider standard C++ without extensions. Concept / Approach: By definition, a destructor cannot take parameters and cannot return a value. Its spelling includes an empty parameter list. You also cannot overload a destructor; each class has exactly one destructor (which may be implicitly generated, defaulted, deleted, or user-defined). Therefore, the correct completion is that a destructor takes “no” arguments. Step-by-Step Solution: Recall the form: ~ClassName(). Notice the empty parentheses: there are no parameters. Confirm language rule: no overloading and no parameters allowed. Therefore, select “no.” Verification / Alternative check: Attempting to declare ~ClassName(int); fails to compile. Only special cases like virtual destructors change dispatch, not the parameter list. Why Other Options Are Wrong: one/two/three — contradict the C++ grammar for destructors. Common Pitfalls: Confusing destructor parameters with constructor parameters; only constructors may take arguments. Trying to overload a destructor to specialize cleanup paths (use strategy objects instead). Final Answer: no

Question 2

C++ object lifetime for automatic objects: constructors and destructors are called when objects…

Accepted Answer

Introduction / Context: Automatic (stack-allocated) objects in C++ embody RAII: they acquire resources on creation and release them automatically when leaving scope. Knowing precisely when constructors and destructors run enables predictable resource management without manual calls to free or close APIs. Given Data / Assumptions: “Automatic objects” means block-scope variables with automatic storage duration. We are focusing on scope entry/exit behavior. Not considering static storage or dynamic allocation via new/delete here. Concept / Approach: When execution enters the scope where an automatic object is defined, its constructor runs at the point of definition. When execution leaves that scope (normally or via exceptions), the object’s destructor runs automatically, in reverse order of construction for multiple objects. This is the core of exception-safe cleanup and deterministic finalization in C++. Step-by-Step Solution: At scope entry and object definition ⇒ constructor runs. At scope exit (including stack unwinding due to exceptions) ⇒ destructor runs. This pairing ensures resources are released even on early returns or exceptions. Therefore, “enter and leave scope” best captures both calls succinctly. Verification / Alternative check: Instrument a class with logging in constructor and destructor. Observe creation when the variable is defined and destruction when the enclosing block is left, regardless of the exit path. Why Other Options Are Wrong: “inherit parent class” — unrelated to lifetime events. “are constructed” or “are destroyed” — each covers only one side of the lifecycle, not both. Common Pitfalls: Assuming destructors run at program end only; for automatic objects they run at scope exit. Forgetting that static and dynamic objects have different timing rules. Final Answer: enter and leave scope

Question 3

C++ destructors: which statement is correct about naming, return type, and overloading?

Accepted Answer

Introduction / Context: Destructors are special member functions that finalize objects. Their syntax, naming, and constraints differ from ordinary member functions. This question asks which property correctly describes a destructor according to the C++ language rules. Given Data / Assumptions: We are considering ordinary classes (no exotic extensions). Focus on the destructor’s spelling, return type, and overloadability. Concept / Approach: A destructor’s declarator uses the class name preceded by a tilde: ~ClassName(). It has no return type (not even void) and cannot take parameters. There can be only one destructor per class (no overloading), though it may be virtual, defaulted, deleted, or user-defined. Therefore, the correct statement is that a destructor has the same name as the class (with a leading ~). Step-by-Step Solution: Identify the naming rule: ~ClassName() — same base name as the class. Check return type: none; not int or void. Check overloading: disallowed; only one destructor per class. Select the statement that matches these rules. Verification / Alternative check: Any attempt to declare two destructors or to assign a return type will yield compilation errors, confirming uniqueness and lack of return type. Why Other Options Are Wrong: Different name — false per syntax. Returns integer — destructors return nothing. Can be overloaded — not allowed; only one destructor is permitted. Common Pitfalls: Confusing virtual destructors (for polymorphic deletion) with “multiple destructors.” Virtuality does not imply overloading. Final Answer: A destructor has the same name as the class in which it is present.

Question 4

C++ constructors: which statement is correct about naming, return type, and overloading?

Accepted Answer

Introduction / Context: Constructors are special member functions responsible for initializing objects. Their naming and type rules differ from ordinary functions. This question asks which statement best matches the language definition for constructors in C++. Given Data / Assumptions: We review naming, return type, and overloading for constructors. Applies to regular classes under standard C++. Concept / Approach: A constructor has the same name as its class and has no return type (not even void). Constructors can be overloaded: you may define multiple constructors with different parameter lists (default, parameterized, copy, and move constructors). Therefore, the correct statement is that the constructor’s name matches the class name. The distractors claiming different names, integer return type, or prohibition on overloading are all incorrect. Step-by-Step Solution: Confirm naming rule: ClassName(...); — same base name as the class. Confirm return type: none; constructors do not return values. Confirm overloading: allowed with distinct parameter lists. Choose the statement aligned with these facts. Verification / Alternative check: Define multiple constructors with different parameters; compilation succeeds, demonstrating overloading. Any attempt to specify a return type fails to compile. Why Other Options Are Wrong: Different name — violates constructor syntax. Returns integer — constructors have no return type. Cannot be overloaded — false; overloading is idiomatic in C++. Common Pitfalls: Assuming default constructor appears automatically even when other constructors are provided; rules depend on declarations. Final Answer: A constructor has the same name as the class in which it is present.

Question 5

C++ destructors: which statement correctly describes what a destructor destroys?

Accepted Answer

Introduction / Context: Destructors finalize objects by releasing resources and performing class-specific cleanup. A common misconception is that a destructor is tied to particular member types. In reality, destruction is holistic and ordered, covering all subobjects of the instance. This question asks which statement captures that behavior correctly. Given Data / Assumptions: A “complete object” includes its base-class subobjects and data members. Member destruction order is reverse of construction order. Pointers are just values; deleting dynamically allocated memory is a separate operation you may perform in the destructor body. Concept / Approach: When a class’s destructor runs, the language guarantees that first the destructor body executes (your code), then class members are destroyed automatically in reverse order of their declaration, and finally base classes are destroyed last (again, reverse order relative to construction). Therefore, the entire object is torn down, not only specific member categories. If a class owns dynamic resources via pointers, the destructor should release them, but this is your policy code — not an automatic “pointer-only” rule. Step-by-Step Solution: Identify that destruction covers all subobjects: bases and members. Recall order: member fields first (reverse declaration), then base subobjects (reverse inheritance chain). Understand pointer members: unless smart pointers are used, you must explicitly free dynamic memory inside the destructor. Conclude the correct statement is “destroys the complete object.” Verification / Alternative check: Instrument constructors and destructors of members and bases; observe paired creation/destruction logging that spans the full object graph, not just certain types like int or float. Why Other Options Are Wrong: “Only integer/float/pointer members” — destruction is not selective by type; all subobjects participate. Common Pitfalls: Forgetting to free heap allocations held by raw pointers, causing leaks. Misunderstanding that smart pointers automatically manage the lifetime of owned resources during destruction. Final Answer: Destructor destroys the complete object.

Question 6

In C++ (object-oriented programming), can a class declare a virtual destructor? Explain your choice based on polymorphic deletion and best practices.

Accepted Answer

Introduction / Context: Destructors are special member functions that run when an object's lifetime ends. In polymorphic class hierarchies, deleting objects through a base pointer requires the correct destructor to run. This question checks whether a destructor itself can be declared virtual and why that matters. Given Data / Assumptions: C++ class may be used polymorphically via base pointers/references. delete may be applied through a base pointer. We want the most-derived object's resources to be released correctly. Concept / Approach: Yes—C++ allows declaring a destructor as virtual. When a base destructor is virtual, delete basePtr triggers dynamic dispatch so that the derived destructor executes first, followed by base destructors up the chain. This prevents resource leaks and undefined behavior when a derived class owns additional resources. Step-by-Step Solution: 1) Declare in base: virtual ~Base() {}.2) Derive: struct Derived : Base { ~Derived() override { /* release / } };3) Create: Base p = new Derived();4) Delete: delete p; → calls Derived::~Derived() then Base::~Base(). Verification / Alternative check: Instrument destructors with logging; observe derived then base order during deletion via a base pointer when the base destructor is virtual. Why Other Options Are Wrong: No: incorrect—virtual destructors are fully supported.Only for abstract bases / only if other virtuals exist: unnecessary restrictions; you can (and often should) make the base destructor virtual whenever the class is intended for polymorphic use.Compiler-dependent: the behavior is standardized. Common Pitfalls: Forgetting a virtual destructor in a polymorphic base causes only the base part to be destroyed when deleting through a base pointer, leaking derived resources. Final Answer: Yes

Question 7

Constructors vs. destructors in C++: which statement is correct about how they are invoked? Consider implicit calls at scope boundaries and possible explicit use in special cases.

Accepted Answer

Introduction / Context: C++ manages object lifetimes using constructors (initialization) and destructors (cleanup). Most of the time these functions are invoked by the language at well-defined points. This item tests awareness of typical invocation patterns. Given Data / Assumptions: Automatic objects are constructed at definition and destroyed at scope end. Dynamic objects are constructed by new and destroyed by delete. Developers may sometimes write placement new or call constructors explicitly in rare patterns. Concept / Approach: Constructors are often called implicitly (e.g., T x; or new T()). In advanced scenarios (placement new), a constructor can be invoked explicitly. Destructors are typically invoked implicitly at scope exit or via delete. Although C++ permits explicitly calling a destructor, idiomatic and safe resource management relies on the implicit calls, which is the intent behind the conventional MCQ answer. Step-by-Step Solution: 1) Automatic T x; → constructor runs implicitly; at scope end, destructor runs implicitly.2) Dynamic T* p = new T; → constructor via new; delete p; → destructor runs implicitly.3) Placement new: new (buffer) T(args); → explicit constructor syntax exists.4) General rule captured by the option: constructors may be implicit or explicit; destructors (in normal use) are implicitly called. Verification / Alternative check: Instrument constructors/destructors with prints; observe automatic, timely calls without manual invocation in ordinary patterns. Why Other Options Are Wrong: Always explicit/always not called: contradicts standard object lifetime semantics.Destructor always explicit: incorrect in idiomatic C++ (delete/scope end trigger implicit calls). Common Pitfalls: Manually calling a destructor on an object with automatic storage, then letting scope end invoke it again, causes double-destruction. Avoid explicit calls unless you precisely control object lifetimes (e.g., placement new patterns). Final Answer: Constructor is called either implicitly or explicitly, whereas destructor is always called implicitly.

Question 8

Which statement is correct about C++ destructors and their return type? Choose the precise language rule.

Accepted Answer

Introduction / Context: Destructors finalize an object's lifetime and release resources. Their syntax is constrained to ensure predictable cleanup. This question focuses on what a destructor may return. Given Data / Assumptions: Destructor syntax is ~ClassName(). No parameters and no overloading by signature are allowed. Destructors cannot be const, static, or templated in the usual sense. Concept / Approach: By the C++ standard, a destructor has no return type and cannot return a value. Writing any return type (e.g., void) is ill-formed because the grammar fixes destructor declarations to the ~ClassName() form only. Control may leave the destructor normally or by throwing an exception (which is strongly discouraged), but there is never a return value. Step-by-Step Solution: 1) Consider a valid form: struct T { ~T(); };2) Attempt to write void ~T(); → compilation error: return type not permitted.3) Likewise, int ~T(); is invalid for the same reason.4) Therefore the only correct statement is that a destructor has no return type. Verification / Alternative check: Compile test snippets with various faux return types on destructors; compilers reject them according to the grammar. Why Other Options Are Wrong: Void/integer/same as main/boolean: all contradict the fixed grammar for destructors. Common Pitfalls: Attempting to signal cleanup errors via a destructor return value. Use exception-safe design (prefer noexcept destructors) and RAII so failure paths are explicit outside destructors. Final Answer: A destructor has no return type.

Question 9

C++ destructors: passing arguments to a destructor is considered which kind of error? Identify the compile-time classification.

Accepted Answer

Introduction / Context: Destructors have a fixed signature in C++. They cannot accept parameters. This question asks how the language treats an attempt to pass arguments to a destructor. Given Data / Assumptions: Destructor form: ~ClassName(). No parameters permitted and no overloading by parameter list. Call sites use implicit destruction at scope end or delete. Concept / Approach: If you write ~T(42) or declare ~T(int), the code violates the language grammar. Such violations are detected by the compiler's parser and type checker, resulting in a compile-time syntax error (ill-formed program). It is not a runtime or linking concern. Step-by-Step Solution: 1) Valid declaration: struct T { ~T(); }.2) Invalid declaration: ~T(int); → compile-time syntax error.3) Invalid explicit call with arguments: obj.~T(1); → compile-time error.4) Therefore, the correct classification is syntax error. Verification / Alternative check: Test in any conforming compiler; the front end rejects parameterized destructor declarations or calls. Why Other Options Are Wrong: Logical/virtual/linker/runtime: none describe a violation of the language grammar found at compile time. Common Pitfalls: Trying to pass context into a destructor. If cleanup requires data, store it as members beforehand; destructors must remain parameterless. Final Answer: syntax

Question 10

Which statements about C++ constructors in inheritance are correct? Consider access to base members and whether constructors are inherited or callable.

Accepted Answer

Introduction / Context: Understanding how constructors interact with inheritance is essential for designing class hierarchies. This question explores access to base members and the notion of inheriting or invoking base constructors. Given Data / Assumptions: Standard C++ access control: public, protected, private. Derived classes initialize their base subobjects via constructor initializer lists. We consider the classic rule that constructors themselves are not inherited as callable functions on the derived type (ignoring using-inheritance syntax details). Concept / Approach: Derived member functions, including constructors, may access base public and protected members subject to access rules. Constructors are not inherited as ordinary members; instead, a derived constructor explicitly invokes a chosen base constructor in its initializer list. Therefore, statements A and B are correct together, while claiming no access or full inheritance of constructors is wrong. Step-by-Step Solution: 1) Access: within Derived::Derived(), you can read/write Base's protected/public members.2) Invocation: Derived::Derived(args) : Base(base_args) { /.../ }3) There is no syntax to “inherit” constructors as ordinary callable functions (though using Base::Base in modern C++ inherits constructors for overload set construction, not as general callables).4) Therefore, pick “Both A and B.” Verification / Alternative check: Create a Base with protected data and a Derived constructor that initializes it via Base’s constructor; compilation succeeds respecting access control. Why Other Options Are Wrong: C: contradicts access rules.E: misconstrues inheritance of constructors; they are not ordinary inherited methods. Common Pitfalls: Forgetting to call the appropriate base constructor, leading to unintended default initialization of the base subobject. Final Answer: Both A and B.

Question 11

Program termination via std::exit or std::abort: what happens to destructors of automatic (stack) objects in C++?

Accepted Answer

Introduction / Context: Automatic objects normally have their destructors run when their scope ends. However, abnormal or immediate termination paths behave differently. This question targets the behavior of std::exit and std::abort with respect to stack unwinding. Given Data / Assumptions: Automatic storage duration objects reside on the stack. std::exit performs normal termination without unwinding stack frames. std::abort terminates the process immediately. Concept / Approach: When std::exit is called, stack unwinding does not occur, so destructors for automatic (block-scope) objects are not called. Registered atexit handlers run, and static-duration objects may be destroyed. std::abort is harsher: it terminates immediately and does not call destructors or atexit handlers. Therefore, for automatic objects, the correct answer is that destructors are not called. Step-by-Step Solution: 1) Local object inside a function → normally destroyed at scope end.2) Call std::exit(n) inside the function → the function never returns; no stack unwinding → no local destructor calls.3) Call std::abort() → immediate termination; no destructors of any kind are run.4) Therefore: “are not called”. Verification / Alternative check: Insert logging in destructors; compare a normal return path vs. calling std::exit or std::abort to observe the difference. Why Other Options Are Wrong: are called/are created/are inherited: contradict termination semantics.Special-casing main(): termination behavior is not limited to main's locals; the rule concerns stack unwinding globally. Common Pitfalls: Relying on stack object destructors for critical cleanup during process termination; prefer RAII plus ensuring normal shutdown paths, or register handlers as appropriate. Final Answer: are not called

Question 12

When an object's lifetime ends in C++, which special member function of its class is invoked for cleanup?

Accepted Answer

Introduction / Context: Object lifetime in C++ begins with construction and ends with destruction. The language provides special member functions to manage both edges. This question asks you to name the function responsible for cleanup. Given Data / Assumptions: An object is leaving scope or being deleted. Class may hold resources (memory, files, sockets). We want deterministic release of resources. Concept / Approach: The destructor (~ClassName) runs automatically at the end of an object's lifetime. It releases resources and restores invariants. This is the RAII pattern: acquire resources in constructors; release them in destructors, ensuring exception safety and deterministic cleanup. Step-by-Step Solution: 1) Object is created → constructor establishes state.2) Lifetime ends (scope exit, delete) → destructor executes.3) Destructor closes files, frees memory, and performs other necessary cleanup.4) Program continues with no resource leaks tied to the object. Verification / Alternative check: Open a file in a class constructor and close it in the destructor. Observe that the file is reliably closed even if exceptions are thrown after construction. Why Other Options Are Wrong: Constructor: used at creation, not destruction.Assignment / copy/move constructors: manage copying or moving existing objects, not cleanup at end-of-life. Common Pitfalls: Leaving resource release to manual calls; prefer RAII with destructor-based cleanup for robustness. Final Answer: destructor

Question 13

Order of destruction in C++: destructor calls occur in what relation to the order of the corresponding constructor calls?

Accepted Answer

Introduction / Context: For robust cleanup, C++ guarantees a predictable destruction order that mirrors construction—reversed. Understanding this is critical when members or resources depend on each other. Given Data / Assumptions: An object aggregates subobjects (members, bases). Construction occurs in a fixed order; we seek the destruction order. Stack objects within a block are constructed in sequence and destroyed in reverse sequence. Concept / Approach: Within a single object, base classes are constructed first, then data members in declaration order; destruction happens in the exact reverse: members are destroyed in reverse declaration order, then bases. For multiple objects with automatic storage in a scope, the last constructed is the first destroyed (LIFO), aligning with stack behavior. Step-by-Step Solution: 1) Construct A then B → destruction runs B then A.2) For a class: Base then Member1 then Member2 → destruction order is Member2 then Member1 then Base.3) This reversal prevents use-after-destruction because dependents go away before their dependencies.4) Therefore, select “Reverse order”. Verification / Alternative check: Add logging to constructors and destructors of members and observe the reversed output during teardown. Why Other Options Are Wrong: Forward/depends/undefined: conflict with the language's deterministic lifetime rules for contained objects and stack variables. Common Pitfalls: Assuming initializer list order controls member construction; it does not—member declaration order does. Destruction still reverses declaration order. Final Answer: Reverse order

Question 14

By C++ definition, a “default constructor” is a constructor that accepts how many parameters?

Accepted Answer

Introduction / Context: Terminology around constructors can be confusing. The C++ standard defines a default constructor in a very specific way. This question checks whether you know that definition. Given Data / Assumptions: We are speaking about the standard term “default constructor”. We distinguish it from user-provided, trivial, or implicitly-declared constructors. Parameters with default values may still allow default construction. Concept / Approach: A default constructor is one that can be called with no arguments. Most simply, it has no parameters. A constructor with parameters all of which have default values also counts as a default constructor because it can be invoked with zero arguments. MCQs usually distill this to “no parameters”. Step-by-Step Solution: 1) struct T { T(); }; → default constructor with zero parameters.2) struct U { U(int x = 0); }; → still default-constructible because it can be called with no arguments.3) The essence is callability with zero arguments.4) Thus, choose “no”. Verification / Alternative check: Instantiate T t; and U u; to confirm that both forms allow default construction. Why Other Options Are Wrong: one/two/three: incorrect by the standard definition.“Any number if all have defaults”: while nuanced, the canonical MCQ answer emphasizes that a default constructor takes no arguments. Common Pitfalls: Confusing “default constructor” with “compiler-generated constructor”. A class may or may not get an implicitly declared default constructor depending on other user-declared constructors. Final Answer: no

Question 15

Which statement about C++ constructors is incorrect? Evaluate the claims about compiler-provided constructors and required access level.

Accepted Answer

Introduction / Context: Developers often rely on defaults, but C++ only supplies certain constructors when specific conditions are met. Access control on constructors is also flexible. This question identifies the incorrect statements among common myths. Given Data / Assumptions: Classes may define their own constructors. If no constructors are user-declared, the compiler may implicitly declare a default constructor. Constructors can have any access specifier: public, protected, or private. Concept / Approach: Statement A is true: a constructor is indeed a special member function. Statement B is false because the compiler does not “always” provide a zero-argument constructor; it does so only when none is user-declared and other rules allow it. Statement C is false because constructors may be private or protected (e.g., singletons, factory patterns, or abstract bases). Therefore, the combined incorrect choice is “Both B and C.” Step-by-Step Solution: 1) Verify A: constructors are members (though unnamed and special).2) Evaluate B: suppressed if any constructor is user-declared; also constrained by class content.3) Evaluate C: access may be restricted intentionally.4) Conclusion: B and C are the incorrect claims. Verification / Alternative check: Create a class with a user-declared constructor taking arguments only; observe that default construction is no longer available unless explicitly declared. Why Other Options Are Wrong: A is correct; E is false because B and C are indeed incorrect. Common Pitfalls: Assuming default construction exists after adding any non-default constructor; you must explicitly add a default constructor if needed. Final Answer: Both B and C.

Question 16

C++ constructors: what happens if a class defines only parameterized constructors (no zero-argument/default constructor), but the program attempts to create an object that requires a no-argument constructor?

Accepted Answer

Introduction / Context: In C++ object construction, the presence or absence of a default (zero-argument) constructor controls which forms of object creation are valid. If a class only supplies parameterized constructors and omits a default constructor, any attempt to create an instance without arguments tests your understanding of overload resolution and constructor availability at compile time. Given Data / Assumptions: The class explicitly defines one or more parameterized constructors. No user-declared default constructor is provided, and no implicitly generated one exists due to the user-declared constructors. The program tries to create an object with syntax that requires a zero-argument constructor (for example, T obj; or new T; or a container default-constructing T). Concept / Approach: When you declare any user-defined constructor, the compiler does not implicitly declare a default constructor unless its generation is still permitted by the rules. If none exists and code requires default construction, overload resolution fails during compilation. Because constructors are selected and validated at compile time, the failure is detected before the program can run, eliminating the possibility of a run-time error or exception here. Step-by-Step Solution: Identify that the object creation site provides no arguments. Check class interface: only parameterized constructors are available. Attempt overload resolution: no matching constructor taking zero parameters. Compilation fails with a diagnostic: “no matching constructor for initialization.” Verification / Alternative check: Provide a user-declared default constructor (T();) or give default values to all parameters of one constructor, making it usable without arguments. Recompile and observe that the error disappears, confirming the compile-time nature of the issue. Why Other Options Are Wrong: Preprocessing error: preprocessing does not consider constructors; it only handles directives and macros. Runtime error / Runtime exception: construction viability is determined before linking and execution, so the program never runs to hit a run-time failure for this cause. Common Pitfalls: Assuming the compiler will “synthesize” a default constructor even if parameterized ones exist. Confusing default initialization (T t;) with value-initialization (T t{};), both still require an accessible default constructor. Final Answer: Compile-time error.

Question 17

C++ special members: the function whose name is the class name prefixed with a tilde (~) is called what?

Accepted Answer

Introduction / Context: C++ provides special member functions that govern object lifetime. A function spelled with the class name prefixed by a tilde (~) is one of these special members and is responsible for cleanup when an object's lifetime ends. This question checks recognition of that naming convention and its role in RAII (Resource Acquisition Is Initialization). Given Data / Assumptions: Spelling: ~ClassName() No return type and no parameters are allowed. Invoked automatically at the end of an object's lifetime. Concept / Approach: The member named ~ClassName() is the destructor. It performs finalization such as releasing memory, closing file handles, unlocking mutexes, or logging. The constructor, by contrast, shares the class name without the tilde and initializes the object. Recognizing the destructor’s signature is foundational for writing exception-safe, leak-free code in C++. Step-by-Step Solution: Recall naming: constructor → ClassName(...); destructor → ~ClassName(). Recall semantics: constructor runs at creation; destructor runs at scope exit or delete. Match to options: “destructor.” Confirm: no return type; cannot be overloaded; can be virtual. Verification / Alternative check: Instrument ~ClassName() with a print; observe calls when objects go out of scope, when vectors shrink, or when delete p; is executed for dynamically allocated objects with virtual destructors where needed. Why Other Options Are Wrong: constructor: no tilde and runs at creation. function/object: too generic and do not identify the special cleanup role. Common Pitfalls: Forgetting to make base-class destructors virtual when deleting through base pointers. Assuming destructors can have parameters or return types—they cannot. Final Answer: destructor

Question 18

C++ unions: a union without any user-declared constructor can be initialized from another union of which type?

Accepted Answer

Introduction / Context: Unions in C++ overlay multiple members at the same memory location. Initialization and assignment rules depend on type compatibility and on whether user-declared constructors are present. This question targets the scenario where the union has no constructor and asks about the type constraints for initializing it from another union value. Given Data / Assumptions: No user-defined constructors exist in the union. Initialization is performed using another union as a source value. We focus on type compatibility in standard C++. Concept / Approach: If a union has no user-declared constructors, it behaves like an aggregate for many initialization purposes. Initialization from another union is only well-formed when the source has the same union type. Different types (even layout-compatible unions) are not considered the same type. Terms like “virtual” and “class” do not describe types that satisfy this requirement; they are unrelated concepts or too broad. Therefore, the safe and correct option is “same.” Step-by-Step Solution: Confirm that constructors are absent → aggregate-like behavior. Check type of source union → must be exactly the same union type. Attempt cross-type initialization → ill-formed. Conclude: initialization permitted only from the same union type. Verification / Alternative check: Try compiling code that initializes U1 u = u2; where U1 and U2 are distinct union types with identical members; compilation fails due to mismatched types. Using exactly the same union type compiles and behaves as expected. Why Other Options Are Wrong: different: violates type equivalence requirements. virtual: refers to virtual dispatch and is irrelevant for unions. class: overly generic and not a type equality statement. Common Pitfalls: Assuming layout or member similarity implies type compatibility—it does not. Overlooking that user-defined constructors change initialization rules entirely. Final Answer: same

Question 19

C++ copy constructor design: if the copy constructor takes its parameter by value, what happens?

Accepted Answer

Introduction / Context: The copy constructor is meant to copy an existing object into a new one. Its parameter type is critical. A common trap is to declare the copy constructor with a by-value parameter instead of a by-reference parameter. This question explores the consequence of that mistake. Given Data / Assumptions: Class defines a copy constructor that takes the source object by value (e.g., T(T other)). No special compiler extensions are assumed. Standard semantics for parameter passing and construction apply. Concept / Approach: Passing an object by value to a function requires copying it to create the parameter. If the function in question is the copy constructor itself, creating the parameter requires invoking… the copy constructor. That, in turn, requires copying the parameter again, and so on—leading to infinite recursion at compile time (conceptually), which manifests as the inability to form the parameter without another copy. Hence, the correct design is to take the source by reference, typically const T& (and optionally also define a move constructor in modern C++). Step-by-Step Solution: Define T(T other) → parameter passing demands a copy. To copy other, call the copy constructor T(T ...). But that again needs a copy → recursion with no base case. Compilation fails; the correct signature is T(const T&). Verification / Alternative check: Change the signature to T(const T&). Recompile and observe that the issue disappears. Optionally implement T(T&&) for move semantics. Tools like static analyzers flag the by-value copy constructor as erroneous. Why Other Options Are Wrong: One-argument or zero-argument constructors are irrelevant here. “Work without any problem” ignores the recursive dependency inherent in by-value parameters. Common Pitfalls: Confusing copy constructors with assignment operators; the latter take a reference too. Forgetting const on the reference, reducing usability with const objects. Final Answer: call itself recursively

Question 20

C++ copy constructor parameter: how must a copy constructor receive its argument for correct behavior?

Accepted Answer

Introduction / Context: A copy constructor’s purpose is to initialize a new object from an existing object of the same type. The parameter type determines whether the constructor is even callable without paradox. This question targets the correct, standard signature style for a copy constructor in C++. Given Data / Assumptions: We are discussing the canonical copy constructor signature. No vendor extensions; standard C++ rules apply. Best practice includes const correctness. Concept / Approach: The copy constructor must take its argument by reference, typically T(const T&). If it were by value, creating the parameter would itself require invoking the copy constructor, creating an infinite regress. Passing by address is not the language-defined copy constructor form and would not be considered a copy constructor by the compiler. Therefore, “only pass-by-reference” is correct, with the conventional form being a const lvalue reference (and a separate move constructor for rvalues in modern C++). Step-by-Step Solution: Recognize the signature the compiler treats specially: T(const T&). Reason about by-value parameter: would require another copy → impossible. Address parameter: not treated as a copy constructor by the language. Conclude: only pass-by-reference is valid for a real copy constructor. Verification / Alternative check: Compile with T(T) and observe failure or recursion. Replace with T(const T&) and the constructor behaves as expected in copy initialization and direct initialization contexts. Why Other Options Are Wrong: Either value or reference: includes an invalid case (by value). Only by value: impossible for the reasons above. Only by address: not recognized by the compiler as a copy constructor. Common Pitfalls: Omitting const, which prevents copying from const objects. Forgetting to also implement or default the move constructor/assignment when needed. Final Answer: only pass-by-reference

Constructors and Destructors Questions