Question 1

In C++, which of the following are legal ways to access a data member x from inside a member function using the this pointer? Assume x is a non-static data member of the current class.

Accepted Answer

Introduction:The keyword this is a pointer to the current object inside non-static member functions. This question checks knowledge of pointer syntax versus direct-member access syntax when referencing a field named x through this.Given Data / Assumptions:Inside a non-static member function.this has type T for class T.x is a valid non-static data member of T.Concept / Approach:Because this is a pointer, the correct operator to access a member is the arrow operator: this->x. The dot operator requires an object (not a pointer). Parentheses are required if you explicitly dereference this and then use dot: (*this).x is valid, but the option given as *this.x is parsed incorrectly as *(this.x) and is invalid.Step-by-Step Solution:1) Recognize that this is a pointer to the current object.2) Use pointer-to-member access: this->x.3) Alternative (not listed): (*this).x also works because *this yields an lvalue object.4) Any form missing parentheses or misusing dot/arrow is ill-formed.Verification / Alternative check:Compile a snippet with both this->x and (*this).x; both compile. Try this.x or *this.x and observe compilation errors due to incorrect parsing.Why Other Options Are Wrong:this.x: dot requires an object, not a pointer.*this.x: parsed as *(this.x), accessing a member x of pointer this (nonsense).*this-x: arithmetic on pointers mixing dereference and subtraction; unrelated and invalid for member access.Common Pitfalls:Forgetting parentheses around *this when using dot, leading to precedence errors. Prefer this->x for clarity.Final Answer:this->x

Question 2

Consider the statements about operator overloading in C++: I) All operators can be overloaded. II) We can change the basic meaning of an operator. Which option correctly evaluates these statements?

Accepted Answer

Introduction:Operator overloading lets user-defined types interoperate with familiar syntax, but it is constrained by C++ language rules. This question evaluates two common myths about how far operator overloading can go.Given Data / Assumptions:We are discussing C++ operator overloading rules.“Basic meaning” refers to fundamental properties such as arity, precedence, and evaluation order.Concept / Approach:Not all operators are overloadable. For example, ::, . (member access), .*, ?:, sizeof, typeid, alignof, and a few others cannot be overloaded. Moreover, overloading does not allow changing the basic meaning: you cannot alter precedence, associativity, or the number of operands; you only provide user-defined behavior for existing syntax on user-defined types.Step-by-Step Solution:1) Examine I: “All operators can be overloaded.” This is false due to the explicit non-overloadable set.2) Examine II: “We can change the basic meaning of an operator.” Also false—overloading cannot change precedence/arity or the core parsing behavior.3) Therefore, the correct evaluation is that both statements are false.4) Proper use: provide intuitive semantics consistent with the operator's conventional meaning.Verification / Alternative check:Try to declare an overload for ?: or :: and observe a compilation error; compare with legal overloads like operator+, operator[], or operator->.Why Other Options Are Wrong:Only I true / Only II true / Both true: each contradicts specific, well-documented language restrictions.Common Pitfalls:Abusing operator overloading to create surprising behavior; even when legal, keep semantics consistent with user expectations to preserve readability.Final Answer:Both I and II are false.

Question 3

For the standard output stream object cout (std::cout), which operator is overloaded to support formatted output? Select the operator commonly chained in printing expressions.

Accepted Answer

Introduction:C++ iostreams rely on operator overloading to present a clean, chainable syntax for input and output. This question asks which operator is overloaded for the output stream std::cout to send data to the console.Given Data / Assumptions:We are using iostreams (std::cout).Formatted output is achieved via operator chaining.Insertion/extraction operators are part of the iostream design.Concept / Approach:The insertion operator >.Step-by-Step Solution:1) Identify output direction: “insert into stream” uses 2) Note that std::cout is a std::ostream object.3) The expression std::cout 4) The overloaded functions return std::ostream& to enable chaining.Verification / Alternative check:Header defines the relevant operatorWhy Other Options Are Wrong:>>: extraction for input streams (std::cin).+: unrelated to stream output semantics.=: assignment operator; not used for printing.Common Pitfalls:Forgetting to make custom operatorFinal Answer:

Question 4

Which statement correctly captures the relationship between classes and objects in C++? Choose the standard definition used in OOP.

Accepted Answer

Introduction:Object-oriented programming distinguishes between type definitions and the concrete entities created at runtime. This question checks the fundamental terminology connecting classes and objects.Given Data / Assumptions:A class defines structure (data members) and behavior (member functions).Objects are created during program execution.Language: C++.Concept / Approach:A class is a user-defined type—a blueprint. An object is a particular instance of that type that occupies memory and participates in computation. Many objects can be created from one class, each with its own state, while sharing behavior defined by the class.Step-by-Step Solution:1) Define a class: struct Point { int x; int y; };2) Create objects: Point p1; Point p2;3) Observe that p1 and p2 are instances of Point with separate storage.4) Conclude: an object is an instance of its class.Verification / Alternative check:sizeof(Point) gives the size of the type; allocating Point p; reserves memory for an instance, showing the distinction between definition (class) and instance (object).Why Other Options Are Wrong:Class as an instance of object or data type: reverses the relationship; classes are types.Object as an instance of data type (generic): incomplete; in OOP we specifically say “instance of a class.”Common Pitfalls:Confusing class (type) with object (value). Remember: classes are compile-time constructs; objects exist at runtime.Final Answer:Object is an instance of a class.

Question 5

Which kind of class pattern allows only one object of the class to be created throughout the program's lifetime? Identify the design that enforces single-instance control.

Accepted Answer

Introduction:Sometimes an application needs exactly one global access point to a resource—logging, configuration, or a device manager. This question targets the standard design pattern that enforces a single instance for a class.Given Data / Assumptions:We need at most one instance.Global, controlled access is desired.Language: C++.Concept / Approach:The Singleton pattern ensures only one object exists by controlling construction and providing a global accessor. Typical elements include a private constructor, a deleted copy/move, and a static function that returns a reference to the unique instance, often implemented as a function-local static for thread-safe initialization.Step-by-Step Solution:1) Make constructors private or protected.2) Delete copy/move operations to prevent cloning.3) Provide static T& instance() { static T obj; return obj; }4) Access via T::instance() and never via direct construction.Verification / Alternative check:Attempts to create additional instances should fail to compile or link; all users obtain the same object reference from the accessor.Why Other Options Are Wrong:Virtual class: C++ has virtual inheritance, not “virtual classes.”Abstract class: prevents instantiation altogether unless derived and completed.Friend class: an access control tool, not a single-instance mechanism.Common Pitfalls:Overusing singletons creates hidden dependencies and hinders testing. Prefer dependency injection; use a singleton only when global uniqueness is genuinely required.Final Answer:Singleton class

Question 6

Which C++ feature allows the compiler to insert missing arguments at the call site using specified defaults? Identify the mechanism that fills in omitted parameters automatically.

Accepted Answer

Introduction:APIs often offer convenient defaults so callers can omit less common parameters. This question asks for the C++ feature that enables such convenience directly in function declarations.Given Data / Assumptions:A function parameter list may include defaults.Omitted trailing arguments are supplied by the compiler.Language: C++.Concept / Approach:Default arguments are specified in the function declaration: void log(std::string msg, int level = 1). When the caller does not provide level, the compiler inserts 1 at the call site during overload resolution. Defaults must be trailing and are bound at the point of declaration that is visible to the call site.Step-by-Step Solution:1) Declare defaults in a header or visible declaration.2) Ensure defaults apply to trailing parameters.3) Callers may pass fewer arguments; the compiler fills the rest.4) Implementation should not repeat defaults in multiple declarations to avoid ODR/sync issues.Verification / Alternative check:Compile an example where a call omits the final argument and confirm successful binding with the intended value.Why Other Options Are Wrong:Call by value/reference/pointer: parameter passing mechanisms, not argument-supply features.Common Pitfalls:Placing defaults in both declaration and definition causes redefinition errors. Also avoid ambiguous overloads interacting poorly with defaults.Final Answer:Default arguments

Question 7

In C++, which of the following is not a member of a class by definition? Identify the construct that has access but is not itself a class member.

Accepted Answer

Introduction:Classes can contain many kinds of members: data, functions (including static, const-qualified, and virtual). C++ also has the notion of friends that can access private parts without being members. This question tests your understanding of that distinction.Given Data / Assumptions:We compare membership status versus access rights.We consider typical method qualifiers (static, const, virtual).Friendship is explicitly declared by the class.Concept / Approach:A friend function is not a class member. It remains a free function (or a function of another class) but is granted access to private and protected members of the declaring class. By contrast, a static member function is a true member without a this pointer; a const member function is a member whose implicit object parameter is const; a virtual function is a member participating in dynamic dispatch.Step-by-Step Solution:1) Identify which candidates are intrinsically members (static, const-qualified, virtual).2) Recall that friend affects access, not membership.3) Conclude that “Friend function” is not a member.4) Therefore, select option B.Verification / Alternative check:Use ADL and fully qualified names to note that friend functions are defined at namespace scope (unless they are also declared as members separately).Why Other Options Are Wrong:Static function: declared inside the class; it is a member.Const function: still a member; const qualifies the implicit object parameter.Virtual function: always a non-static member participating in virtual dispatch.Common Pitfalls:Assuming a friend “belongs” to the class. It does not; it only gains access privileges.Final Answer:Friend function

Question 8

Which of the following best represents an abstract data type (ADT) in C++? Choose the option that encapsulates data and behavior behind an interface.

Accepted Answer

Introduction:An abstract data type is defined by its interface and observable behavior rather than its implementation details. This question asks which choice best captures that idea within C++ terminology.Given Data / Assumptions:An ADT exposes operations while hiding representation.We distinguish primitive types from user-defined abstractions.Language: C++.Concept / Approach:A class is the canonical vehicle for ADTs in C++. It packages data and functions, controls access via public/protected/private, and allows clients to depend on a stable interface while the implementation can change. Primitive types like int and double are concrete machine-level types, not ADTs. The identifier string typically refers to std::string, which is a class implementing an ADT, but the general answer that represents the concept itself is “Class.”Step-by-Step Solution:1) Identify ADT properties: interface-first, hidden representation.2) Map these to C++ constructs: classes provide exactly this encapsulation.3) Recognize primitives as non-ADT concrete types.4) Select “Class” as the best conceptual match.Verification / Alternative check:Consider a Stack class: push/pop/top define behavior; internal container choice (vector/list) can change without affecting users—hallmark of an ADT.Why Other Options Are Wrong:int / double: primitive numeric types, not interface-defined abstractions.string: specific library class; while it is an ADT instance, the general concept is better represented by “Class”.Common Pitfalls:Equating ADT solely with inheritance; ADTs can exist without inheritance so long as the interface abstracts representation.Final Answer:Class

Question 9

In type theory terms, what kind of polymorphism does function overloading in C++ exemplify? Pick the standard category used to describe overloading.

Accepted Answer

Introduction:Polymorphism comes in several flavors, and C++ supports more than one. This question asks you to classify function overloading using the conventional terminology from type theory and programming languages.Given Data / Assumptions:Multiple functions share the same name.They differ by parameter types or arity.Binding occurs at compile time via overload resolution.Concept / Approach:Function overloading is a form of ad-hoc polymorphism. The compiler chooses among distinct implementations based on the static types of the arguments. This differs from parametric polymorphism (templates/generics) and from subtype (runtime) polymorphism (virtual functions). In C++, overloading and operator overloading are resolved at compile time without a vtable lookup.Step-by-Step Solution:1) Present an overload set, e.g., f(int) and f(double).2) Call f with different argument types; the compiler selects the best match.3) Note that each overload is a separate function body (ad-hoc).4) Conclude the classification: ad-hoc polymorphism.Verification / Alternative check:Inspect the generated symbols; you will see distinct mangled names for each overload, confirming there are separate implementations.Why Other Options Are Wrong:Virtual polymorphism: refers to runtime (subtype) polymorphism via virtual dispatch.Transient / Pseudo polymorphism: non-standard or informal terms not used to classify overloading.Common Pitfalls:Confusing templates (parametric) with overloading (ad-hoc). Templates generate implementations from a single pattern; overloading selects among multiple concrete functions.Final Answer:Ad-hoc polymorphism

Question 10

C++ OOP: which is the correct syntax to declare a pure virtual function? Choose the exact declaration form used in an abstract base class.

Accepted Answer

Introduction / Context:In C++, a pure virtual function is a function in a base class that has no implementation in that class and must be overridden in derived classes. Declaring a pure virtual function makes the class abstract, meaning you cannot instantiate it directly. This question tests your ability to recognize the precise syntax that the C++ language uses to mark a virtual member function as pure (abstract). Given Data / Assumptions: Target declaration name: Display. Return type: void. Parameter list: (void) — i.e., no parameters. Goal: mark the function as pure virtual in an abstract base class. Concept / Approach: The correct form for a pure virtual member function is: return_type function_signature = 0; combined with the virtual keyword in the class definition. The “= 0” portion is not an assignment; it is grammatically special and tells the compiler that the function has no definition in the current class and must be overridden (unless the derived class is also abstract). You may still provide an out-of-class definition for a pure virtual function in rare cases, but the class remains abstract until all pure virtuals are overridden in a concrete derived class. Step-by-Step Solution: 1) Start with a normal virtual declaration: virtual void Display(void); 2) Add the pure specifier: = 0; directly after the closing parenthesis. 3) Final form inside the class: virtual void Display(void) = 0; 4) Result: The class becomes abstract and cannot be instantiated. Verification / Alternative check: Attempting to instantiate a class containing at least one pure virtual function results in a compile-time error. A derived class that overrides Display with an exact-matching signature becomes instantiable provided no other pure virtuals remain unimplemented. Why Other Options Are Wrong: virtual void Display(void){0}; — A function body with “{0}” is not the pure-virtual syntax; it attempts a definition. virtual void Display = 0; — Missing the parameter list; not a valid member function declaration. void Display(void) = 0; — Missing virtual; the pure marker applies to virtual functions only. Common Pitfalls: Confusing pure virtual with “unimplemented” non-virtual; only virtual members can be pure. Forgetting that a destructor can also be pure virtual (often to enforce abstractness) but still should have a definition. Final Answer: virtual void Display(void) = 0;

Question 11

Object-oriented basics in C++: which concept refers to wrapping data and functions together into a single unit?

Accepted Answer

Introduction / Context:In object-oriented programming (OOP), class design bundles state (data) with behavior (member functions). Understanding the names and roles of core OOP principles helps you reason about program structure, maintainability, and security. This question asks which term specifically denotes the wrapping of data and functions together in one cohesive unit. Given Data / Assumptions: The language context is C++. We compare common OOP principles: abstraction, encapsulation, inheritance, and polymorphism. We emphasize how a class exposes behavior and hides implementation details. Concept / Approach: Encapsulation is the OOP principle that binds data and the methods that operate on that data into a single unit (typically a class), while controlling access via access specifiers (private, protected, public). Encapsulation enables information hiding: clients interact through a stable public interface while internal representation remains private, enabling safer refactoring and preserving invariants. Although related, abstraction is about exposing essential features while hiding complexity; inheritance enables reuse across hierarchies; polymorphism enables substitutability via virtual dispatch and overloading. Step-by-Step Solution: 1) Identify the phrase “wrapping data and functions together.” 2) Map it to the OOP concept that couples state and behavior with access control ⇒ encapsulation. 3) Confirm via access specifiers: private members hide representation; public members expose behavior. 4) Conclude that the term is encapsulation. Verification / Alternative check: Consider a class with private fields and public getters/setters or behavior methods. Users of the class cannot directly manipulate internals, confirming encapsulation. Abstraction may also be present, but the “wrapping together” wording points chiefly to encapsulation. Why Other Options Are Wrong: Abstraction: emphasizes essential interface, not bundling per se. Inheritance: reuses and extends behavior across classes. Polymorphism: allows the same interface to represent different concrete types. Common Pitfalls: Equating encapsulation with “getters and setters” only; true encapsulation also enforces invariants via methods. Assuming public fields maintain encapsulation; exposing raw state breaks information hiding. Final Answer: Encapsulation

Question 12

C++ constructors: which of the following is NOT a constructor type?

Accepted Answer

Introduction / Context:Constructors initialize objects and establish class invariants. C++ recognizes several common constructor categories by usage rather than special keywords. This question checks whether you can distinguish real constructor types from invalid notions in standard C++ terminology. Given Data / Assumptions: We consider standard C++ (not vendor extensions). Constructor names match the class name and have no return type. Friendship grants access; it is not a kind of constructor. Concept / Approach: Recognized categories include: default constructor (no parameters), parameterized constructor (with parameters), and copy constructor (takes const Class& under typical form). There is no such thing as a “friend constructor.” The friend keyword grants another function or class access to private/protected members; it does not turn a constructor into a different “type.” Constructors themselves can be friends of another class, but that does not create a new constructor category. Step-by-Step Solution: 1) List standard categories: default, parameterized, copy (and move in modern C++). 2) Evaluate “friend constructor”: not a standard category—friendship is an access relationship. 3) Conclude that “Friend constructor” is not a constructor type. 4) Therefore, it is the correct choice for “not a type.” Verification / Alternative check: Reviewing language references shows friend applies to functions/classes for access control. A constructor may be declared friend of another class, but its own classification remains default/parameterized/copy/move. Why Other Options Are Wrong: Copy constructor: initializes from another object of the same type. Default constructor: callable with no arguments. Parameterized constructor: accepts arguments to customize initialization. Common Pitfalls: Confusing friend with constructor categories. Forgetting move constructors (C++11+)—not listed here but standard. Final Answer: Friend constructor

Question 13

C++ classes: what is the default access specifier for members inside a class definition?

Accepted Answer

Introduction / Context:Access control is fundamental to encapsulation. In C++, the default accessibility of members differs between class and struct. Understanding the default helps you avoid unintended exposure of implementation details and enforces safer APIs by default. Given Data / Assumptions: Context: members declared within a class block. No explicit access specifier precedes the member declarations. We are not discussing inheritance access here, only member access level. Concept / Approach: Inside a class, the default access for members is private. Inside a struct, the default is public. This asymmetry is deliberate: class encourages encapsulation by hiding internals unless explicitly exposed, while struct is often used for simple aggregates where public data is acceptable. You can always override defaults by writing explicit public:, protected:, or private: labels. Step-by-Step Solution: 1) Consider a class with no access labels: members are private by default. 2) Contrast with a struct: members are public by default. 3) Therefore, the correct answer is “private.” 4) Use explicit labels to avoid ambiguity in team codebases. Verification / Alternative check: Try accessing a member from outside the class without an explicit public: section; the compiler emits an access error, confirming the default is private for classes. Why Other Options Are Wrong: public/protected: not the default in classes. friend: not an access level for members; it is a relationship granting access to another function/class. Common Pitfalls: Assuming class and struct share the same default; they do not. Overusing public data, which weakens encapsulation. Final Answer: private

Question 14

C++ object lifecycle: when is a constructor invoked for a class object?

Accepted Answer

Introduction / Context:Constructors initialize objects to a valid state. Knowing precisely when they run helps you reason about resource acquisition and initialization order, which is critical for RAII patterns in C++ (Resource Acquisition Is Initialization). Given Data / Assumptions: We discuss automatic (stack), static, and dynamic objects (via new). “Declaration of an object” is taken to mean its definition/creation. We ignore forward declarations without definitions. Concept / Approach: Constructors are invoked when an object is created: for automatic objects, upon entering their scope at the definition; for static-duration objects, before main (or on first use for function-local statics with initialization guards); for dynamic objects, immediately when new allocates and constructs. Mere use of an already-constructed object does not call the constructor again. Defining a class type itself does not trigger constructors; only creating instances does. Step-by-Step Solution: 1) auto T x; ⇒ constructor runs at the point of definition. 2) static T g; ⇒ constructor runs before first use per initialization rules for static storage. 3) T* p = new T(...); ⇒ constructor runs after allocation. 4) Using x later does not call the constructor again; the destructor will run at end-of-life. Verification / Alternative check: Instrument a constructor with logging and observe when messages print: at creation, not at arbitrary “use” points nor at type declaration time. Why Other Options Are Wrong: “time of use of an object”: use does not trigger construction. “time of declaration/use of a class”: classes are types; only objects have constructors called. Common Pitfalls: Confusing declaration with forward declaration; only definitions create objects. Assuming copy elision rules always call or skip constructors—modern C++ may elide but construction still conceptually occurs. Final Answer: A constructor is called at the time of declaration of an object.

Question 15

C++ iostreams: what exactly is cout in standard C++?

Accepted Answer

Introduction / Context:cout is ubiquitous in C++ programs for console output. Understanding what it actually is clarifies why insertion with works and how manipulators (like std::endl) integrate with the streaming model in the standard library. Given Data / Assumptions: Namespace std is presumed (either via qualification or using-declaration). We are using modern headers (), not old *.h forms. Operators are overloaded for stream insertion. Concept / Approach: std::cout is a global object of type std::ostream (or an implementation-defined type derived from it) representing the standard output stream. The stream insertion operator operator<< is overloaded for many types, enabling expressions like std::cout << 42. Manipulators such as std::hex and std::endl are functions or objects that work with this stream object through overloads. It is not a function or macro itself; it is an instance through which output operations are performed. Step-by-Step Solution: 1) Identify cout in : declared as an external stream object. 2) Recognize expression form: std::cout << value; uses overloaded operators on the object. 3) Conclude: cout is an object, not a function, operator, or macro. 4) Understand that buffering and formatting are properties of the stream object. Verification / Alternative check: Intellisense/IDE hover shows cout’s type as std::ostream. Taking its address &std::cout is valid (object), while calling std::cout() is ill-formed (not a function). Why Other Options Are Wrong: operator: << is the operator; cout is its left operand (an object). function: you do not call cout; you stream into it. macro: cout is not defined by the preprocessor. Common Pitfalls: Assuming cout is tied to the console only; it represents standard output, which can be redirected. Forgetting to flush buffers when necessary (e.g., using std::endl or std::flush). Final Answer: object

Question 16

C++ headers: which header provides the declarations for both cin and cout (per classic options listed)?

Accepted Answer

Introduction / Context:Modern C++ uses header names without the .h suffix, such as . However, many legacy multiple-choice questions still cite pre-standard headers. Among the given choices, one classic header historically declared both cin and cout together. Given Data / Assumptions: We accept the question’s legacy-style options. cin and cout are standard input/output stream objects. We focus on the header that includes both in one unit. Concept / Approach: Historically, the header (pre-Standard C++) declared stream classes and the global objects cin, cout, cerr, and clog. Modern C++ replaces it with in namespace std. Separate headers like and were compiler-specific and are not part of the current standard. Given the provided choices, the correct legacy answer is iostream.h. Step-by-Step Solution: 1) Identify which option historically brings in both input and output streams. 2) Choose iostream.h, the combined header. 3) Note that modern code should prefer #include and std::cout/std::cin. 4) Remember that manipulators like are separate in both eras. Verification / Alternative check: Compiling legacy examples against old compilers required . On conforming modern compilers, is absent; use instead (but that is not among the options here). Why Other Options Are Wrong: istream.h and ostream.h: non-standard, often partial; not both together. iomanip.h: for formatting manipulators, not for defining cin/cout. Common Pitfalls: Memorizing legacy headers without understanding that modern code uses (no .h) and namespace std. Final Answer: iostream.h

Question 17

Late binding in C++: which feature enables runtime selection of the method implementation?

Accepted Answer

Introduction / Context:Late binding (dynamic binding) means the function to call is determined at runtime based on the object’s dynamic type. In C++, this is the cornerstone of runtime polymorphism and is essential for designing flexible interfaces that derived classes can override. Given Data / Assumptions: We consider class hierarchies with base pointers/references. We differentiate between compile-time and runtime dispatch. We focus on the mechanisms built into C++. Concept / Approach: A virtual function in a base class allows derived classes to provide their own implementations. When you invoke the function through a base reference or pointer, the call is dispatched via the vtable to the most-derived override at runtime. Non-virtual member functions bind at compile time. “Operator function” is just a function implementing an operator overload and usually binds statically; “const function” only constrains mutation of the object; “static function” has no this and cannot be virtual, so it does not participate in dynamic binding. Step-by-Step Solution: 1) Mark a base member as virtual. 2) Override it in derived classes with the same signature. 3) Call through a base pointer/reference. 4) Observe runtime selection of the derived override. Verification / Alternative check: Removing the virtual keyword changes dispatch to static, making the base implementation run even when the dynamic type is derived (for non-overridden names, hiding rules aside). Why Other Options Are Wrong: Operator function: operator overloading is resolved at compile time. Const function: affects mutability, not dispatch. Static function: no virtual mechanism; it cannot be overridden polymorphically. Common Pitfalls: Expecting late binding without virtual. Confusing templates (static polymorphism) with virtual functions (dynamic polymorphism). Final Answer: Virtual function

Question 18

Name hiding vs overriding: if base and derived define a function with the same prototype, which function is called?

Accepted Answer

Introduction / Context:When both base and derived classes declare a function with the same signature, the behavior depends on whether the base function is virtual and on the static type of the expression used to call it. Understanding this clarifies how overriding and name hiding interact in typical class hierarchies. Given Data / Assumptions: Base and derived both define a function with the same prototype. No additional qualifiers are mentioned; assume standard visibility and access. We consider calls through actual objects of base or derived types. Concept / Approach: If the function is not virtual, the selection is based on the static type of the expression: a base object calls the base version; a derived object calls the derived version (overload resolution picks the member within the respective class; there is no runtime redirection). If the base declares the function virtual and the call is made through a base reference or pointer to a derived object, dynamic binding will select the derived override at runtime. In either case, a base object never calls the derived version, because it lacks the derived subobject and has its own layout and vtable (if any). Step-by-Step Solution: 1) Consider a Base b; and Derived d; where Derived : Base and both define f(). 2) Call b.f(); ⇒ invokes Base::f(). 3) Call d.f(); ⇒ invokes Derived::f(). 4) For pointers/references, if virtual, Base* p = &d; p->f(); dispatches to Derived::f(). Verification / Alternative check: Compile and run a sample with and without the virtual keyword to see the difference between static and dynamic binding. Inspecting assembly or debugger views shows vtable-based indirection in the virtual case only. Why Other Options Are Wrong: Error: redefining a member in a derived class is legal; it hides or overrides depending on virtual. “Only base” or “only derived” irrespective of object: both contradict standard dispatch rules. Common Pitfalls: Expecting derived to run when calling a non-virtual function through a base object. Confusing object calls with pointer/reference calls where dynamic binding applies. Final Answer: Base class object will call base class function and derived class object will call derived class function.

Question 19

C++ inline functions: which statements are correct about their impact?

Accepted Answer

Introduction / Context:Inlining replaces a function call with the function’s body at the call site (subject to compiler heuristics). This can remove call overhead and enable further optimizations such as constant propagation and dead code elimination. However, duplicating the body across call sites can increase code size, affecting instruction cache behavior. Given Data / Assumptions: Inline is a request to the optimizer; compilers may ignore it. Small, frequently called functions are the best candidates. We consider typical desktop and embedded targets with caches. Concept / Approach: Inlining often speeds up execution by eliminating call/return overhead and enabling interprocedural optimizations. At the same time, it usually increases code size because the function’s body is replicated at each call site. Whether performance improves depends on many factors: code size growth can actually hurt instruction cache locality, especially on tight embedded systems, leading to neutral or even negative performance changes. Therefore, the commonly accepted trade-off is “can be faster” and “often larger.” Step-by-Step Solution: 1) Consider the cost removed: function prologue/epilogue and call/return sequence. 2) Consider the cost added: duplicated instructions at each call site. 3) Weigh optimizer wins (constant folding, branch pruning) against I-cache pressure. 4) Conclude that A and C together reflect reality best. Verification / Alternative check: Benchmark two builds: one with forced inlining of a hot, tiny function and one without. You will often see modest speedups and measurable code growth; for large functions, growth can dominate and even hurt speed due to cache misses. Why Other Options Are Wrong: “Slows down execution” is not generally true; it may happen in some cases but is not the defining characteristic. Choosing only A or only C ignores the dual effect intrinsic to inlining. Common Pitfalls: Forcing inline on large functions indiscriminately. Confusing the inline keyword’s ODR/linkage meaning with “always inline.” Modern compilers decide independently. Final Answer: Both A and C.

Question 20

In object-oriented programming with C++, which concept best matches the statement: “The compiler checks the type of the reference used for a call rather than the actual object’s type.” Select the most appropriate concept name.

Accepted Answer

Introduction:Many learners get confused between compile-time resolution (based on the static type of a reference) and runtime resolution (based on the dynamic type of the object). This question asks you to connect that behavior to the correct high-level object-oriented programming concept in C++.Given Data / Assumptions:A call is made through a reference or pointer.The compiler can use the static type (reference type) for some resolutions.With virtual functions, the language can defer the final choice to runtime based on the object's dynamic type.Concept / Approach:Polymorphism is the umbrella concept that covers both compile-time and runtime selection of behavior depending on types. In C++, overloading and templates are compile-time (the compiler checks the reference/parameter types), whereas overriding of virtual functions is runtime (the program checks the object’s dynamic type and uses late binding).Step-by-Step Solution:1) If a function call is not virtual (e.g., overloading), the compiler resolves it using the static type of the expression (the reference type).2) If the call is to a virtual function through a base reference/pointer, the runtime decides which override to invoke based on the dynamic object type.3) Both behaviors fall under polymorphism: ad-hoc (compile time) and subtype (runtime).4) Among the given options, the broad, correct concept name is “Polymorphism”.Verification / Alternative check:Create Base and Derived with a virtual function, call through Base& to a Derived object, and observe the Derived override executes. For an overloaded non-virtual function set, the compiler’s selection depends on the reference’s static type.Why Other Options Are Wrong:Inheritance: a relationship enabling reuse/subtyping, not the selection mechanism itself.Abstraction: exposing essential features while hiding details—unrelated to call dispatch.Encapsulation: bundling data/operations with access control—also unrelated to dispatch rules.Common Pitfalls:Assuming every member function call is dynamically bound. In C++, only virtual functions use runtime dispatch; others are resolved using the reference type at compile time.Final Answer:Polymorphism

OOPS Concepts Questions

Questions

Practice smarter