Question 1

Library reuse: Can we derive a class from a base class even if the base class’s source code is not available (for example, only a header, binary, or assembly/metadata is provided)? Choose the best evaluation.

Accepted Answer

Introduction / Context: Reuse through inheritance often targets library types. In both C++ and C#, you can derive from classes defined in precompiled libraries as long as the compiler and linker (or runtime) can see the necessary interface/type information. Source code access is not required for inheritance to function. Given Data / Assumptions: C++: a header with declarations and a linked library/object providing definitions. C#: an assembly (DLL) exposing public/protected members via metadata. No private constructor-only bases or sealed classes preventing derivation. Concept / Approach: Compilers need type declarations (signatures, visibility, vtable layout in C++ per ABI) to compile derived classes. Linkers/CLR/JIT resolve definitions at build/run time. If the base class permits derivation (not final in C++ or sealed in C#), and the constructor/protected interface is accessible, you can derive without the source. This is standard practice when extending frameworks and SDKs. Step-by-Step Solution: Reference the base type declaration (header/assembly). Declare your derived class and override/extend as allowed. Build/link against the binary providing the base implementation. Verification / Alternative check: Many UI frameworks (MFC, .NET WinForms/WPF) and game engines encourage subclassing library classes without supplying their source code to developers. Why Other Options Are Wrong: Requiring source: unnecessary; declarations/metadata suffice. “Only if abstract” or “only with friends”: derivation rules are not restricted to these cases. Reflection is unrelated to normal inheritance. Common Pitfalls: Confusing the availability of symbol definitions at link/runtime with the need for source code; or forgetting sealed/final restrictions that can disallow derivation even if the type is visible. Final Answer: Correct — derivation needs the interface/type, not necessarily the full source.

Question 2

Access directionality: Because a derived class can access public members of its base class, does it follow that base-class member functions can access public members of the derived class? Provide the correct judgment.

Accepted Answer

Introduction / Context: The statement probes a common misunderstanding: that accessibility is symmetric across inheritance. In reality, inheritance grants the derived class visibility into the base’s accessible members, not vice versa. Base classes do not magically see derived members simply because a derived type exists. Given Data / Assumptions: Base has public/protected members; derived has its own members. We consider member function bodies defined inside the base type itself. No friend declarations or CRTP tricks are assumed. Concept / Approach: Access control is independent of object identity. A base-class member function is compiled in the context of Base, so it can access members declared in Base (per access specifiers) but not those declared later in Derived. While you can pass a Derived instance to a base function, that does not change what members the code is permitted to access. Virtual dispatch lets a derived override change behavior when called via a base interface, but it does not alter access rights of base code to derived data. Step-by-Step Solution: Define Base::f() — it can use Base’s public/protected/private (subject to rules) but not Derived’s members. Call f() via a Derived object — Base::f() still cannot name Derived’s members. Only friend relationships or downcasts with explicit knowledge of Derived (and accessibility) change what can be accessed, and even then, access rules still apply. Verification / Alternative check: Try to compile Base::f() referencing a Derived-only field; the compiler errors because the name is unknown in Base’s scope. Overriding a virtual in Derived does not grant Base visibility into Derived members. Why Other Options Are Wrong: “Public implies universal access up and down”: false; access is lexical and based on declaring scope. “Only when virtual” or “only with references”: dynamic dispatch affects behavior resolution, not access control. Common Pitfalls: Equating polymorphism (which member executes) with access rights (what names are visible within code). Final Answer: Incorrect — access does not work upward; base members do not gain access to derived members.

Question 3

Composition vs. inheritance: Is it illegal in C++ to declare objects of one class as data members of another class? Choose the most accurate statement.

Accepted Answer

Introduction / Context: This tests understanding of composition, a fundamental OO design technique where a class contains objects of other classes as members. C++ fully supports composition and relies on it for RAII and aggregation patterns. Declaring member objects is not only legal; it is idiomatic. Given Data / Assumptions: Two user-defined class types exist. One class defines an object of the other class as a data member. Constructors and destructors follow normal C++ rules. Concept / Approach: Composition embeds an object directly inside another object’s storage. Construction/destruction of member subobjects are automatically sequenced: members are constructed before the containing object’s body runs and destroyed in reverse order. Whether the member has a default constructor matters only for default-initialization; if it lacks one, you must initialize it explicitly in the owner’s member-initializer list. None of this makes composition illegal. Step-by-Step Solution: Declare class A and class B. Inside A, declare B b; or B b{args}; Ensure B is constructible using A’s constructor initializer list if needed. Verification / Alternative check: Try implementing a class that owns a std::string or std::vector. These are objects from the standard library; their presence as members exemplifies composition working seamlessly. Why Other Options Are Wrong: “Only fundamental types allowed”: incorrect; user-defined types are normal members. “Only if default constructor exists”: you can initialize with parameters instead. “Must be pointer”: pointers are optional; direct members are common and safer. “Illegal if unrelated”: relationship is irrelevant; composition does not require inheritance. Common Pitfalls: Forgetting to initialize non-default-constructible members in the initializer list; assuming composition implies ownership semantics identical to pointers (RAII usually makes it safer). Final Answer: Incorrect — it is legal and common (composition).

Question 4

Inherited member availability: If the base class defines a member function func(), and the derived class does not define a function with that name, can an object of the derived class call func()? Provide the correct evaluation.

Accepted Answer

Introduction / Context: The claim suggests a derived object cannot access a base member unless the derived redeclares it. In C++, members of the base are part of the derived object as long as they are not hidden and remain accessible under the chosen inheritance mode (public/protected/private) and access level (public/protected). Given Data / Assumptions: Base declares a function func() that is accessible to Derived (e.g., public). Derived does not declare another func(). Use public inheritance for typical behavior. Concept / Approach: With public inheritance, public base members remain public in the derived interface. Therefore, calls like Derived d; d.func(); are perfectly valid. Virtual is not required to call the function; virtual only affects which implementation runs when calling through a base interface and enabling overriding. If Derived declared another overload with the same name, name hiding could affect lookup, but in the scenario stated, no such overload exists. Step-by-Step Solution: Base::func() exists and is accessible. Derived does not declare its own func(). An expression of type Derived calls func() → Base::func() executes. Verification / Alternative check: Change inheritance to private: public members of Base become private within Derived and may not be callable from outside via a Derived object, but still callable inside Derived’s own member functions — showing access control matters, not the existence of an override. Why Other Options Are Wrong: “Cannot call unless redefined”: incorrect; inheritance exposes the base implementation. “Only if virtual”: virtuality is not required for direct calls. “Requires base scope qualification”: not necessary unless hidden by another declaration. Common Pitfalls: Confusing overriding with availability; and conflating access specifiers with the need to redeclare symbols in the derived class. Final Answer: Incorrect statement — the derived object can call func() if it is accessible via inheritance.

Question 5

C#.NET inheritance access modes: Does C# support private or protected forms of inheritance (i.e., changing base-member accessibility via an inheritance specifier)? Choose the most accurate statement.

Accepted Answer

Introduction / Context: The question contrasts C++ and C#. In C++, you can write class D : private B or class D : protected B to adjust base-member accessibility in the derived type. In C#, inheritance syntax does not support such specifiers for classes, so there is no notion of “private” or “protected” inheritance for classes. Given Data / Assumptions: We are discussing class inheritance in C#. C# allows a single base class and multiple interfaces. Accessibility of inherited members is governed by their declared access modifiers and by the derived class’s context, not by an inheritance-mode keyword. Concept / Approach: The C# class declaration syntax uses a colon followed by the base class name (if any) and implemented interfaces. There is no grammar to place private or protected before the base class name to alter how members are exposed. Public, protected, internal, and private modifiers control member accessibility in the declaring class, and derived classes observe those rules; inheritance itself has no “mode” to tighten them for the derived public surface. Step-by-Step Solution: class Derived : Base { } → valid; no inheritance mode keyword. Attempt class Derived : private Base { } → invalid in C#. Member accessibility remains determined by each member’s modifier and assembly boundaries. Verification / Alternative check: Compiling a “private inheritance” attempt in C# yields syntax errors. Interfaces can be listed freely, but again, no inheritance-mode keywords exist for classes. Why Other Options Are Wrong: Claims that C# supports private/protected inheritance: false. “Only for interfaces”: interfaces are implemented, not inherited with access modes. “Protected inheritance is default”: non-existent in the language. Abstract base does not change the rule. Common Pitfalls: Projecting C++ features onto C#, or confusing member access modifiers with inheritance-mode specifiers. Final Answer: Correct — C# has only one inheritance form; you cannot declare private/protected inheritance.

Question 6

Object-oriented programming (C++/OOP): Does creating a derived class require fundamental changes to the existing base class?  Choose the most accurate statement about inheritance design and source-code impact.

Accepted Answer

Introduction / Context: Inheritance is a core concept in object-oriented programming (OOP). The question probes a common misconception: that introducing a derived (sub)class forces sweeping or “fundamental” changes to an existing base class. Sound OOP design emphasizes substitutability, encapsulation, and extensibility without retrofitting the base. Given Data / Assumptions: We have a stable base class that exposes a public/protected interface. A new derived class will inherit from that base. “Fundamental changes” means breaking public contracts, altering invariants, or reworking core behaviors of the base. Concept / Approach: Inheritance allows a derived class to reuse and extend behavior via the base’s public/protected interface. Because encapsulation hides implementation details, adding a subclass typically does not require modifying the base. If changes are needed, they are usually additive (e.g., adding virtual hooks or protected extension points) rather than fundamental. The Liskov Substitution Principle encourages designing bases so that derived types can slot in without base changes. Step-by-Step Solution: Identify base responsibilities and its stable interface.Confirm the derived class relies on existing public/protected members.Implement overrides/extra methods in the derived class; avoid touching private base data.Optionally add non-breaking extension points (virtual functions) if future variation is anticipated.Result: no fundamental base changes are required to introduce the derived class. Verification / Alternative check: Many frameworks (e.g., GUI toolkits) let you derive and override behavior without editing the base classes. If base redesign is routinely required, the abstraction is likely leaky and needs refactoring, not because inheritance intrinsically demands it. Why Other Options Are Wrong: Correct: Claims fundamental base changes are required; this contradicts encapsulation and standard OOP practice. Not applicable / Depends on compiler / Only in multiple inheritance: Inheritance semantics are language-level; compilers do not demand such changes, and multiple inheritance is not a prerequisite. Common Pitfalls: Confusing “adding virtual” with “fundamental change”; conflating refactoring for better extensibility with a strict requirement; exposing base internals that force downstream edits. Final Answer: Incorrect

Question 7

Object-oriented programming: Is multilevel inheritance allowed (A → B → C → D)?  Select the statement that best reflects C++/Java-style inheritance rules.

Accepted Answer

Introduction / Context: Multilevel inheritance means a class derives from a class that itself derives from another class, forming a chain such as A → B → C → D. This is a foundational capability in classical OOP languages like C++ and is conceptually supported in Java via single inheritance of classes (interfaces are separate). The question tests whether such layered hierarchies are permitted. Given Data / Assumptions: We consider typical OOP languages with single inheritance of implementation for classes (e.g., C++, Java). The chain A → B → C → D represents class D extending C, which extends B, which extends A. No multiple-inheritance-of-classes is being asserted—only multilevel (transitive) inheritance. Concept / Approach: In multilevel inheritance, every class in the chain inherits the accessible members of its parent. Constructors and destructors (or finalizers) are invoked in well-defined orders. Method overriding, virtual dispatch (C++) or dynamic dispatch (Java), and polymorphism apply transitively. Step-by-Step Solution: Define base A with some interface/behavior.Define B : A to inherit and extend A.Define C : B, further extending behavior.Define D : C, completing the chain. This is valid and common. Verification / Alternative check: Many standard libraries organize types in inheritance chains (e.g., Java’s java.io hierarchy). Unit tests that instantiate D can call methods from A, B, and C according to access rules. Why Other Options Are Wrong: Incorrect: Denies a supported language feature. Only with interfaces / Only with abstract classes: Not required; concrete classes may participate. Runtime dependent: This is a compile-time language feature, not runtime dependent. Common Pitfalls: Confusing multilevel inheritance (legal) with multiple inheritance of classes (restricted in Java). Poorly designed deep chains can harm maintainability, but that is a design smell, not a prohibition. Final Answer: Correct

Question 8

Access control in inheritance: Can a derived class object access private members of its base class directly?  Choose the most accurate statement.

Accepted Answer

Introduction / Context: Encapsulation restricts how data and functions are accessed across class boundaries. Private members belong strictly to the class that declares them. The prompt tests whether a derived class object can directly access a base class’s private members, which is a frequent source of confusion for learners. Given Data / Assumptions: We have a base class with private data/methods. A derived class inherits from that base. We consider direct access (e.g., obj.privateMember) rather than mediated access (e.g., via public/protected methods). Concept / Approach: In C++/Java-like access control, private members are accessible only to the declaring class (and its friends in C++). Derived classes do not gain direct access to the base’s private section. They may interact via public or protected interface, getters/setters, or friend functions (in C++), but not by direct access. Step-by-Step Solution: Define Base with private: data.Define Derived : public Base.Attempt to access Base::data directly inside Derived → compile-time error.Access instead through Base’s public/protected functions, or a friend that exposes data safely (C++). Verification / Alternative check: Compilers enforce private access; adding a protected accessor in Base or making Derived a friend (C++) changes accessibility by design choice, not inheritance alone. Why Other Options Are Wrong: Incorrect: States the opposite of encapsulation rules. Only with friend declarations: Friendship is a separate mechanism; the generic statement “cannot access” remains true without such special arrangements. Only via public inheritance / Only when using protected: Inheritance mode does not expose private members; protected affects member visibility to derived classes but only for protected/public members, not private. Common Pitfalls: Assuming inheritance “opens up” private data; conflating “is-a” with “has access to everything.” Final Answer: Correct

Inheritance Questions