Question 1

Which of the following statements about C++ type checking and static member functions are correct? Select the most accurate combination based on the C++ language rules.

Accepted Answer

Introduction: C++ performs compile-time type checking and also offers limited runtime type identification features. This question verifies understanding of static versus dynamic type checking and clarifies a common misconception about const qualification of static member functions. Given Data / Assumptions: Language: C++. Static type checking occurs at compile time. Dynamic checks exist via RTTI (typeid, dynamic_cast). Static member functions have no implicit this pointer. Concept / Approach: “Static type checking” means errors are caught at compile time by the type system. “Dynamic type checking” in C++ refers to features like dynamic_cast on polymorphic types and typeid, which consult runtime type information. A static member function cannot be declared const because const applies to the implicit object parameter (this), which static functions do not have. Step-by-Step Solution: 1) Assess statement A: true — the C++ compiler enforces static type rules at compile time.2) Assess statement B: true — RTTI enables certain runtime checks (e.g., dynamic_cast failures).3) Assess statement C: false — static members lack a this pointer; const has no meaning here.4) Therefore the correct combined choice is “Both A and B.” Verification / Alternative check: Code examples: dynamic_cast(basePtr) returns nullptr if the runtime type is not Derived, demonstrating runtime checking; compile-time mismatches (e.g., adding int to std::string) fail statically. Why Other Options Are Wrong: A only: ignores legitimate runtime checks via RTTI.B only: overlooks pervasive compile-time checking in C++.C: impossible by language rules; const qualifies the object state through this. Common Pitfalls: Confusing dynamic typing (as in Python) with C++’s RTTI; C++ remains statically typed even though it supports certain runtime checks. Final Answer: Both A and B.

Question 2

Which statements correctly describe C++ function overloading? Choose all that make two functions with the same name distinct overloads.

Accepted Answer

Introduction: Function overloading lets multiple functions share a name but differ in their parameter lists. This question checks whether you know which differences produce distinct overloads in C++. Given Data / Assumptions: Same function name across candidates. We compare parameter lists only (return type alone does not overload). Language: C++ overload resolution rules. Concept / Approach: Two overloads are distinct if their parameter types differ in number, types, or order. Changing only the return type does not create a new overload. Therefore, differences in argument types or their order both qualify as distinct overloads. Step-by-Step Solution: 1) Evaluate A: different parameter types → valid basis for overloading.2) Evaluate B: different order (e.g., f(int, double) vs f(double, int)) → valid, because the parameter lists are different.3) Evaluate C: “number is same” by itself does not ensure distinctness; they could still be identical. Overloading needs a parameter list difference.4) Hence, the correct choice is “Both A and B.” Verification / Alternative check: Try compiling void f(int,double); void f(double,int); — both coexist. But int f(int); double f(int); fails because return type alone does not overload. Why Other Options Are Wrong: A only: incomplete — order differences also qualify.B only: incomplete — type differences also qualify.C: irrelevant condition; sameness of number does not ensure distinct overloads. Common Pitfalls: Assuming that changing only the return type is sufficient. Also forgetting that default arguments can complicate overload resolution and cause ambiguity. Final Answer: Both A and B.

Question 3

Which OOP concept means deciding at runtime which method implementation to invoke for a call through a base interface? Identify the correct term used in C++ for this behavior.

Accepted Answer

Introduction: Object-oriented languages dispatch virtual calls using the most-derived override that applies at runtime. This question asks for the term that describes runtime decision-making for which method body to execute in C++. Given Data / Assumptions: Virtual functions are involved. Call is made through a base-class interface or pointer/reference. Language: C++. Concept / Approach: The correct term is dynamic binding (also called late binding). With dynamic binding, the program chooses the function implementation based on the runtime dynamic type of the object, not merely the static type of the expression. Step-by-Step Solution: 1) Declare a virtual function in the base class.2) Override it in derived classes.3) Call through a base pointer/reference; the runtime type determines which override runs.4) The dispatch commonly uses a vtable/vptr mechanism on typical implementations. Verification / Alternative check: Construct a small example with Base::foo virtual and Derived::foo override; observe that calling foo via Base* to a Derived object executes Derived::foo. Why Other Options Are Wrong: Data hiding: refers to encapsulating implementation details, not dispatch.Dynamic Typing: C++ is statically typed; RTTI is not dynamic typing.Dynamic loading: means loading code/modules at runtime, unrelated to method dispatch choice. Common Pitfalls: Confusing dynamic binding with templates (which are resolved at compile time) or assuming all member functions are dynamically bound without the virtual keyword. Final Answer: Dynamic binding

Question 4

Which programming approach is primarily associated with C++ and object-oriented design? Choose the best match for how systems are modeled and built.

Accepted Answer

Introduction: C++ supports multiple design approaches, but classic object-oriented design emphasizes composing larger systems from smaller, reusable components. This question checks recognition of that dominant perspective. Given Data / Assumptions: Language: C++ with OOP. Common OOP methodology contrasts with procedural decomposition. We seek the conventional association, not an exclusive rule. Concept / Approach: OOP often follows a bottom-up approach: define classes encapsulating state and behavior, compose them into subsystems, then assemble applications. While top-down analysis is also used, the idiomatic C++/OOP workflow encourages building from objects upward. Step-by-Step Solution: 1) Identify OOP building blocks: classes and objects.2) Create reusable components: containers, algorithms, services.3) Compose higher-level modules from these components.4) Integrate into full applications, leveraging encapsulation and inheritance. Verification / Alternative check: Standard libraries (e.g., STL) exemplify bottom-up reuse: generic containers and algorithms are composed to solve larger problems. Why Other Options Are Wrong: Top-down: more closely associated with procedural decomposition.Right-left / Left-right: not recognized software design paradigms. Common Pitfalls: Assuming OOP forbids top-down planning; in practice, teams blend both, but object modeling encourages bottom-up construction. Final Answer: Bottom-up

Question 5

How many major kinds of polymorphism does C++ support? Distinguish by when binding happens relative to compile time.

Accepted Answer

Introduction: Polymorphism means “many forms” — the ability for the same interface to exhibit different behaviors. In C++, polymorphism is broadly categorized by whether it is resolved at compile time or at runtime. Given Data / Assumptions: Language: C++. We consider standard categories, not niche taxonomies. Examples include function/operator overloading and virtual dispatch. Concept / Approach: C++ supports two principal kinds: compile-time (static) polymorphism and runtime (dynamic) polymorphism. Compile-time includes templates, function overloading, and operator overloading. Runtime uses virtual functions and dynamic dispatch via base-class interfaces. Step-by-Step Solution: 1) Identify compile-time mechanisms: templates, overload sets, inline substitution decided by the compiler.2) Identify runtime mechanisms: virtual functions resolved through vtables at execution time.3) Count distinct categories: 2.4) Map to the answer: “2”. Verification / Alternative check: Consult common C++ texts that divide polymorphism into static and dynamic; examples demonstrate decisions made either during compilation or at runtime. Why Other Options Are Wrong: 1: ignores one of the two major forms.3 or 4: overcounts by splitting subtypes beyond the commonly accepted categories. Common Pitfalls: Confusing inheritance with polymorphism; inheritance enables runtime polymorphism but is not itself a separate kind. Also, templates are compile-time, not runtime. Final Answer: 2

Question 6

In C++ access control, which members are intended to be accessible only within the class and its derived classes (i.e., within the class hierarchy chain)? Choose the best match for “available only in the hierarchy”.

Accepted Answer

Introduction: Access specifiers in C++ control visibility of class members. This question targets the meaning of protected and how it differs from public and private with respect to inheritance. Given Data / Assumptions: Three main access levels: public, protected, private. Focus: visibility across class boundaries and along inheritance chains. Typical, non-friend contexts assumed. Concept / Approach: Protected members are accessible within the class that declares them and within derived classes (subject to access rules and friendship). They are not accessible to unrelated external code. That matches the idea “available only in the class hierarchy chain.” Step-by-Step Solution: 1) Public: accessible everywhere — not restricted to the hierarchy.2) Private: accessible only within the declaring class — not even in derived classes.3) Protected: accessible in the declaring class and in derived classes — the hierarchy chain.4) Therefore, “Protected data members” is the correct choice. Verification / Alternative check: Attempting to access a protected member through an unrelated object from outside the hierarchy fails to compile, while a derived class method can access it. Why Other Options Are Wrong: Public data members: accessible everywhere, not limited to the hierarchy.Private data members: not accessible in derived classes (except via friends or accessors).Member functions: access depends on their specified level; “member functions” is too broad. Common Pitfalls: Assuming protected is similar to package-private from other languages. In C++, protected is strictly about class and derived-class access, not modules or namespaces. Final Answer: Protected data members

Question 7

In C++, which of the following cannot be declared with the keyword virtual? Select the entity for which virtual is not permitted.

Accepted Answer

Introduction: The virtual mechanism in C++ enables dynamic binding for functions invoked through base-class interfaces. This question pinpoints which constructs are compatible with virtual and which are not. Given Data / Assumptions: Language: C++. Typical usage: virtual on member functions for polymorphism. Special cases: constructors and destructors. Concept / Approach: Constructors cannot be virtual in C++ because dynamic dispatch requires an already constructed object with a valid vptr. During construction, the object’s dynamic type is not yet established for base subobjects. Destructors, on the other hand, are often virtual to ensure proper cleanup via base pointers. Member functions (non-static) can be virtual. The keyword “virtual” is not used to declare a class itself, although inheritance can be virtual in the derivation list (virtual base classes). Step-by-Step Solution: 1) Check constructors: cannot be virtual → candidate answer.2) Check destructors: can and often should be virtual in polymorphic bases.3) Check member functions: can be virtual (enables dynamic dispatch).4) “class” is not declared virtual; instead, base-class subobjects can be specified as virtual in inheritance syntax. Verification / Alternative check: Compilers reject “virtual ConstructorName(...);” but accept “virtual ~Base();” and “virtual void f();”. Why Other Options Are Wrong: member functions: valid target for virtual.destructor: valid and recommended in interfaces.class: “virtual class” is not a declaration form; however, the question asks what cannot use virtual — the definitive, universally correct answer is the constructor. Common Pitfalls: Confusing “virtual inheritance” (in the derivation list) with “virtual classes.” Remember: constructors never virtual. Final Answer: constructor

Question 8

Which C++ operator cannot be overloaded by user code? Identify the operator that is excluded from overloading rules.

Accepted Answer

Introduction: C++ permits overloading many operators to customize behavior for user-defined types. However, a fixed subset of operators is non-overloadable. Recognizing these exceptions is essential for API design. Given Data / Assumptions: Language: C++. We consider built-in operator overloading rules. Goal: identify a non-overloadable operator. Concept / Approach: Operators that cannot be overloaded include . (member access), ., ::, ?: (conditional), sizeof, typeid, alignof, and a few more context operators. In contrast, [], ->, and * are all overloadable (operator[], operator->, operator*). Step-by-Step Solution: 1) Review overloading rules: many unary/binary operators are overloadable.2) Identify exceptions list that includes the conditional operator.3) From the options, ?: is on the non-overloadable list.4) Conclude that ?: cannot be overloaded. Verification / Alternative check: Attempting to declare T operator ?:(...) is ill-formed. Meanwhile, operator[], operator->, and operator* are common in smart pointers, containers, and iterator types. Why Other Options Are Wrong: []: overloadable (e.g., std::vector::operator[]).->: overloadable (used by smart pointers to forward member access).*: overloadable (e.g., dereference for iterators or user types). Common Pitfalls: Confusing “possible but discouraged” with “impossible.” While some overloads are poor style, they are still legal; ?: is not. Final Answer: ?:

Question 9

In object-oriented C++, which feature primarily provides a code-reuse mechanism? Select the concept most directly associated with reusing existing implementations.

Accepted Answer

Introduction: Code reuse is a central goal of object-oriented programming. While several OOP principles contribute indirectly, one feature most directly enables reuse of implemented behavior across related types. Given Data / Assumptions: Language: C++. Typical OOP toolkit: abstraction, encapsulation, inheritance, and polymorphism (dynamic binding). Focus: direct mechanism for implementation reuse. Concept / Approach: Inheritance allows a derived class to reuse and extend the implementation of a base class, inheriting data and member functions. Although abstraction and encapsulation improve design clarity and safety, inheritance explicitly shares implemented behavior. Dynamic binding enables substitutability, not reuse per se. Step-by-Step Solution: 1) Identify reuse goal: avoid re-writing common behavior.2) Map OOP features to outcomes: encapsulation hides details; abstraction models concepts; dynamic binding chooses implementations at runtime.3) Recognize that inheritance copies base interface and implementation into the derived type’s interface/behavior.4) Therefore, inheritance is the direct reuse mechanism. Verification / Alternative check: Common frameworks provide abstract base classes with default implementations (e.g., adapter classes) that derived classes reuse and override selectively. Why Other Options Are Wrong: Abstraction: defines essential interfaces; does not itself reuse code.Dynamic binding: enables polymorphism, not implementation reuse.Encapsulation: controls access/visibility; does not replicate implementation across types. Common Pitfalls: Overusing inheritance where composition would be better. Prefer “composition over inheritance” when reuse does not require an is-a relationship. Final Answer: Inheritance

Question 10

In modern C++, which of the following are mechanisms of static (compile-time) polymorphism? Choose the option that best captures all techniques resolved before runtime.

Accepted Answer

Introduction: Polymorphism in C++ broadly divides into static (compile-time) and dynamic (runtime). This question checks whether you can recognize the common features that provide static polymorphism—i.e., behavior decided by the compiler rather than a runtime dispatcher. Given Data / Assumptions: Language: C++ (standards-compliant, no compiler extensions assumed). Focus: mechanisms whose resolution occurs during compilation. Contrast with dynamic polymorphism via virtual functions. Concept / Approach: Static polymorphism means the call or instantiation choice is determined at compile time from types and overload sets. Three pillars in C++ are: function overloading (choosing among functions with the same name but different parameter lists), operator overloading (syntactic sugar that compiles down to function calls chosen at compile time), and templates (generic code that the compiler instantiates into concrete functions/classes based on supplied types). None of these require a vtable at runtime to choose an implementation. Step-by-Step Solution: 1) Function overloading: the compiler selects the best match from the overload set using overload resolution rules.2) Operator overloading: operators map to functions (e.g., operator+); selection is determined at compile time similarly to ordinary overloads.3) Templates: the compiler generates code for specific types at instantiation time; calls are then resolved statically.4) Since all three are compile-time mechanisms, the comprehensive answer includes all. Verification / Alternative check: Inspect generated symbols (e.g., with objdump) to see template-instantiated functions and overloaded operators resolved to concrete functions without runtime dispatch tables. Why Other Options Are Wrong: Operator overloading: correct but incomplete alone.Function overloading: correct but incomplete alone.Templates: correct but incomplete alone. Common Pitfalls: Confusing templates with macros (templates are type-checked). Equating operator overloading with runtime dispatch (it is resolved at compile time unless combined with virtuals inside bodies). Final Answer: All of the above

Question 11

In C++, how do you make a class abstract (i.e., uninstantiable and intended as an interface/base)? Select the standard language feature used to enforce abstractness.

Accepted Answer

Introduction: Abstract classes model shared interfaces/behaviors that derived classes must implement. This question asks which exact C++ mechanism enforces that a class cannot be directly instantiated. Given Data / Assumptions: You want a base class that cannot be constructed. Language: C++ with virtual dispatch semantics. Need a canonical, standard-compliant technique. Concept / Approach: A class becomes abstract if it declares (and does not override with a definition) at least one pure virtual function, written with ”= 0“. This communicates that derived classes must supply an override before they become concrete. Merely having virtual functions is not sufficient; they can still have definitions and the class remains instantiable if no pure virtuals exist. Step-by-Step Solution: 1) Identify a function that must be implemented by derived types (e.g., draw()).2) Declare it pure virtual in the base: virtual void draw() = 0;3) Because at least one pure virtual exists, the base class becomes abstract.4) Any concrete derived class must implement draw() to be instantiable. Verification / Alternative check: Attempting ”Base b;“ where Base has a pure virtual function triggers a compile-time error stating that the type is abstract. Why Other Options Are Wrong: static: unrelated to abstractness; affects storage/linkage.virtual keyword alone: enables dynamic dispatch but does not force abstractness.“virtual function” (non-pure): class can still be instantiated. Common Pitfalls: Forgetting to provide a virtual destructor in abstract bases used polymorphically. Declaring a pure virtual destructor still requires a definition. Final Answer: Making at least one member function as pure virtual function.

Question 12

Which concept refers to adding new program components while the application is running (rather than at compile/link time)? Pick the term commonly used in C/C++ systems.

Accepted Answer

Introduction: Large systems sometimes need to extend functionality on the fly—for example, by loading plug-ins without stopping the process. This question targets the term for bringing code into a running process image. Given Data / Assumptions: Runtime extensibility is desired. Context: C/C++ or OS-level facilities (e.g., dlopen/LoadLibrary). We are not changing types or dispatch rules, only adding modules. Concept / Approach: Dynamic loading means loading code/data from external modules during execution. On POSIX systems, dlopen/dlsym handle shared objects; on Windows, LoadLibrary/GetProcAddress manage DLLs. This is distinct from dynamic typing (type systems) or dynamic binding (virtual function dispatch); it is about module loading and symbol resolution at runtime. Step-by-Step Solution: 1) Compile plug-ins as shared libraries.2) At runtime, call the platform loader API to bring the module into memory.3) Resolve function pointers with dlsym/GetProcAddress.4) Invoke newly loaded functionality without restarting the application. Verification / Alternative check: Unload and reload modules to confirm swapping behavior; check symbol tables to verify late binding of addresses to function pointers. Why Other Options Are Wrong: Data hiding: encapsulation concern, not module loading.Dynamic typing: property of languages like Python, not C++.Dynamic binding: runtime choice among virtual overrides, not loading code. Common Pitfalls: Forgetting ABI stability and versioning. Not handling loader errors or symbol name mangling (extern "C" helps for C++ exports). Final Answer: Dynamic loading

Question 13

In C++, what is the term for a function that is defined inside a class definition? Choose the standard name used in OOP and C++.

Accepted Answer

Introduction: C++ classes bundle state and behavior. The behavior is implemented through functions associated with the class. This question asks for the conventional term for those functions. Given Data / Assumptions: A function appears in the class body. It may be declared and defined inside the class, or declared inside and defined outside with ClassName:: scope. We use standard OOP terminology. Concept / Approach: Functions that belong to a class are called member functions (a.k.a. methods). They operate on class instances, may access this, and may be const/non-const, static or virtual, etc. “Member variable” refers to data, not behavior; “class function” is informal and ambiguous; “classic function” is unrelated. Step-by-Step Solution: 1) Identify that the function is part of a class.2) Recognize the established term: member function.3) Note that placement of the definition (inside vs outside) does not change the term.4) Conclude the correct choice is “Member function”. Verification / Alternative check: Any C++ text or reference uses “member function” and “data member” consistently to distinguish behavior from state. Why Other Options Are Wrong: Member Variable: that is state (data), not behavior.Class function: non-standard term; may confuse with static functions.Classic function: unrelated phrase. Common Pitfalls: Assuming static member functions are not “member functions”—they are still members, but lack a this pointer. Final Answer: Member function

Question 14

In C++, how is late binding (deciding the override at runtime) implemented under the hood? Identify the common mechanism used by compilers.

Accepted Answer

Introduction: Virtual functions enable runtime polymorphism: the program chooses which overridden function to run based on the dynamic type of the object. This question asks for the typical implementation device used by mainstream C++ compilers. Given Data / Assumptions: Polymorphic classes declare at least one virtual function. We discuss common ABI strategies (Itanium, MSVC) rather than strict standard mandates. Concept / Approach: Most compilers implement late binding via a vtable (virtual table) per polymorphic type and a vptr inside each object, pointing to the class’s vtable. A virtual call compiles to an indirect call through the vtable entry corresponding to the function’s slot. Step-by-Step Solution: 1) When a class has virtual functions, the compiler emits a vtable listing function pointers.2) Each object stores a hidden vptr initialized by constructors to point at the class’s vtable.3) A call like p->foo() becomes: load vptr, index to foo’s slot, perform indirect call.4) Overrides in derived classes replace entries in the derived class’s vtable. Verification / Alternative check: Disassembling a polymorphic call shows an indirect jump through a table. ABI docs describe slot layouts and RTTI pointers colocated with the vtable. Why Other Options Are Wrong: “C++ tables”, “Indexed virtual tables”, “polymorphic tables”: vague or non-standard terms; the accepted term is “virtual table (vtable)”. Common Pitfalls: Believing the standard mandates vtables—it does not, but they are the de facto implementation. Also, thinking templates require vtables (they do not). Final Answer: Using Virtual tables

Question 15

Which C++ concept lets one class contain and manage objects of another class as part of its own state? Select the composition-style reuse mechanism.

Accepted Answer

Introduction: There are several ways to reuse code in C++. This question focuses on the pattern where one class holds other objects as members and delegates behavior to them—an approach often summarized as “has-a”. Given Data / Assumptions: You want to build larger types by combining smaller, well-defined components. Goal: favor loose coupling and testability. We contrast with inheritance (“is-a”). Concept / Approach: Composition means a class contains objects of other classes as data members and uses them to implement behavior. It is the backbone of “composition over inheritance”: prefer assembling behavior from parts rather than extending a base class when an is-a relationship does not truly exist. Step-by-Step Solution: 1) Identify responsibilities that can be delegated to collaborators (e.g., Logger, Repository).2) Add collaborators as members and initialize them via constructors or setters.3) Forward calls to these members to achieve the desired behavior.4) Enjoy improved substitution and unit testing by mocking or swapping components. Verification / Alternative check: Refactor an inheritance-heavy design to composition and observe reduced coupling and fewer fragile base class problems. Why Other Options Are Wrong: Encapsulation: hiding internal details; orthogonal to how you assemble types.Abstraction: modeling essential behavior; not specifically a containment mechanism.Inheritance: reuses base implementation but creates tight is-a relationships. Common Pitfalls: Overusing inheritance for code reuse, leading to rigid hierarchies. Composition typically provides better flexibility and testability. Final Answer: Composition

Question 16

In C++, what are the primary roles of a constructor? Choose the option that best reflects what constructors actually do.

Accepted Answer

Introduction: Constructors run automatically when an object's lifetime begins, preparing its invariants and resources. This question distinguishes between allocation/creation and initialization responsibilities in C++. Given Data / Assumptions: Objects can be automatic (stack), dynamic (via new), or static storage. Construction is distinct from allocation of raw memory. We focus on what the constructor function body guarantees. Concept / Approach: Constructors initialize objects: they set up member values, establish invariants, and acquire resources. The act of “making an object exist” is performed by storage allocation (e.g., stack frame, operator new). The constructor then runs to initialize that storage with a valid state. A constructor does not “construct a class” or “construct a function”. Step-by-Step Solution: 1) Memory is reserved for the object (by context or operator new).2) The constructor executes, initializing members (via member initializer list/body).3) The object becomes usable with class invariants established.4) On destruction, the destructor releases resources and unwinds that initialization. Verification / Alternative check: Overload operator new to observe allocation separate from construction; placement new also demonstrates that constructors initialize pre-allocated memory. Why Other Options Are Wrong: Construct a new class: classes are compile-time types; not constructed at runtime.Construct a new object: allocation plus initialization creates objects; the constructor specifically performs initialization.Construct a new function: nonsensical in C++. Common Pitfalls: Placing heavy logic in constructors that can throw, complicating exception safety. Prefer noexcept where practical and RAII for resource management. Final Answer: Initialize objects

Question 17

What can a friend function access in a C++ class? Identify the correct scope of access granted by friendship.

Accepted Answer

Introduction: Friendship in C++ is a targeted access control escape hatch. This question checks whether you know the breadth of access a friend function receives once declared by a class. Given Data / Assumptions: A class explicitly declares a function (or class) as friend. We discuss access rights, not ownership or lifetime. Friendship is not inherited or transitive unless redeclared. Concept / Approach: A friend function has full access to the class’s private, protected, and public members. Friendship grants access privileges equivalent to those of member functions for the purpose of reading/modifying members, but the friend is still not a member of the class. Step-by-Step Solution: 1) Inside the class, add ”friend ReturnType f(…);”.2) The named function f can now read/write private and protected members.3) No other unrelated functions gain access unless also declared as friends.4) Derived classes do not automatically become friends. Verification / Alternative check: Try compiling code where a friend function writes a private field; it compiles, while a non-friend/non-member attempt fails. Why Other Options Are Wrong: Public only: too restrictive—friendship includes private/protected.Protected only / Private only: incomplete; friendship includes all. Common Pitfalls: Overusing friendship harms encapsulation. Prefer narrow interfaces; use friends sparingly for operator overloads or factory helpers that need intimate access. Final Answer: All of the above.

Question 18

Why is reusability considered a desirable feature in a programming language and ecosystem? Select the most defensible advantages commonly achieved by reuse.

Accepted Answer

Introduction: Software reuse—via libraries, frameworks, and shared components—promises faster delivery and higher quality. This question asks which benefits are genuinely attributable to reusability in practice. Given Data / Assumptions: Reusable components are well-tested and documented. Teams integrate rather than re-implement core building blocks. We compare development lifecycle stages: testing, maintenance, and build times. Concept / Approach: Reusing proven components reduces duplicated code and the surface area for new defects. Consequently, teams spend less time writing and testing custom implementations. Maintenance costs drop because common functionality lives in a central, versioned artifact rather than scattered bespoke code. Compilation time, however, depends on toolchains and project layout; reuse does not inherently reduce compilation time and may even increase it for template-heavy libraries. Step-by-Step Solution: 1) Testing effort declines because reused modules arrive pre-validated; only integration and boundary tests are needed.2) Maintenance cost falls as bug fixes and updates occur once in the shared module and propagate to dependents.3) Build times vary; reuse does not guarantee faster compilation.4) Therefore, benefits A and B are the reliable outcomes of reuse. Verification / Alternative check: Empirical project metrics often show defect density decreases when switching from homegrown utilities to vetted libraries; maintenance tickets for duplicated logic also drop. Why Other Options Are Wrong: Compilation time: not a direct or consistent effect of reuse.A or B alone: each is true, but the best answer captures both. Common Pitfalls: Overgeneralizing reuse to inappropriate domains (premature abstraction). Also, neglecting versioning and dependency management can negate the benefits. Final Answer: Both A and B.

Question 19

In which contexts are virtual calls effectively resolved at compile time (i.e., dynamic dispatch is suppressed) in C++? Choose the standard situations where a virtual call does not dispatch to a more derived override at runtime.

Accepted Answer

Introduction: Virtual functions normally dispatch based on the object's dynamic type. However, C++ intentionally disables dynamic dispatch in specific phases of an object's lifetime. This question asks you to identify those well-defined exceptions. Given Data / Assumptions: We have a polymorphic base class with virtual functions and a derived class overriding them. Calls originate from base-class constructors/destructors. Standard object model semantics apply (vptr initialization order). Concept / Approach: During construction and destruction, the dynamic type is treated as the class whose constructor or destructor is currently running. The most-derived subobject is not yet fully formed (in a constructor) or is being torn down (in a destructor). Therefore, a virtual call behaves as if it were non-virtual, targeting the function of the current class—this is often described as “devirtualized by the language rules,” not merely by optimization. Step-by-Step Solution: 1) In Base::Base(), a call to a virtual f() resolves to Base::f(), even if Derived overrides f().2) In Base::~Base(), a call to f() also resolves to Base::f() for safety; derived resources may already be destroyed.3) Outside these phases (e.g., in main or any ordinary context), virtual dispatch works normally through the vtable.4) Hence the correct combined choice is “Both A and B”. Verification / Alternative check: Compile a demo printing which override runs from constructors/destructors; observe base version prints despite a Derived instance. Why Other Options Are Wrong: main(): ordinary context; virtual dispatch operates as usual when calling through base pointers/references.A only / B only: incomplete; both phases suppress dispatch. Common Pitfalls: Relying on virtual calls in constructors/destructors for initialization/cleanup in derived classes; prefer calling non-virtual helpers or using factory/setup methods. Final Answer: Both A and B.

Question 20

In C++ object-oriented programming, which concept refers to waiting until runtime to decide which actual function implementation will be called through a base interface? Choose the best term that names this runtime decision process.

Accepted Answer

Introduction: Late selection of the actual function implementation is a cornerstone of runtime polymorphism in C++. This question asks you to identify the precise term for deciding which overridden method to execute when a call is made through a base-class reference or pointer. Given Data / Assumptions: Language: C++ with classes and inheritance. Calls are made through a base pointer/reference. Virtual functions are used to enable runtime selection. Concept / Approach: The term is dynamic binding (also called late binding). When a function is declared virtual in a base class and overridden in derived classes, the call p->f() is resolved using the object's dynamic type at runtime. Typical implementations use a vtable (virtual table) and a hidden vptr inside each polymorphic object to indirect to the correct function body. Step-by-Step Solution: 1) Declare a virtual function in Base: virtual void draw();2) Override it in Derived: void draw() override;3) Form a base pointer to a derived object: Base* p = new Derived();4) Invoke p->draw(); at runtime, the program selects Derived::draw via dynamic binding. Verification / Alternative check: Print from Base::draw and Derived::draw. When called through a Base* that actually points to a Derived, the Derived version prints, confirming dynamic binding. Why Other Options Are Wrong: Data hiding: about encapsulation and access control, not dispatch.Dynamic casting: RTTI-based casts (dynamic_cast), not dispatch selection.Dynamic loading: loading modules at runtime (e.g., dlopen), unrelated to virtual calls. Common Pitfalls: Assuming all member functions are dynamically bound; in C++, only virtual functions dispatch dynamically. Also, within constructors/destructors, virtual calls do not dispatch to more-derived overrides. Final Answer: Dynamic binding

OOPS Concepts Questions