Constructor and Destructor Behavior Quiz Quiz

Explore the essential behaviors of constructors and destructors with this focused quiz. Assess your understanding of key object-oriented principles, such as initialization, destruction, overloading rules, memory management, and order of invocation.

1. Default Constructor Initialization

   What happens if no constructors are explicitly defined in a class named Example?

   1. A default constructor is automatically provided by the compiler.
   2. A parameterized constructor is added by default.
   3. The class cannot be instantiated at all.
   4. A destructor is automatically provided but not a constructor.

   Explanation: If no constructors are defined, most object-oriented languages automatically provide a default constructor that takes no arguments. This allows the class to be instantiated with default values. The class is not rendered uninstantiable, so the second option is incorrect. While destructors may also be compiler-generated, the question concerns constructors, making the third option less appropriate. No parameterized constructor is generated by default, eliminating the last distractor.

2. Destructor Invocation Timing

   When is a class destructor called for a local object inside a function?

   1. Immediately after the object is created
   2. When the constructor is called
   3. Only when the program ends
   4. When the object goes out of scope at the end of the function

   Explanation: For local objects, the destructor is called automatically as soon as the object goes out of scope, typically at the end of the function. Destructors are not called immediately after construction, so option one is incorrect. Only global and static objects have destructors called at program end, rejecting option three. Destructors are invoked at object destruction, not construction, so the last distractor is inaccurate.

3. Constructor Overloading

   Given a class with multiple constructors, how does the program decide which constructor to use when an object is created?

   1. All constructors are called in sequence.
   2. The default constructor is always called regardless of arguments.
   3. It chooses constructors randomly.
   4. It selects the constructor based on the arguments provided during instantiation.

   Explanation: The appropriate constructor is chosen depending on the number and type of arguments passed when the object is created. Constructors are not all called; only one is selected per instantiation. The default constructor is only called with no arguments, so the third option is incorrect. Constructors are never chosen randomly, ruling out the fourth distractor.

4. Order of Destructor Calls with Inheritance

   In a class hierarchy where class Derived inherits from class Base, what is the correct order of destructor calls when a Derived object goes out of scope?

   1. Derived destructor is called before Base destructor
   2. Base destructor is called before Derived destructor
   3. Only the Base destructor is called
   4. Destructors are called in random order

   Explanation: In inheritance, the destructor of the most derived class is called first, followed by the base class destructor. The base destructor is not called first, making the first distractor incorrect. Random ordering never occurs, and excluding the Derived destructor would miss important resource cleanup, so the last option is also incorrect.

5. Constructor and Dynamic Memory Allocation

   If a class’s constructor allocates memory dynamically but the destructor does not release it, what issue can occur?

   1. Infinite constructor loop
   2. Memory leak
   3. Compiler warning with no runtime effect
   4. Segmentation fault during construction

   Explanation: Failing to release dynamically allocated memory in the destructor leads to memory leaks, where used memory is never reclaimed. Segmentation faults typically occur with invalid memory access, not just allocation or missing deallocation. Constructors cannot result in an infinite loop by themselves unless poorly coded, and while compilers may warn, the real problem is at runtime, not just at compile time.