Question 1

C++ constructors vs. destructors: which statement correctly compares their ability to take arguments and return values?

Accepted Answer

Introduction / Context: Special member functions govern object lifetime in C++. Constructors initialize a newly created object; destructors finalize and clean it up. Understanding the exact grammar constraints for these functions—such as whether they accept parameters, return values, or allow overloading—is essential for writing correct RAII-style code and for interpreting compiler errors accurately. Given Data / Assumptions: A constructor can be default, parameterized, copy, or move. A destructor has the form ~ClassName() and is invoked automatically at the end of lifetime. We consider standard C++ behavior without extensions. Concept / Approach: Constructors may take parameters; that is precisely how you support configurable initialization (e.g., Vector(int n), String(const char*)). Destructors, by contrast, are declared with an empty parameter list and can never take arguments. Neither constructors nor destructors return a value (not even void). Overloading is permitted for constructors (multiple parameter lists), but there is exactly one destructor per class, optionally virtual, and it cannot be overloaded. Therefore, the only correct comparison in the options is that constructors can take arguments but destructors cannot. Step-by-Step Solution: Assess A: false — destructors cannot take parameters; constructors can. Assess B: true — matches the language rules. Assess C: false — constructors can be overloaded; destructors cannot. Assess D: false — neither returns any value. Verification / Alternative check: Attempt to declare ~C(int) → compile-time error. Define multiple constructors with distinct parameter lists → valid overloading. Attempt to give constructors/destructors a return type → rejected by the compiler. Why Other Options Are Wrong: A: flips the truth about parameters. C: reverses overloading realities. D: contradicts the rule that special members have no return type. Common Pitfalls: Confusing destructor parameters with user data passed to cleanup code (instead, store needed state as members). Assuming multiple destructors are possible; use conditional cleanup inside the single destructor. Final Answer: Constructors can take arguments but destructors cannot.

Question 2

C++ abstract classes: what is the correct way to make a class abstract (non-instantiable)?

Accepted Answer

Introduction / Context: An abstract class in C++ serves as an interface or a base with incomplete behavior. It cannot be instantiated directly; instead, derived classes complete the behavior. This is central to polymorphism and clean API design, especially when you want to enforce contracts on subclasses while sharing common infrastructure in the base. Given Data / Assumptions: A “pure virtual function” is declared with = 0 in its declaration. Const member functions and the virtual keyword are distinct notions. No special keyword like “abstract” exists in standard C++ to mark classes as abstract. Concept / Approach: A class becomes abstract if it declares (or inherits unimplemented) at least one pure virtual function, for example virtual void draw() = 0;. This signals that the base provides an interface contract but lacks an implementation. Derived classes must override the pure virtual function(s) to be instantiable. Using the virtual keyword alone does not make a function pure; it only enables dynamic dispatch. Marking functions const controls whether they can modify the object; it does not affect abstractness. There is no abstract keyword in standard C++. Step-by-Step Solution: Choose a function that should be overridden by derived classes. Declare it pure virtual: virtual Ret f(params) = 0; The class now cannot be instantiated directly. Derived classes must provide f(...) to become concrete. Verification / Alternative check: Attempt to instantiate an abstract class with a pure virtual function; the compiler emits an error. Provide an override in a derived class and instantiate that; compilation succeeds, confirming the mechanism. Why Other Options Are Wrong: All functions constant — unrelated to abstractness. static keyword — unrelated; affects storage linkage, not abstractness. virtual keyword by itself — enables polymorphism but does not make a function pure. Common Pitfalls: Forgetting to mark destructors virtual in abstract bases used polymorphically. Leaving a pure virtual destructor without a definition; it still requires one if used. Final Answer: By making at least one member function a pure virtual function.

Question 3

C++ class design: what relationship is expressed by the following definitions? class Bike { Engine objEng; }; class Engine { float CC; };

Accepted Answer

Introduction / Context: Object-oriented design uses relationship vocabulary to describe how types relate. “Is-a” denotes inheritance (a specialized kind of the base), while “has-a” denotes composition/aggregation (an object contains or owns another object). Correctly identifying the relationship guides design choices like lifetime management and interface exposure. Given Data / Assumptions: class Bike { Engine objEng; }; — Bike has a data member of type Engine. Engine is a separate class with some state (e.g., displacement in CC). No inheritance is present in the snippet (no colon syntax). Concept / Approach: The presence of an Engine data member inside Bike indicates composition: a Bike has an Engine. This is typically a strong “has-a” relationship, often implying ownership and synchronized lifetimes (the Engine subobject is constructed and destroyed with the Bike). An “is-a” (inheritance) relationship would have used the syntax class Bike : public Engine { ... };. Vague phrases like “kind of relationship” do not correspond to standard OO terminology and are not specific enough to be correct here. Step-by-Step Solution: Inspect Bike: contains Engine as a direct data member → composition. No base-class list (:) → not inheritance. Therefore, relational phrase is “has a relationship.” Verification / Alternative check: Consider construction order: when a Bike is created, its Engine member is constructed first. On destruction, Engine is destroyed last among members. This lifecycle coupling is characteristic of composition and confirms the “has-a” judgment. Why Other Options Are Wrong: kind of relationship — not a standard term; too vague. Inheritance — would require class Bike : public Engine, which is absent. Both A and B — includes a non-standard term; only “has a relationship” fits. Common Pitfalls: Confusing aggregation (has-a, possibly non-owning) with inheritance (is-a). Using public inheritance to model “has-a,” which misstates the type relationship. Final Answer: has a relationship

Question 4

C++ virtual base classes: what is their primary purpose in a multiple-inheritance hierarchy?

Accepted Answer

Introduction / Context: Multiple inheritance can produce the “diamond problem,” where a derived class inherits from two intermediate bases that themselves inherit from the same grand base. Without special handling, the final most-derived class can contain two independent subobjects of the grand base, leading to ambiguity and duplication. Virtual base classes solve this problem. Given Data / Assumptions: Class D derives from B and C; both B and C derive from A. We want a single shared A subobject inside D. We use the virtual keyword in the base-specifier list. Concept / Approach: Declaring inheritance as class B : virtual public A and class C : virtual public A tells the compiler that any most-derived class should contain one shared A subobject, not one per path. The most-derived class is responsible for constructing the virtual base, eliminating ambiguities (e.g., which A::f() or which A data to use) and reducing memory overhead of duplicated subobjects. This feature does not “provide multiple inheritance” by itself; it modifies how a base is shared when multiple inheritance exists. It does not change access control (private members remain inaccessible directly) and certainly is not meant to create multiple copies—quite the opposite. Step-by-Step Solution: Identify diamond pattern → risk of duplicate A subobjects. Apply virtual inheritance on the shared base A in intermediate classes. Most-derived class now holds one A; ambiguity eliminated. Verification / Alternative check: Compile with and without virtual inheritance and inspect object layout or method calls; you will see duplicate A instances without virtual inheritance and one shared A with virtual inheritance, confirming the purpose. Why Other Options Are Wrong: Provide multiple inheritance — that is the role of listing multiple bases; virtual affects sharing, not availability. Allow multiple copies — opposite of the actual goal. Allow private members to be inherited — access control is unchanged; private remains inaccessible to derived classes. Common Pitfalls: Forgetting that the most-derived class must construct the virtual base explicitly in its member-initializer list. Misunderstanding that virtual inheritance affects layout and constructor order. Final Answer: It is used to avoid multiple copies of base class in derived class.

Question 5

C++ data members: which category is shared by all instances of the class?

Accepted Answer

Introduction / Context: Class design often distinguishes between per-object state and per-class state. When a value should be common across all objects (for example, a counter of instances or a configuration flag), C++ provides a specific storage class and access pattern to model this: static data members. Understanding this distinction avoids redundant storage and keeps invariants centralized. Given Data / Assumptions: Per-object members exist separately in each instance. Per-class members exist once regardless of the number of instances. Access control (public/private/protected) is independent from whether a member is static or non-static. Concept / Approach: A static data member is allocated once and shared among all instances of the class. It can be accessed via the class name (e.g., T::count) or through an object (though the former is clearer). Public/private affects visibility, not multiplicity. “Inherited” is not a storage class; it merely describes where names come from in hierarchies. “Friend” is an access grant, not a data member category. Hence, the only option that encodes “shared by all instances” is static. Step-by-Step Solution: Identify need: single storage shared across objects. Choose static data member and define it (and, in pre-C++17, provide an out-of-class definition). Access it via ClassName::member for clarity and encapsulate with static member functions if needed. Verification / Alternative check: Instantiate several objects and modify a static member through one of them; observe the updated value through all others and via the class name, confirming shared storage. Why Other Options Are Wrong: Public — concerns visibility, not sharing. Inherited — not a storage specifier. Friend — grants access to another function/class; not a member kind. Common Pitfalls: Forgetting to define non-inline static data members in a translation unit (before C++17). Confusing static data members with static local variables inside functions. Final Answer: Static

Question 6

C++ friendship: which statement correctly describes valid use of the friend keyword inside a class?

Accepted Answer

Introduction / Context: Friendship in C++ is an access-control feature that allows a specified function or class to access the private and protected members of another class. It is commonly used to implement symmetric operators, tight collaborations between classes, or non-member helper functions that require privileged access without making data public. Given Data / Assumptions: friend grants access to named functions or entire classes, not to specific data members. Friendship is neither inherited nor transitive. Keywords cannot be reused as identifiers. Concept / Approach: Inside a class definition, you can declare either a specific function or another class as a friend. Doing so gives the friend full access to private/protected members of the declaring class. You cannot declare a particular data member as a friend; access always targets functions or whole classes. Friendship is to types or functions, not specific object instances, so “an object as a friend” is meaningless. Finally, the token friend is a reserved keyword and cannot be used as a class name. Step-by-Step Solution: Option A → invalid: data members cannot be friends. Option B → valid: friend class Logger; is legal. Option C → invalid: friendship is not per-object. Option D → invalid: friend is a reserved keyword. Verification / Alternative check: Create two classes and declare one as friend of the other. Access private fields in the friend class's methods; it compiles. Attempt to mark a single data member as friend or to friend an object variable; the compiler rejects these constructs. Why Other Options Are Wrong: Private data member as friend — syntactically and semantically unsupported. Object as friend — friendship is granted to functions or classes, not instances. friend as class name — violates the reserved keyword rule. Common Pitfalls: Overusing friendship instead of designing clearer public interfaces. Expecting friendship to be inherited down the hierarchy; it is not. Final Answer: A class may be declared as a friend.

Question 7

C++ static member functions: evaluate two claims about their access and how they are called.

Accepted Answer

Introduction / Context: Static member functions operate at the class level, not on a particular object instance. They are commonly used to manipulate static data members, implement factories, or provide utility operations closely tied to a class's abstraction, while not requiring an object pointer (this) at the call site. This question asks you to validate two common statements about them: access constraints and call syntax. Given Data / Assumptions: Statement 1: A static member function can access only other static members of its class. Statement 2: A static member function can be called using the class name, not just objects. We consider standard C++ rules for static members. Concept / Approach: Because static member functions do not have an implicit object (no this pointer), they cannot directly access non-static data members or non-static member functions, which require an object context. They can, however, access static data members and call other static member functions. For invocation, the canonical form is ClassName::func(...), although calling through an object is syntactically allowed but unnecessary. Therefore, both statements accurately describe static member functions. Step-by-Step Solution: Confirm lack of this pointer → can't access instance members directly. Static functions/data are class-level → accessible. Call via ClassName::func() → valid and idiomatic. Hence, both statements are true. Verification / Alternative check: Attempt to use a non-static data member inside a static function; the compiler complains about missing object. Access a static counter or call another static function; compilation succeeds. Invoke the function as T::f() and also via an instance; both compile, the former being clearer. Why Other Options Are Wrong: “Only 1” or “Only 2” — each ignores that both statements hold. “Both incorrect” — contradicts fundamental static semantics. Common Pitfalls: Attempting to read or write non-static members in a static function without passing an object. Confusing static member functions with free functions in the same namespace. Final Answer: Both 1 and 2 are correct.

Question 8

C++ public inheritance: under public inheritance, how do base-class public members appear in the derived class?

Accepted Answer

Introduction / Context: Inheritance in C++ can be public, protected, or private. The chosen access specifier alters how base-class members are exposed through the derived class's interface. Public inheritance models an “is-a” relationship that preserves the base's public API, enabling substitutability (the Liskov Substitution Principle) and polymorphic use through base references or pointers. Given Data / Assumptions: We consider class D : public B. Public/protected/private in the base determine initial accessibility. Public inheritance preserves access of public and protected members (modulo rules stated below). Concept / Approach: Under public inheritance, the access levels are preserved for the derived interface: base public members remain public in the derived class; base protected members remain protected; base private members are not accessible directly by the derived class (though they exist as part of the object). This preservation is why clients can use a derived object wherever a base is expected. If you change the inheritance to protected or private, the visibility is reduced accordingly, but not under public inheritance. Step-by-Step Solution: Compare options to the rule of public inheritance. Only option D matches: base public → derived public. Options A/B contradict preservation; C discusses private members, which remain inaccessible, not promoted. Verification / Alternative check: Write a base with a public method and derive publicly; call that method on a derived instance from client code. It compiles, showing the public interface was preserved. Why Other Options Are Wrong: A/B — would reduce visibility, not how public inheritance behaves. C — private members are not inherited as accessible members; they remain hidden. Common Pitfalls: Assuming private members “become” protected or public—they do not. Forgetting that overriding access can also be applied per-member in the derived class. Final Answer: Public members of the base class become public members of derived class.

Question 9

C++ classes: what is the default access specifier used inside a class definition (if none is written)?

Accepted Answer

Introduction / Context: C++ distinguishes between classes and structs not by features but by defaults. Both support the same mechanisms: member functions, constructors, inheritance, templates, and so on. The key difference is the default access level of members and base classes when no explicit access specifier is provided. Remembering these defaults prevents accidental exposure or hiding of APIs. Given Data / Assumptions: We are declaring members inside a class (not a struct). No explicit access label (public/protected/private) precedes the members. Standard C++ access rules apply. Concept / Approach: For a class, the default access specifier for members is private. For a struct, the default is public. This distinction also applies to base-class access in inheritance lists: class D : B implies private inheritance by default, while struct D : B implies public inheritance by default. Because the question explicitly asks about a class definition, the correct answer is private. Options like “Friend” are not access levels at all; friend is a separate language feature granting access to another function or class. Step-by-Step Solution: Consider class C { int x; void f(); } → x and f are private by default. Contrast with struct S { int x; }; → x is public by default. Therefore, choose “Private.” Verification / Alternative check: Attempt to access an unlabelled member of a class from outside; the compiler rejects it. Mark the same member in a struct; it becomes accessible. Add public: to the class and access now succeeds, confirming the default. Why Other Options Are Wrong: Protected/Public — these are valid access levels, but they are not the defaults for class. Friend — not an access specifier; it is a separate friendship declaration mechanism. Common Pitfalls: Assuming struct and class differ fundamentally; they differ only in defaults. Forgetting to mark intended public APIs in classes with public:. Final Answer: Private

Question 10

In C++ polymorphic class design, which statement is correct regarding the destructor of a base class that may be deleted through a base pointer? Choose the best practice that prevents resource leaks and undefined behavior.

Accepted Answer

Introduction / Context: When designing inheritance hierarchies in C++, objects are often manipulated via base-class pointers or references. If you delete a derived object through a base pointer, the correct destructor must run to release all acquired resources. This question targets the essential rule that enables safe polymorphic destruction. Given Data / Assumptions: A base class may be used polymorphically (i.e., it has at least one virtual member function or is intended for inheritance). Derived classes may own additional resources that require cleanup in their destructors. Deletion may occur through a base pointer: delete basePtr; Concept / Approach: Declaring the base-class destructor as virtual ensures dynamic dispatch on destruction. With a virtual destructor, delete basePtr first calls the most-derived destructor, then unwinds through base classes, guaranteeing complete cleanup and preventing leaks or partial destruction. Step-by-Step Solution: 1) Declare: struct Base { virtual ~Base() {} };2) Derive: struct Derived : Base { ~Derived() override { /* free derived resources / } };3) Allocate polymorphically: Base p = new Derived();4) Delete via base: delete p; → calls Derived::~Derived() then Base::~Base(). Verification / Alternative check: Add logging in both destructors; observe that the derived destructor executes first. Removing virtual causes only Base::~Base() to run when deleting through a base pointer, which is unsafe. Why Other Options Are Wrong: Static/private/inline-only: none of these access or linkage attributes provide dynamic dispatch; they do not solve polymorphic deletion.“Should not be virtual”: incorrect and dangerous in polymorphic contexts. Common Pitfalls: Forgetting to mark a polymorphic base destructor virtual leads to undefined behavior when deleting through base pointers. Conversely, making every destructor virtual needlessly can add slight overhead; do it for polymorphic bases. Final Answer: Destructor of base class should always be virtual.

Question 11

In object-oriented analysis and design (C++/UML), what does a class hierarchy primarily depict? Select the relationship a class–subclass tree is intended to model.

Accepted Answer

Introduction / Context: A class hierarchy is the backbone of inheritance. Understanding what it communicates conceptually is crucial for correct modeling. The question asks which real-world relationship a hierarchy intends to express. Given Data / Assumptions: Classes may form parent–child relations via inheritance. Different forms of association exist: composition (has-a), usage (uses), and inheritance (is-a / kind-of). We are focusing on the meaning of the inheritance diagram (a class tree). Concept / Approach: Inheritance models an “is-a” or “kind-of” relationship. A Dog is a kind of Animal; a Square is a kind of Shape. This is distinct from “has-a” (composition/aggregation), where an object contains or owns another object (e.g., Car has an Engine). Thus a class hierarchy primarily expresses “kind of”. Step-by-Step Solution: 1) Identify inheritance (Base ← Derived) → semantic meaning: Derived is-a Base.2) Map to wording: “kind of” is the best natural-language equivalent of is-a.3) Recognize alternatives: “has-a” corresponds to fields/members (composition), not the hierarchy tree.4) Therefore, choose “It describes 'kind of' relationships.” Verification / Alternative check: UML generalization arrows encode is-a; composition/aggregation are separate notations. Documentation consistently defines hierarchies as modeling is-a. Why Other Options Are Wrong: Organization chart / family tree: visual analogies but not precise semantics.“Has a”: that is composition/aggregation, not inheritance.“Uses”: denotes dependency, not hierarchical generalization. Common Pitfalls: Overusing inheritance to model “has-a”; prefer composition for containment to reduce coupling and improve flexibility. Final Answer: It describes 'kind of' relationships.

Question 12

C++ static member function pointer: consider the program below. What is the correct outcome when compiling/linking? class CuriousTab { public: static void MyFunction(); }; int main() { void(ptr)() = &CuriousTab::MyFunction; return 0; }

Accepted Answer

Introduction / Context: This snippet tests knowledge of static member functions and function pointers in C++. Static member functions have no implicit object parameter and can be used like ordinary free functions with respect to taking their addresses. The subtlety here is the difference between successful compilation and successful linking. Given Data / Assumptions: Class CuriousTab declares a static member function: static void MyFunction(); No out-of-class definition of CuriousTab::MyFunction is provided. main takes the function’s address into a pointer of type void()(). Concept / Approach: Taking the address of a static member function is legal and yields an ordinary function pointer type compatible with void()(). The code will compile because the declaration is visible and the types match. However, because the function is only declared and never defined, the linker cannot resolve the symbol CuriousTab::MyFunction, producing an unresolved external reference (linker error). Step-by-Step Solution: 1) Parse declarations: static member → no this pointer → OK to form &CuriousTab::MyFunction.2) Type check: assignable to void()() → OK.3) Linking: reference to MyFunction must bind to a definition; none exists.4) Result: link fails with an unresolved symbol error. Verification / Alternative check: Add a definition: void CuriousTab::MyFunction() {}. Rebuild → program links successfully. Removing the assignment or not using the symbol may still require a definition depending on optimization; conservatively, the missing definition is a link-time error. Why Other Options Are Wrong: A/B/C: Misstate pointer rules; static member functions are addressable via ordinary function pointers without an object.E: Incorrect because the symbol remains undefined at link time. Common Pitfalls: Confusing pointer-to-member-function syntax (for non-static members) with static members. Non-static member pointers have type like void (Class::*)() and require an instance to invoke. Final Answer: The program reports linker error.

Question 13

In C++ terminology, which entity is also known as an instance of a class? Select the most accurate term used in object-oriented programming.

Accepted Answer

Introduction / Context: Object-oriented programming distinguishes between a class (the blueprint) and its concrete realizations. The question asks for the standard term for a concrete realization of a class. Given Data / Assumptions: Classes define data members and member functions. At runtime or during execution, concrete entities are created from classes. We seek the canonical term for such concrete entities. Concept / Approach: An object is an instance of a class. It occupies memory, maintains state, and supports operations (methods) defined by its class. Multiple objects can be instantiated from the same class, each with its own state. Step-by-Step Solution: 1) Define a class, e.g., class Point { int x, y; };2) Create instances: Point p1; Point p2;3) p1 and p2 are objects (instances) of Point, each storing its own x and y.4) Methods operate on these objects to read/modify state. Verification / Alternative check: Consult any OOP primer: “class = blueprint, object = instance”. The standard library types (std::string, std::vector) are classes; variables of these types are objects. Why Other Options Are Wrong: Friend functions: free or member-like functions granted special access, not instances.Member functions/variables: components of a class/object, not the instance itself.Namespace: a scope construct, not an instance. Common Pitfalls: Calling classes “objects” or vice versa; remember a class describes behavior and structure, an object embodies them at runtime. Final Answer: Object

Question 14

In C++ language features, which of the following can be overloaded to provide multiple meanings based on parameter types or counts? Choose the most complete answer.

Accepted Answer

Introduction / Context: Overloading allows the same name or symbol to represent different operations depending on argument types or arity. C++ supports two primary forms of overloading: function overloading and operator overloading. Identifying both is fundamental to idiomatic C++. Given Data / Assumptions: Function overloads differ by parameter types, counts, or cv/ref qualifiers. Operator overloading is implemented via specially named functions (e.g., operator+). Objects and namespaces are not overloadable entities themselves. Concept / Approach: Function overloading lets you define multiple functions with the same name but different parameter lists. Operator overloading lets you give standard operators (+, -, [], (), etc.) custom behavior for user-defined types while preserving operator syntax. Both are resolved at compile time via overload resolution rules. Step-by-Step Solution: 1) Function: void print(int); void print(std::string const&);2) Operator: struct Vec { Vec operator+(Vec const&) const; };3) Calls like print(42) vs print(s) select the correct overload at compile time.4) Using v1 + v2 invokes Vec::operator+. Verification / Alternative check: Compile examples; observe that the compiler picks appropriate overloads without runtime cost. Why Other Options Are Wrong: Object: instances are not “overloaded”.Namespaces: they organize code; their names are not overloadable constructs. Common Pitfalls: Abusing operator overloading to create confusing semantics; follow established expectations (e.g., + should not mutate in surprising ways). Final Answer: Both B and C

Question 15

C++ inheritance syntax check: what happens when compiling the following class definitions? class Birds {}; class Peacock : protected Birds {};

Accepted Answer

Introduction / Context: C++ supports three access specifiers in inheritance: public, protected, and private. Understanding their legality and effects on member access and interface exposure is key. This item checks whether “protected inheritance” is valid and whether empty class definitions compile. Given Data / Assumptions: Base class Birds is defined with an empty body. Derived class Peacock inherits using the protected access specifier. No members or constructors are explicitly declared. Concept / Approach: Protected inheritance is legal C++ syntax. It changes how public and protected members of the base appear in the derived class’s interface (they become protected in the derived). Empty class bodies are also valid. Therefore, the code compiles successfully as-is. Step-by-Step Solution: 1) Parse class Birds {}; → valid empty class.2) Parse class Peacock : protected Birds {}; → valid inheritance declaration.3) No rule requires bodies to contain members; empty is fine.4) Conclusion: compilation succeeds. Verification / Alternative check: Compile the snippet in any conforming compiler; it will succeed. Add members to observe how access transforms under protected inheritance. Why Other Options Are Wrong: A/B: Empty class bodies are fully legal.C: Protected inheritance is supported by the language.E: A virtual destructor is unrelated to the legality of inheritance syntax here. Common Pitfalls: Confusing inheritance access specifiers with member access specifiers. Inheritance access controls how base’s public/protected members are exposed by the derived, not their actual accessibility within member functions. Final Answer: It will compile succesfully.

Question 16

Dot operator (.) in C++: which pair of entities, read from left to right, can it legally connect? Pick the most precise description of member access.

Accepted Answer

Introduction / Context: The dot operator is the standard member-access operator for objects in C++. Correctly identifying what appears on each side clarifies how to read and write idiomatic code. Given Data / Assumptions: The left operand must be an object, reference, or lvalue of class/struct/union type. The right operand must be a member (data or function) of that type. Static vs non-static members both use the same syntax on objects; scope operator :: is for types/namespaces. Concept / Approach: Member access uses object.member. For pointer-to-object, use the arrow operator: ptr->member. To access static members without an instance, qualified lookup uses ClassName::member. Thus, dot specifically connects an object on the left to a member of that object’s class on the right. Step-by-Step Solution: 1) Point p; p.x; → object p to its data member x.2) p.length(); → object p to its member function length().3) Point::origin(); → uses scope operator, not dot (class to static member).4) Point* q; q->x; → uses arrow, not dot. Verification / Alternative check: Compile examples using dot vs arrow vs scope operator to see which combinations are allowed. Why Other Options Are Wrong: Class-to-member uses ::, not .Member-to-object order is reversed; the left must be the object.Namespaces use :: for qualified lookup, not . Common Pitfalls: Attempting to use dot on pointers (should use ->), or using dot with class names instead of instances for static members (should use ::). Final Answer: A class object and a member of that class.

Question 17

C++ syntax basics: what is the only technical difference between a struct and a class in C++ (ignoring stylistic conventions)?

Accepted Answer

Introduction / Context: In modern C++, structs and classes are nearly identical constructs. The notable distinction is their default access level, which affects encapsulation when you omit explicit access specifiers. Given Data / Assumptions: Both struct and class can contain data members, member functions, constructors, destructors, and even inheritance. Access specifiers available: public, protected, private. We focus on defaults when none are specified. Concept / Approach: By default, members of a struct are public; members of a class are private. Likewise for base-class inheritance: struct defaults to public inheritance, class to private inheritance. Otherwise, capabilities are the same. You can override defaults with explicit access specifiers. Step-by-Step Solution: 1) struct S { int x; }; → x is public by default.2) class C { int x; }; → x is private by default.3) struct D : Base {}; → public inheritance by default; class E : Base {}; → private by default.4) Functionality (constructors, operators, templates) is shared; only defaults differ. Verification / Alternative check: Compile code accessing S::x directly vs C::x; you will see that access to C::x fails unless made public. Why Other Options Are Wrong: Protected-by-default: incorrect for both forms.“Structs cannot have member functions”: false—structs are classes under a different keyword. Common Pitfalls: Assuming “struct is C-style POD only”—not true in C++; use struct for passive aggregates by convention, but it has full class features. Final Answer: Member function and data are by default public in structures but private in classes.

Question 18

In object-oriented design, what term describes the use of an object of one class inside the definition of another class (i.e., a has-a relationship)?

Accepted Answer

Introduction / Context: Classes often collaborate by containing other objects. This design choice models real-world “has-a” relationships and is a cornerstone of object composition over inheritance. Given Data / Assumptions: A class holds an instance (or reference/pointer) of another class as a member. The containing class delegates behavior to or coordinates behavior with its parts. We seek the correct OOP term for this relationship. Concept / Approach: Composition (also aggregation, depending on ownership) models has-a. For example, a Car has an Engine. This differs from inheritance (is-a), where a SportsCar is a kind of Car, and from encapsulation, which is about access control and hiding implementation details. Step-by-Step Solution: 1) Define: class Car { Engine engine; } → composition.2) Ownership: if Car controls the lifetime of Engine, that is composition (stronger than aggregation).3) Interactions: Car methods may call Engine methods to implement behavior.4) Contrast: class SportsCar : public Car {}; → inheritance (is-a), not composition. Verification / Alternative check: UML shows composition with a filled diamond and aggregation with a hollow diamond; both are “has-a,” but composition implies strong ownership. Why Other Options Are Wrong: Encapsulation: information hiding inside a class boundary.Inheritance: is-a relationship, not has-a.Abstraction: focusing on relevant features, omitting details.Polymorphism: treating different types uniformly via a common interface. Common Pitfalls: Overusing inheritance where composition would be simpler and safer; prefer composition to reduce coupling and increase flexibility. Final Answer: Composition

Question 19

Access control in C++ classes: who can access private data members or private member functions of a class? Choose the most accurate rule.

Accepted Answer

Introduction / Context: C++ uses access specifiers to protect a class’s internal representation. Private members form the strictest boundary, and understanding who is allowed to read or modify them is central to encapsulation. Given Data / Assumptions: Private members are declared with the private: label. Member functions live inside the class definition and share access rights. Friend declarations grant special access but are exceptional and explicit. Concept / Approach: All member functions of a class, regardless of whether they are declared public, protected, or private, have full access to all members of that class, including private ones. This is a class-level privilege, not per-function. Additionally, friends (functions or classes) explicitly declared as such also gain access, but the question asks for the general rule applicable to class members themselves. Step-by-Step Solution: 1) Inside class C, any member function can read/write C’s private data.2) Public/protected/private qualifiers control who can call the member, not its internal access rights.3) External non-friend functions cannot access private members.4) Therefore, “Any member function of that class” is the most accurate rule. Verification / Alternative check: Write two member functions—one public and one private—and access the same private field from both; compilation succeeds. Try the same access from a non-friend free function; compilation fails. Why Other Options Are Wrong: A/B: Overbroad—privacy would be meaningless if any/global functions could access internals.D: Misleading—private members are accessible from all members, not only public ones.E: Incomplete—friends can access, but the statement omits the class’s own members. Common Pitfalls: Confusing “who can call a member function” with “what that member function can access.” The former is controlled by the member’s own access specifier; the latter is uniformly full access within the class. Final Answer: Any member function of that class.

Question 20

In C++ access control, which keyword is used specifically to control access to a class member (i.e., to set its accessibility level within and outside the class)?

Accepted Answer

Introduction / Context: C++ provides three access specifiers to control the visibility of class members: public, protected, and private. Choosing the correct specifier is fundamental to encapsulation, information hiding, and safe inheritance hierarchies. This question asks you to identify the keyword among the options that actually serves as an access-control specifier. Given Data / Assumptions: We are discussing class member accessibility in C++. Valid access specifiers are public, protected, and private. Other listed tokens may exist in C/C++ but are not access specifiers. Concept / Approach: Access specifiers determine who can see or use class members. Inheritance also interprets them: under public inheritance, public stays public, protected stays protected, and private remains inaccessible to derived classes. Among the choices, only protected is a real access specifier. The others either have different purposes or are not standard C++ keywords for access control. Step-by-Step Solution: List true access specifiers: public, protected, private. Compare each option with this set. Identify that only “Protected” matches an access specifier. Conclude that “Protected” is the correct answer. Verification / Alternative check: Write a sample class and mark a member as protected. Attempt access from outside the class (fails) and from a derived class (succeeds), demonstrating the role of the protected specifier. Why Other Options Are Wrong: Default: no such access specifier keyword; “default access” is contextual (class vs. struct). Break: used to exit loops/switch, not for access control. Asm: non-standard/extension keyword for inline assembly, unrelated to access. Common Pitfalls: Confusing “default access” (private in class, public in struct) with an actual keyword. Assuming protected means publicly accessible—protected limits access to the class and its descendants. Final Answer: Protected

Objects and Classes Questions