Question 1

In standard C++ iostreams, what is the dynamic type (class) of the object std::cout? Choose the correct library type name.

Accepted Answer

Introduction:C++ iostreams define several stream classes for input and output. Recognizing which class std::cout belongs to is a foundational library fact that affects which operators and manipulators you can use.Given Data / Assumptions:We use the standard header .std::cout is the global output stream tied to the C standard output.We want the class (type) that std::cout is an instance of.Concept / Approach:The output stream type in the iostream hierarchy is std::ostream. std::cout is a global object of type std::ostream (technically std::ostream& bound to a buffered streambuf). The companion input stream is std::cin (std::istream). std::iostream is a bidirectional stream type, and std::ifstream is file input, neither of which is the type of std::cout.Step-by-Step Solution:1) Identify std::cout as the standard output stream.2) Match “output stream” to class std::ostream in the library taxonomy.3) Rule out input-only and file-only types (std::istream, std::ifstream).4) Conclude the correct choice is std::ostream.Verification / Alternative check:Inspect the declaration in the standard library headers or documentation; you will find extern std::ostream cout; in namespace std (the exact signature can vary slightly by vendor).Why Other Options Are Wrong:iostream: a bidirectional stream type; std::cout is not of this type.istream: used for input like std::cin.ifstream: file input stream for reading from files, not console output.Common Pitfalls:Confusing std::iostream (type) with (header). The header defines multiple classes including std::istream and std::ostream.Final Answer:ostream

Question 2

Consider the statements about when function calls are resolved: I) In procedure-oriented programming, all function calls are resolved at compile time. II) In object-oriented programming (OOP), all function calls are resolved at compile time. Which o…

Accepted Answer

Introduction:Different paradigms (procedural vs. object-oriented) influence how and when a call to a function is bound to its actual implementation. This question checks your understanding of compile-time (early) versus runtime (late) binding across these styles.Given Data / Assumptions:Procedural languages like C do not have virtual dispatch for ordinary functions.OOP languages like C++ support virtual functions that can dispatch at runtime.“All calls” means without exceptions.Concept / Approach:In procedural programs, the target of a function call is generally determined at compile/link time. In OOP, while many calls are also resolved at compile time, virtual functions are deliberately dispatched at runtime based on the object’s dynamic type. Therefore, saying “all” calls in OOP are compile-time is incorrect.Step-by-Step Solution:1) Evaluate I: true in the typical sense—procedural calls are early-bound.2) Evaluate II: false—virtual member functions in OOP are late-bound (dynamic binding).3) Since only I holds universally, choose “Only I is correct.”4) Note that in OOP non-virtual calls and inline/templated calls still resolve at compile time; “all” is the failing word.Verification / Alternative check:Write a base/derived example with a virtual function; the actual function selected depends on the runtime type, confirming late binding exists in OOP.Why Other Options Are Wrong:Only II / Both correct / Both incorrect: each contradicts the existence of virtual dispatch in OOP and the general early binding in procedural code.Common Pitfalls:Equating OOP with always-late binding. In C++, only virtual functions called via a base interface dispatch at runtime; others are still early-bound.Final Answer:Only I is correct.

Question 3

In C++, which statement about classes and structures is correct? Assume standard C++ (not C) access defaults and capabilities.

Accepted Answer

Introduction:C and C++ use the words “struct” and “class” differently. In modern C++, both can contain functions and data, but their default access differs. This question verifies that you know the precise, standard defaults and capabilities for C++ classes versus structures.Given Data / Assumptions:Language: C++ (not C).We consider member access defaults and whether member functions are allowed.We consider whether pointers to these types are allowed.Concept / Approach:In C++, class and struct are almost identical except for default access. In a class, members are private by default; in a struct, members are public by default. Both can have member functions and both support pointers and references. Hence, the only correct statement among the options is the one describing these default access rules.Step-by-Step Solution:1) Rule out A: structures can absolutely have member functions in C++.2) Rule out B: it reverses the defaults.3) Rule out C: pointers to classes/structs are valid and common.4) Select D: it correctly states the defaults—class: private, struct: public.Verification / Alternative check:Write minimal examples showing that omitting access specifiers in class makes members inaccessible (private), while in struct they are accessible (public) by default.Why Other Options Are Wrong:A: incorrect in C++—structs can have methods.B: flips the defaults.C: pointers are allowed to any object type.Common Pitfalls:Confusing C behavior (structs have no member functions) with C++ behavior, where structs are full-fledged classes with different defaults.Final Answer:class data members are private by default while that of structure are public by default.

Question 4

In object-oriented design, which concept best matches “exposing only the necessary information to the client and hiding the rest”? Pick the most appropriate OOP term.

Accepted Answer

Introduction:Good APIs reveal just enough to use a component while keeping internal complexity hidden. This question checks whether you can identify the OOP concept that emphasizes presenting essential features and omitting unnecessary details from a user’s perspective.Given Data / Assumptions:Client consumes a type via its public interface.Internal representation and helper functions remain hidden.Terms like encapsulation, data hiding, and abstraction are related but distinct.Concept / Approach:Abstraction focuses on modeling only the relevant aspects and exposing a clean interface, independent of implementation. Encapsulation is about bundling data and behavior with access control; data hiding is the access-control manifestation that prevents outsiders from touching internals. Abstraction is the closest match to “exposing only what’s necessary”.Step-by-Step Solution:1) Identify the goal: minimize surface area and reveal essential operations.2) Map to OOP terms: this is abstraction at the API boundary.3) Use encapsulation and data hiding to support the abstraction (private members, friend minimization).4) Result: clients program to an abstract interface, not concrete details.Verification / Alternative check:Compare a well-designed class with a leaky one. The former exposes methods like push/pop/top for a stack while hiding its internal container choice, demonstrating abstraction.Why Other Options Are Wrong:Encapsulation: supporting mechanism; broader than “expose only what’s necessary.”Data hiding: narrower focus on access control rather than conceptual modeling.Data binding: unrelated term in OOP contexts here.Common Pitfalls:Using abstraction and encapsulation interchangeably; abstraction is about the interface level, while encapsulation is about packaging and access control.Final Answer:Abstraction

Question 5

Which of the following statements about C++ classes and structures is correct? Consider access control defaults and member capabilities.

Accepted Answer

Introduction:C++ extends the C struct by allowing it to behave like a class. This question checks whether you know that both classes and structures in C++ can contain functions and what their access defaults are.Given Data / Assumptions:Language: C++ (not C).We compare what members are permitted and their default access.Protected access is available in classes.Concept / Approach:In C++, a struct is essentially a class with a different default access level. Both can have data members and member functions, both support private/protected/public sections, and both can be used with inheritance. Therefore, the true statement is that structures can have functions as members.Step-by-Step Solution:1) Examine A: false—classes can have protected data members.2) Examine B: true—structs can declare member functions in C++.3) Examine C: false—class members are private by default.4) Examine D: false—struct members are public by default.Verification / Alternative check:Write a simple struct with a member function and verify it compiles and works like a class method.Why Other Options Are Wrong:A: contradicts the language; protected is a core access specifier.C and D: both reverse the standard C++ defaults.Common Pitfalls:Confusing C and C++: in C, structs cannot have functions as members; in C++, they can. Also, forgetting the different defaults leads to access errors.Final Answer:Structures can have functions as members.

Question 6

Which of the following is NOT a recognized form of inheritance in C++ class hierarchies? Select the option that does not name a standard inheritance pattern.

Accepted Answer

Introduction:Inheritance patterns describe how classes derive from one another. Knowing the standard names helps you quickly understand class diagrams and codebases. This question asks you to identify the odd one out—something that is not a standard inheritance pattern name in C++.Given Data / Assumptions:Common patterns include single, multiple, multilevel, and hierarchical inheritance.We consider terminology from typical C++ texts.Concept / Approach:Multiple inheritance allows a class to derive from more than one base. Multilevel inheritance involves a chain (A → B → C). Hierarchical inheritance means one base with many derived classes. “Distributive” is not a standard term in C++ inheritance taxonomy.Step-by-Step Solution:1) Recognize the three standard names among the choices.2) Compare each to known definitions in OOP literature.3) Identify that “Distributive” does not refer to any C++ inheritance form.4) Select “Distributive”.Verification / Alternative check:Survey standard references; you will not find “distributive inheritance” as a defined pattern in mainstream C++ texts.Why Other Options Are Wrong:Multiple: valid and supported.Multilevel: valid; involves grandparent-parent-child chains.Hierarchical: valid; one base, several derived types.Common Pitfalls:Confusing hierarchical with hybrid (a combination of multiple and multilevel). The term “hybrid inheritance” is also seen, but “distributive” is not.Final Answer:Distributive

Question 7

Which is the correct way to declare a constant (const-qualified) member function in C++? Assume the intention is to prevent modification of the object's state.

Accepted Answer

Introduction:A const member function promises not to modify the observable state of the object. This question checks whether you can place the const in the correct syntactic position for a member function declaration.Given Data / Assumptions:We are declaring a non-static member function.We want the implicit object parameter (this) to be treated as pointer-to-const.Return type is an int in the example.Concept / Approach:The const that makes a member function a “const member function” appears after the parameter list: int ShowData() const. Writing const before the return type (const int) only makes the return value const-qualified; it does not make the member function itself a const member function.Step-by-Step Solution:1) Identify we need to qualify the implicit object parameter, not the return.2) Place const after the function signature: int ShowData() const.3) Inside such a function, only other const members can be called unless explicitly cast, and data members cannot be modified (except those marked mutable).4) Therefore option C is correct.Verification / Alternative check:Attempt to modify a data member inside a const member function and observe a compile error. Repeat in a non-const function and it compiles.Why Other Options Are Wrong:A and B: qualify the return type (const int), not the member function's object parameter.D: cannot be correct because A and B do not declare a const member function.Common Pitfalls:Placing const in the wrong location and believing it affects mutability of the object. Remember: for member functions, const follows the parameter list.Final Answer:int ShowData(void) const { / statements */ }

Question 8

How many instances (objects) of an abstract class can be directly created in C++? Choose the correct count.

Accepted Answer

Introduction:Abstract classes define interfaces with one or more pure virtual functions. They are intended only as base types. This question checks whether you recall the fundamental restriction on constructing abstract types in C++.Given Data / Assumptions:A class has at least one pure virtual function (written with = 0).No concrete override is provided in that class.We are asking about direct instantiation of that abstract class.Concept / Approach:By definition, abstract classes cannot be instantiated. Only concrete classes (those without unimplemented pure virtuals) can have objects created. Abstract bases are used through pointers/references to enable runtime polymorphism and interface-based design.Step-by-Step Solution:1) Declare a base with a pure virtual function.2) Attempt to write Base b; and observe a compile-time error citing abstract type.3) Derive a class that implements all pure virtuals; instantiate the derived type instead.4) Use a Base* pointing to Derived objects for polymorphic behavior.Verification / Alternative check:Compilers explicitly diagnose attempts to instantiate abstract classes. This is testable with a minimal program.Why Other Options Are Wrong:1, 5, 13: any positive number is impossible; the correct count is zero.Common Pitfalls:Forgetting that a pure virtual destructor still needs a definition; also believing that abstract classes cannot have constructors—constructors of abstract bases do run during derived construction.Final Answer:0

Question 9

In C++ programming, which of the following entities cannot be declared as a friend of a class? Identify the item that cannot gain friend-level access.

Accepted Answer

Introduction:Friendship is a targeted access-control mechanism that allows external code to access a class's non-public members. This question asks which kinds of entities can be granted friendship and which cannot.Given Data / Assumptions:A class can declare friends within its body.We consider functions (including operator functions) and other classes.We distinguish types/functions from individual runtime objects.Concept / Approach:In C++, you can declare as friend: specific non-member functions, all member functions of another class by befriending that class, and operator overload functions (which are just functions). Friendship is granted to functions or types, not to individual objects/instances. Therefore, an “object” cannot be declared a friend.Step-by-Step Solution:1) Consider friend void helper(MyClass&); → legal: function is a friend.2) Consider friend class Logger; → legal: all members of Logger have access.3) Consider friend std::ostream& operator4) Attempt “friend someObject;” → ill-formed; objects cannot be befriended.Verification / Alternative check:Try compiling a friend declaration with a specific object variable; compilers reject it because friend expects a type or a function declaration.Why Other Options Are Wrong:Function: valid friend target.Class: valid; grants access to all its members.Operator function: valid because operators are functions.Common Pitfalls:Confusing granting friendship to a single member function versus an entire class; remember that friend declarations are not transitive or inherited—each friendship must be explicitly declared.Final Answer:Object

Question 10

C++ exceptions and errors: which kind of problem actually causes an exception at runtime? Choose the most accurate scenario among compile-time vs run-time issues.

Accepted Answer

Introduction / Context:In C++ programming, it is vital to distinguish between compile-time errors (like syntax mistakes) and run-time errors (like division by zero, out-of-range access, or failed resource acquisition). Exceptions are a language mechanism intended to signal and handle exceptional conditions that usually occur at execution time, not during compilation. This question asks which problem class typically triggers an exception. Given Data / Assumptions: We are working in standard C++ with exception handling using try, throw, and catch. Compilation must succeed before any exception can occur. Examples of run-time faults include bad allocations, logic errors detected by libraries, and invalid operations. Concept / Approach: Exceptions are raised while the program is running. A compile-time error such as a missing semicolon is caught by the compiler and prevents the program from running at all. Syntax errors are therefore not associated with exceptions. Library and user code can throw exceptions to report problems that emerge only with real data and state at run time. These can be handled by catch blocks to recover or terminate gracefully. Step-by-Step Solution: Identify categories: syntax errors (compile-time) vs run-time errors (execution-time). Recognize that exceptions use throw/catch and therefore require the program to be executing. Conclude that only run-time problems are eligible to cause exceptions. Thus, select “A run-time error.” Verification / Alternative check: Try compiling code with a missing semicolon: compilation fails, and the binary is not produced. By contrast, code that throws (e.g., throw std::runtime_error("x");) compiles successfully and triggers an exception only when executed within a try block or propagates to terminate if unhandled. Why Other Options Are Wrong: Missing semicolon in main(): a classic syntax error detected at compile time. A syntax error: all syntax errors are compile-time issues and do not involve exceptions. A problem in calling function: too vague; it could be anything. Only if it occurs at run time and throws would it be relevant. Common Pitfalls: Believing exceptions are a compiler feature; they are a run-time control-flow mechanism. Confusing static analysis warnings with exceptions. Final Answer: A run-time error.

Question 11

C++ inheritance syntax: which of the following is an invalid visibility label in a base-class list?

Accepted Answer

Introduction / Context:When declaring inheritance in C++ (class Derived : access Base {}), you choose an access specifier that controls how the base’s public and protected members are treated in the derived class’s interface. Knowing which keywords are legal in the base-specifier list is fundamental C++ syntax knowledge. Given Data / Assumptions: We are selecting among: public, private, protected, friend. The context is the base-specifier list after a colon in a class definition. No virtual inheritance keyword is shown, but that is separate. Concept / Approach: Valid access specifiers in an inheritance list are exactly public, protected, and private. They adjust the accessibility of inherited members in the derived class. The keyword friend grants access privileges to another function or class and is not an access specifier for inheritance. Therefore it cannot appear as a visibility label in the base-specifier list. Step-by-Step Solution: Recall valid labels: public/protected/private. Note that friend is unrelated to inheritance access. Therefore, friend is invalid in this position. Choose “friend”. Verification / Alternative check: Try compiling class D : friend B {}; — compilers emit a syntax error. Replacing friend with public or protected compiles successfully (assuming B is declared). Why Other Options Are Wrong: public/private/protected are explicitly supported by the language for inheritance. Common Pitfalls: Confusing friend (access grant) with inheritance visibility. Assuming friend affects transitive visibility; it does not. Final Answer: friend

Question 12

C++ inheritance identification: what inheritance type does the following class use? class A : public X, public Y {}

Accepted Answer

Introduction / Context:Recognizing the form of inheritance from the class header is a quick way to interpret C++ code. Here we see a derived class listing more than one base class separated by commas, which maps to a specific inheritance pattern known in object-oriented design and C++ syntax. Given Data / Assumptions: Code: class A : public X, public Y {}; Both bases X and Y are listed after a colon and separated by a comma. No further details (virtual inheritance, etc.) are shown, but not needed. Concept / Approach: When a class inherits from more than one direct base at the same level, this is called multiple inheritance. Multilevel inheritance describes a chain (A derives from B, B derives from C). Hierarchical inheritance is one base with many derived classes. Hybrid inheritance mixes several patterns together (for example, multiple plus multilevel). The given declaration clearly shows two bases for A, so it is multiple inheritance. Step-by-Step Solution: Identify comma-separated bases: X and Y. Observe both are direct bases of A, not a chain. Match to the definition of multiple inheritance. Select “Multiple inheritance”. Verification / Alternative check: Replace the comma-separated list with a chain (class B : public A {}; class C : public B {};). That would be multilevel, unlike the given example. Therefore the classification here is unambiguously multiple. Why Other Options Are Wrong: Multilevel: requires a vertical chain, not siblings. Hybrid: needs a mixture of models; not evident here. Hierarchical: one base, many derived; opposite direction. Common Pitfalls: Confusing “two bases” (multiple) with “two levels” (multilevel). Final Answer: Multiple inheritance

Question 13

C++ operator overloading: which keyword is used in a function signature to overload an operator?

Accepted Answer

Introduction / Context:Operator overloading lets user-defined types work naturally with syntax like +, [], and Given Data / Assumptions: You are familiar with member and non-member overloads. We consider only standard C++ keywords. Examples: T operator+(const T&, const T&); T::operator[](size_t); Concept / Approach: The reserved word used to declare an operator overload is operator. You place the operator token after it to form the function name, for example operator== or operator*. The keyword friend can be used to grant access to a non-member overload, but it is not the keyword that makes the function an overload. The keyword override relates to virtual functions, not operators. There is no keyword named overload in C++. Step-by-Step Solution: Recall the syntax: return_type operatorX(parameters); Identify the fixed token: operator. Conclude the correct answer is “operator”. Note: friend is optional access control for non-member overloads. Verification / Alternative check: Attempting to declare overload void overload+(...) is illegal; compilers only recognize functions whose names begin with operator followed by a recognized operator token. Why Other Options Are Wrong: overload: not a C++ keyword. friend: affects access, not naming of operator overloads. override: applies to virtual functions to indicate overriding, unrelated to operator overloading per se. Common Pitfalls: Forgetting that some operators cannot be overloaded (e.g., ?:, ., ::, sizeof). Final Answer: operator

Question 14

C++ classes: what if a class is declared without a name (an anonymous class)? Choose the best statement based on standard practice.

Accepted Answer

Introduction / Context:In everyday C++ practice, classes are named user-defined types that you can declare, define, and instantiate. Anonymous types exist for certain constructs (like unnamed unions in some contexts), but ordinary class declarations are expected to have an identifier when intended for general use. This question probes whether nameless class declarations are permitted in the usual sense presented in introductory curricula and MCQs. Given Data / Assumptions: We consider typical class definitions intended for use and instantiation. We are not discussing anonymous structs/unions as members or compiler extensions. We interpret the MCQ in a standard educational context. Concept / Approach: Standard C++ codebases define classes with names so they can be referenced, instantiated, and used in interfaces. While certain advanced patterns and special cases exist (e.g., unnamed classes used inline as members in some compilers), they are not part of common, portable style. Thus, the practical and pedagogical answer is that a class “without any name” is not allowed in the ordinary sense of defining a reusable type. Therefore, among the provided options, “It is not allowed.” is the best answer. Step-by-Step Solution: Ask: how would you instantiate or refer to an unnamed class? You cannot name it at use sites, breaking typical usage. Therefore, common C++ guidance treats such a declaration as invalid or unusable for normal programming. Select “It is not allowed.” Verification / Alternative check: Compilers will reject most attempts to define a top-level anonymous class meant for instantiation as a type. Practical examples in teaching material uniformly present named classes. Anonymous aggregates are a separate topic and not what this question targets. Why Other Options Are Wrong: “Cannot have a constructor” or “cannot have a destructor” are red herrings; the core issue is the unusability/invalidity, not specific member availability. “Both A and B” accumulates two incorrect premises. Common Pitfalls: Confusing anonymous unions/structs (special-case) with general class types. Final Answer: It is not allowed.

Question 15

C++ static members: which statements about static data and static member functions are correct?

Accepted Answer

Introduction / Context:Static members in C++ belong to the class itself rather than to any individual object. Understanding their access rules and lifetime is critical for designing shared counters, cached state, or class-wide configuration. This question asks which statements accurately describe static data members and static member functions. Given Data / Assumptions: Static data members have a single storage location shared by all instances. Static member functions do not have a this pointer. Access from outside typically uses ClassName::member syntax. Concept / Approach: A static member function lacks the implicit object pointer (this), so it cannot access non-static members directly because those require an object. It can, however, access static data members. A static data member is indeed shared across all objects. While you can access a public static data member “from main” using ClassName::member (or through an object), the option’s wording “directly” is ambiguous. Therefore, the best precise choice among the provided options is “Both A and B.” Step-by-Step Solution: Confirm statement A: true because no this pointer exists in static functions. Confirm statement B: true by definition of static storage per class. Evaluate statement C: true only via scope resolution and subject to access control; wording is imprecise. Select D (Both A and B) as the accurate option set. Verification / Alternative check: Write a small program with a class counter and a static incrementor(). Attempting to read a non-static field from a static function without an object fails to compile. Accessing the static field as ClassName::counter works as expected. Why Other Options Are Wrong: C alone overstates “direct” access without clarifying syntax and access level. A or B alone omit the other equally correct fact. Common Pitfalls: Trying to use this in a static member function. Forgetting to define the static data member outside the class (pre-C++17) or using inline variables (C++17+) appropriately. Final Answer: Both A and B.

Question 16

C++ references vs pointers: why is a reference not the same as a pointer? Select the best comprehensive reason.

Accepted Answer

Introduction / Context:References and pointers are both indirection mechanisms, but they differ in semantics and safety. Understanding these differences guides API design, function parameter choices, and helps avoid undefined behavior. This question asks which properties collectively distinguish references from pointers in C++. Given Data / Assumptions: References are aliases bound to existing objects. Pointers are variables that store addresses and can be reseated, null, or invalid. We use standard C++ semantics without compiler extensions. Concept / Approach: A reference must be initialized to refer to a valid object and cannot later be made to refer to a different object; there is no “null reference” in standard C++ (though a reference may be bound to an object with problematic lifetime if misused). Access through a reference uses the same syntax as for the object itself, removing the need for explicit * dereferencing at use sites. By contrast, pointers can be null, can be reseated, and require * to access the pointed-to object (and -> for members). Step-by-Step Solution: Check A: references are required to be bound to a valid target at initialization ⇒ treated as non-null. Check B: a reference cannot be reseated to a different target. Check C: using a reference does not require explicit * dereference. Therefore, all three statements are correct ⇒ choose “All of the above.” Verification / Alternative check: Try compiling code that assigns a new address to a reference after initialization; it fails. Try taking the address of a reference variable; you get the address of the referent, not a separate pointer object. Using the reference in expressions behaves like using the original object. Why Other Options Are Wrong: Any single statement alone is incomplete; all three together describe the full semantic distinction. Common Pitfalls: Binding a reference to a temporary with insufficient lifetime. Assuming references are pointers under the hood and can be “reassigned.” Final Answer: All of the above.

Question 17

C++ pointers and inheritance: which statement is correct regarding pointers to base and derived classes?

Accepted Answer

Introduction / Context:Pointer conversions in inheritance hierarchies are fundamental for polymorphism. Correctly understanding which implicit conversions are allowed avoids type-unsafe code and undefined behavior. This question contrasts upcasting (derived to base) with the invalid notion of pointing a derived pointer at a base object. Given Data / Assumptions: Simple single inheritance is assumed for clarity. We consider implicit pointer conversions without casts. Objects are properly constructed of the indicated types. Concept / Approach: A pointer to a base can point to an object of a derived class (upcast), because every derived object contains a base subobject. However, the reverse is not true: a pointer to a derived class cannot safely point to a base object (downcast) without a checked mechanism, because the base object lacks the additional derived parts. Implicit conversion from base* to derived* is illegal. Therefore, the correct statement is that a derived class pointer cannot point to a base class object. Step-by-Step Solution: Establish rule: implicit upcast derived* → base* is allowed. Establish rule: implicit downcast base* → derived* is not allowed. Map to options: “Derived class pointer cannot point to base class.” matches the rule. Choose option B. Verification / Alternative check: Code sample: Base b; Base* pb = &b; Derived* pd = pb; // error. But Derived d; Base* p = &d; // OK. Using dynamic_cast with a polymorphic base can attempt downcasts safely at runtime, returning nullptr on failure. Why Other Options Are Wrong: “Base pointer cannot point to derived” is false; that is exactly what enables polymorphism. “Pointer to derived cannot be created” and “Pointer to base cannot be created” are nonsense; both can be declared. Common Pitfalls: Using C-style casts to force downcasts unsafely. Forgetting to make the base class polymorphic (virtual destructor) before using dynamic_cast on pointers/references. Final Answer: Derived class pointer cannot point to base class.

OOPS Concepts Questions

Questions

Practice smarter