Question 1

In C/C++, why might you define a struct (structure) type at global scope rather than repeating its definition inside each function that uses it?

Accepted Answer

Introduction / Context: Choosing where to place a type definition in C or C++ affects code reuse, compilation dependencies, and interface design. Structures (struct) often represent common data across multiple translation units or functions. Placing a struct definition in a common, global scope (typically a header) avoids duplication and keeps declarations consistent throughout the program. Given Data / Assumptions: The struct type is referenced by multiple functions or source files. We prefer a single authoritative definition to avoid copy-paste errors. Standard C/C++ compilation and separate header/source organization apply. Concept / Approach: Defining a struct once at global scope (commonly in a header included by all users) ensures a single source of truth. This avoids redundant definitions and linkage issues. It is not true that global definition implies the type will never change, nor is it a language requirement; it is a pragmatic design choice to improve maintainability and prevent ODR or redefinition errors across functions and files. Step-by-Step Solution: Identify that multiple functions need the same struct type.Place the struct definition in a shared header (global scope) and include it where needed.Benefit: compilation units share one consistent definition, reducing duplicate code and potential mismatches.Result: fewer lines of code and improved maintainability. Verification / Alternative check: Create two source files that use the same struct. If you maintain separate local definitions, a later change risks inconsistencies. With a single global definition in a header, both files compile against the same layout. Why Other Options Are Wrong: You will never change its definition: Not guaranteed; types evolve. It is required in C++: Untrue; the language does not require global placement. All of the above: Incorrect because the other statements are false. Common Pitfalls: Placing full definitions in multiple headers without include guards can cause redefinition errors. Use include guards or #pragma once and expose only what is necessary. Final Answer: you save many lines of code by not rewriting an identical structure definition in each function that uses it.

Question 2

In object-oriented analysis and design, the practice of focusing on essential properties while deliberately ignoring inessential details is known as what?

Accepted Answer

Introduction / Context: Software engineering emphasizes modeling complex systems by highlighting what matters and suppressing noise. Object-oriented thinking provides several core concepts: abstraction, encapsulation, inheritance, and polymorphism. Among these, abstraction is the foundational idea of representing the essence of an entity while ignoring irrelevant detail for a given context or layer of design. Given Data / Assumptions: The discussion targets conceptual modeling (classes, interfaces, responsibilities). The goal is to name the principle that filters details to essentials. Standard OO vocabulary is assumed. Concept / Approach: Abstraction creates simplified models: an interface showing what behaviors are possible without exposing internal mechanisms. This enables reasoning, reuse, and maintainability. Polymorphism is about substitutable behavior; encapsulation hides implementation behind a boundary; inheritance reuses structure/behavior. None of these alone equate to the act of ignoring inessential details; that role belongs to abstraction. Step-by-Step Solution: Identify the need to focus on key properties and behaviors.Map this need to the OO principle that presents high-level views and omits low-level detail: abstraction.Differentiate from other OO terms (polymorphism, encapsulation, inheritance) to avoid confusion.Conclude that the correct term is abstraction. Verification / Alternative check: Design patterns and UML use abstract classes and interfaces to capture behavior contracts. These abstractions allow multiple concrete implementations without cluttering the model with unnecessary specifics. Why Other Options Are Wrong: Selectiveness / summarizing: Informal words, not established OO principles. Polymorphism: Enables different implementations behind a common interface; not primarily about omitting details. None of the above: Incorrect because abstraction is standard terminology. Common Pitfalls: Confusing abstraction with encapsulation; the former removes detail in the model, the latter hides detail in the implementation. Final Answer: abstraction.

Question 3

In standard C++ file I/O, which header file must be included to use input and/or output file streams such as std::ifstream and std::ofstream?

Accepted Answer

Introduction / Context: C++ uses a standard library of stream classes for console and file I/O. While std::cin and std::cout come from one header, file streams (for reading from and writing to files) come from another. Knowing the correct header improves portability and prevents compilation errors when working with files. Given Data / Assumptions: The question refers to traditional header naming conventions seen in many textbooks (e.g., fstream.h, iostream.h). It targets file streams, not console streams. We assume basic C++ I/O knowledge. Concept / Approach: File stream classes std::ifstream, std::ofstream, and std::fstream are declared in the header historically called fstream.h (modern C++ uses without .h). Console streams std::cin and std::cout are declared in iostream.h (modern ). Therefore, for file input/output you include fstream.h in the historical naming scheme represented by the options. Step-by-Step Solution: Identify the classes to be used: ifstream/ofstream/fstream for files.Recall the corresponding header: fstream.h (or the modern ).Select the option that names the correct file-stream header for the given context.Confirm that iostream.h is for console streams, not file streams specifically. Verification / Alternative check: Create a simple program that opens a file with std::ifstream. Including fstream.h (or ) compiles, while including only iostream.h will not declare file stream types. Why Other Options Are Wrong: filestream.h / instream.h / inoutstream.h: Not standard headers. iostream.h: Console I/O; does not provide file stream class declarations alone. Common Pitfalls: Mixing legacy .h headers with modern headers. Prefer and in contemporary C++ code. Final Answer: fstream.h.

Question 4

In C++ class design, to expose a data member to outside code (so client code can access it directly), the member must be declared in which access section of the class?

Accepted Answer

Introduction / Context: C++ supports access control to encapsulate class internals. Members declared in different sections (public, private, protected) have different visibility to client code. Knowing which section grants direct access determines how you design APIs and maintain invariants. Given Data / Assumptions: Standard C++ class syntax with public:, protected:, and private: access specifiers. We consider direct access by code outside the class scope. We ignore friend declarations for this question. Concept / Approach: Members declared under the public: specifier are accessible to all code with visibility to the class. This is how interfaces are exposed. In contrast, private members are not directly accessible outside the class; protected members are accessible to the class, its friends, and derived classes. Nonstandard labels like common or exposed are not part of C++ syntax. Step-by-Step Solution: Locate the access specifiers in a class: public:, protected:, private:.Place the data member under public: if it must be directly accessible by outside code.Alternatively, prefer private: and provide getters/setters to preserve invariants, but that is beyond the question's scope.Thus, the correct section for direct exposure is public. Verification / Alternative check: Attempt to access a private member from non-member code and observe compilation failure; change it to public and the access succeeds, confirming the rule. Why Other Options Are Wrong: Common / exposed / unrestricted / user: Not valid C++ access specifiers. Common Pitfalls: Overusing public data breaks encapsulation; prefer public functions and keep data private unless a plain data structure is intended. Final Answer: public.

Question 5

In C/C++, an array name in an expression most naturally represents what concept at the language level?

Accepted Answer

Introduction / Context: Arrays are contiguous sequences of elements in memory. Understanding how an array name behaves in expressions is crucial for pointer arithmetic, parameter passing, and avoiding common errors. Many exam questions capture this by asking what an array name denotes at run time or during expression evaluation. Given Data / Assumptions: We consider standard C/C++ behavior in expressions, not declarations. Array-to-pointer decay applies except in a few contexts (e.g., sizeof, &array). The target is conceptual understanding rather than edge cases. Concept / Approach: In most expressions, the array name decays to a pointer to its first element; conceptually, it evaluates to the memory address where the array begins. Although the array itself is not a modifiable lvalue pointer, the practical takeaway is that the array name provides the base address, enabling operations like a[i] = *(a + i). Thus, among the options given, “memory address” best captures the behavior. Step-by-Step Solution: Recognize array-to-pointer decay: a (array) becomes &a[0] in expressions.Interpret &a[0] as the base memory address of the first element.Relate indexing to pointer arithmetic: a[i] equals *(a + i).Conclude the array name provides a memory address used for access. Verification / Alternative check: Print a and &a[0] with %p in C and observe identical addresses (implementation-defined formatting), confirming that the array name evaluates to its base address in expressions. Why Other Options Are Wrong: Subscript: That is the index, not the array name. Formal parameter: A role in function declarations, not what the array name denotes. Prototype: Refers to function declarations, unrelated to arrays. Common Pitfalls: Assuming the array name is a modifiable pointer variable; it is not. You cannot increment the array name itself, though you can manipulate separate pointer variables. Final Answer: memory address.

Question 6

In C++ iostream formatting, how can format flags (such as std::ios::hex, std::ios::showbase) be combined when setting multiple formatting options?

Accepted Answer

Introduction / Context: C++ iostreams use bitmask-style flags to control formatting of numbers and text (e.g., base, justification, show base/prefix). Developers often need to enable multiple options at once, so it is important to know how to combine flags correctly and idiomatically. Given Data / Assumptions: Format flags are of type std::ios::fmtflags, which is a bitmask type. We are setting flags via setf or using manipulators that rely on the same underlying bits. Standard operator semantics for bitmasks apply. Concept / Approach: Bitmask flags combine using bitwise operations. To enable several independent options simultaneously, use the bitwise OR operator (|) to set multiple bits in the mask. Logical operators (||, &&) evaluate to boolean values and are not suitable for constructing bit patterns. Bitwise AND (&) is used to test or clear bits, not to combine options to be turned on together. Step-by-Step Solution: Choose desired flags, for example std::ios::hex and std::ios::showbase.Combine them as std::ios::hex | std::ios::showbase.Apply: stream.setf(std::ios::hex | std::ios::showbase);Verify the stream prints numbers in hexadecimal with base prefix (e.g., 0x). Verification / Alternative check: Consult documentation showing std::ios::fmtflags as a bitmask type and examples using the | operator for combination. Why Other Options Are Wrong: Logical OR (||) and logical AND (&&) operate on booleans, not bitmasks. Bitwise AND (&) is used for masking/clearing/testing, not for enabling multiple flags together. Common Pitfalls: Accidentally mixing format fields that are mutually exclusive (e.g., std::ios::dec vs std::ios::hex). Use unsetf or setf with field masks to avoid conflicts. Final Answer: the bitwise OR operator (|).

Question 7

In object-oriented design, does adding a new derived class typically require fundamental changes to the existing base class interface and implementation?

Accepted Answer

Introduction / Context: One of the strengths of object-oriented design is extensibility: the ability to add new types without rewriting existing, stable code. The Open/Closed Principle states that software entities should be open for extension but closed for modification. This question asks whether introducing a derived class should force fundamental changes to the base class. Given Data / Assumptions: A well-designed base class exposes a stable public interface. Derived classes extend or customize behavior via inheritance and virtual functions. We assume no breaking ABI constraints or design flaws in the base class. Concept / Approach: If the base class is properly abstracted and encapsulates its invariants, adding a new derived class should not require altering the base's interface or internals. Instead, the derived class overrides virtual functions or adds new members. This promotes maintainability and reduces ripple effects across codebases. Step-by-Step Solution: Define a stable base interface with virtual functions where variation is expected.Implement new behavior by deriving a subclass and overriding the relevant virtuals.Confirm no fundamental changes are needed in the base if it already models the abstraction correctly.Therefore, the statement that base class changes are required is false in good designs. Verification / Alternative check: Frameworks (GUI toolkits, plugin systems) allow third parties to add derived classes without patching the base library, validating the principle. Why Other Options Are Wrong: True: Implies poor abstraction or a leaky base interface; not a design goal. Common Pitfalls: Coupling base classes to specific derived behaviors. Prefer dependency inversion and virtual interfaces to avoid editing base code for each extension. Final Answer: False.

Question 8

Language paradigms: can C++ be used both as a procedural (structured) programming language and as an object-oriented language, depending on how you design your code?

Accepted Answer

Introduction / Context: C++ is a multi-paradigm language. It supports procedural, object-oriented, generic, and even functional programming styles. Teams often adopt different subsets of the language to match project needs, from small utilities to large frameworks with rich type hierarchies. Given Data / Assumptions: C++ includes C-like constructs (functions, structs, pointers) and OO constructs (classes, inheritance, virtual functions). Templates and the Standard Template Library further enable generic programming. We assume standard-conforming C++ compilers. Concept / Approach: As a superset of C's core model with added features, C++ permits writing purely procedural programs using functions and simple data structures, or fully object-oriented designs using classes, encapsulation, and polymorphism. Many real-world codebases mix paradigms, choosing the right tool for each module. Step-by-Step Solution: Write a procedural module using free functions and plain structs.Create an OO module with classes and virtual methods for extensibility.Link both modules; the language and toolchain support the coexistence effortlessly.Therefore, the statement is true: C++ can be used procedurally and object-oriented. Verification / Alternative check: Standard libraries themselves demonstrate multiple paradigms: algorithms are generic (templates), containers are object-oriented types, and many utilities are simple procedural functions. Why Other Options Are Wrong: False / Depends on the compiler: Paradigm support is defined by the language, not a specific compiler. Common Pitfalls: Dogmatically restricting code to a single paradigm can reduce clarity. Use the paradigm that best fits the problem while maintaining consistency and readability. Final Answer: True.

Question 9

Generic container classes: if container classes are carefully constructed, these tools are available to work with data structures that are not what (i.e., they do not need to be tied to a single concrete type)?

Accepted Answer

Introduction / Context: Modern C++ emphasizes reusable, generic containers (such as std::vector, std::list, std::map). Properly designed container classes separate algorithms and storage from specific element types, enabling code reuse across many domains with minimal duplication. This question probes the idea that well-designed containers are not tied to a single data type. Given Data / Assumptions: Containers are templated or otherwise generic. The same container interface can store many element types. We are discussing flexibility and generality, not access control or validity. Concept / Approach: When containers are generic, they operate on parameterized types. This means the tools (APIs, algorithms) work with structures that are not type-specific. The container code does not care whether it holds int, std::string, or a user-defined class, as long as required operations are available. This decoupling yields strong reuse and composability. Step-by-Step Solution: Design containers with type parameters (e.g., template).Ensure operations are written in terms of T's interface, not a fixed concrete type.Instantiate containers with multiple T types to verify generality.Conclude that such containers are not type-specific, enabling broad applicability. Verification / Alternative check: std::vector and std::list accept any T meeting requirements. Algorithms like std::sort operate on ranges independent of element type, provided comparator semantics are defined. Why Other Options Are Wrong: Valid without container classes: Validity is unrelated to genericity. Programmer-defined: Containers often do store programmer-defined types. Public: Access specifier has no bearing on type independence. Common Pitfalls: Designing containers with assumptions about specific types (e.g., relying on particular fields) harms reuse. Prefer type constraints expressed via concepts or documented requirements. Final Answer: type-specific.

Question 10

In C++ object-oriented programming, what do we call the special member function that is invoked automatically each time an object's lifetime ends (for example, when it goes out of scope or is deleted)?

Accepted Answer

Introduction / Context: Resource management in C++ relies heavily on the RAII (Resource Acquisition Is Initialization) idiom. Central to RAII is the special member function that runs automatically when an object's lifetime ends. Knowing its name and role is essential for writing safe, leak-free code that properly closes files, releases memory, and unlocks mutexes. Given Data / Assumptions: An object's lifetime ends when it goes out of scope, is explicitly deleted, or when program termination destroys static objects. C++ provides special member functions with fixed names and rules: constructors and destructors. We focus on the function that executes at the end of an object's life. Concept / Approach: The destructor has the class name prefixed with a tilde (~ClassName). It is called automatically to perform cleanup. Constructors initialize objects; destructors finalize and release resources. Destructors can be user-defined or compiler-generated; they may be virtual in polymorphic base classes to ensure correct dynamic dispatch on deletion. Step-by-Step Solution: Identify the life-cycle event: object destruction (end of lifetime).Map the event to the C++ special member function responsible: the destructor.Confirm naming convention: ~ClassName(), no return type, no parameters, optionally virtual.Conclude the correct term is 'destructor' rather than any colloquial synonym. Verification / Alternative check: Consider std::unique_ptr managing heap memory: when the unique_ptr object is destroyed, its destructor automatically deletes the owned pointer, proving the cleanup role. Why Other Options Are Wrong: constructor: Runs at object creation, not destruction. destroyer / terminator: Informal, non-standard terms; not C++ keywords or required names. None of the above: Incorrect because ”destructor” is the precise term. Common Pitfalls: Forgetting to declare a virtual destructor in a polymorphic base class, leading to undefined behavior when deleting through a base pointer. Performing complex logic or throwing exceptions from destructors; exceptions escaping a destructor during stack unwinding call std::terminate. Final Answer: destructor

Question 11

In C++ parameter passing, when you pass a variable by ________, only the current contents (a copy of the value) are sent to the receiving function.

Accepted Answer

Introduction / Context: Understanding how function arguments are passed is vital to predict whether a callee can modify a caller's data. C++ supports three common styles: pass-by-value, pass-by-reference, and pass-by-pointer. This question focuses on the style where only the data's current content is copied into the function, leaving the caller's original variable unchanged. Given Data / Assumptions: The function receives either a copy of the value, a reference (alias), or a pointer (address). No special qualifiers like const are required to understand the basic distinction. Side effects on parameters are a key concern in API design and debugging. Concept / Approach: By value: The callee gets its own copy; modifications affect only that copy. By reference: The callee receives an alias to the original, allowing direct modification. By pointer: The callee receives an address and can modify the pointed-to object via dereferencing. Step-by-Step Solution: Identify which method supplies only the data's contents, not its identity/location → pass-by-value.Confirm that changes in the callee do not propagate back to the caller's variable.Hence the blank is correctly filled by 'by value'. Verification / Alternative check: Example: void inc(int x){ x++; } int a=5; inc(a); a remains 5 after the call because x is a copy. Why Other Options Are Wrong: by reference: Passes an alias; the callee can change the caller's variable. globally / locally: Not parameter-passing mechanisms; they describe scope. None of the above: Incorrect because ”by value” is the standard term. Common Pitfalls: Confusing pass-by-value with returning values by copy; these are separate operations. Assuming objects are always cheap to copy; use references or move semantics when appropriate. Final Answer: by value

Question 12

In C++, when the compiler cannot distinguish between two overloaded constructors (or functions) based on their parameter lists, the overload set is said to be what?

Accepted Answer

Introduction / Context: Function and constructor overloading lets you reuse names for different parameter lists. However, if a call could match more than one candidate with no clear best conversion sequence, the compiler cannot pick uniquely. Recognizing the term for this situation helps diagnose compile-time errors and fix API design issues. Given Data / Assumptions: Multiple overloads share the same name. A call site provides arguments whose types/conversions make more than one overload viable. No single overload is strictly better according to C++ overload resolution rules. Concept / Approach: When no unique best match exists, overload resolution fails with an ambiguous call. Ambiguity can arise from implicit conversions, default arguments, or templated overloads. Eliminating ambiguity involves making the call explicit (casts), removing conflicting overloads, or adding more specific overloads. Step-by-Step Solution: Identify the scenario: two or more viable constructors match equally well.Apply the rule: if no single best conversion sequence exists, the call is ambiguous.Therefore, the correct term is ”ambiguous”. Verification / Alternative check: Try compiling code where int converts to both long and double with similar ranks; compilers emit an ”ambiguous” overload resolution error. Why Other Options Are Wrong: overloaded: Describes the existence of multiple functions, not the failure mode. destructed / dubious: Not standard terminology in this context. None of the above: Incorrect because ”ambiguous” is the precise diagnostic term. Common Pitfalls: Relying on implicit conversions that create ambiguity; prefer explicit interfaces. Overusing default parameters that collide with other overloads. Final Answer: ambiguous

Question 13

C++ class templates: if you instantiate a class template once with int and again with double, how do you call the same member function on those different instantiations?

Accepted Answer

Introduction / Context: Templates enable writing type-independent code. When you instantiate a class template with different type arguments (e.g., MyBox and MyBox), you get distinct types with the same interface. Understanding how to invoke their member functions clarifies generic programming workflows in C++. Given Data / Assumptions: We have a class template with the same set of member functions for each instantiation. Two instantiations are created: one with int and one with double. The question concerns the procedure to call a member function on each object. Concept / Approach: Each instantiation is a separate type (e.g., Box vs Box), but the syntax to call members is identical: object.member(args). No language rule requires prefixing calls with the type name; overload resolution and templates handle this automatically. Availability of a function on one instantiation does not remove it from another; interfaces are replicated per instantiation, subject to constraints. Step-by-Step Solution: Create objects: Box bi; Box bd;.Invoke: bi.push(1); bd.push(1.0); The call syntax is the same.Therefore, there is no difference in the procedure to call a member function across instantiations. Verification / Alternative check: Examine the standard library: std::vector and std::vector use identical call syntax for size(), push_back(), etc. Why Other Options Are Wrong: Prefix words int/double: Not part of call syntax. Becomes unavailable: False; instantiations coexist independently. Cannot perform: Templates are designed for exactly this usage. Common Pitfalls: Assuming templates erase types at compile time like some languages; in C++, types remain distinct. Forgetting that constraints (e.g., operations required on T) may limit certain instantiations. Final Answer: There is no difference in the procedure to call a member function

Question 14

In software design, which form of coupling between modules is considered best (i.e., most desirable) for maintainability and reuse?

Accepted Answer

Introduction / Context: Coupling measures how strongly two modules depend on each other. Lower (looser) coupling generally leads to better testability, easier maintenance, and greater reuse. This concept underpins modular architecture, microservices, and clean interfaces across programming languages and system designs. Given Data / Assumptions: We seek the most desirable coupling style for long-term software health. Modules communicate through well-defined interfaces with minimal knowledge of each other. High cohesion within modules complements loose coupling between modules. Concept / Approach: Loose coupling minimizes interdependencies; changes in one module rarely force changes in others. Tight coupling increases ripple effects and hampers independent deployment or testing. Terms like ”complete” or ”free” are not standard classifications in coupling taxonomy. Step-by-Step Solution: Identify the goal: reduce dependencies while preserving clear contracts.Relate to practices: interfaces, dependency injection, message passing, and stable APIs enable loose coupling.Conclude that ”loose” coupling is the best form among the options. Verification / Alternative check: Industry principles (e.g., SOLID, hexagonal architecture) emphasize loose coupling for scalable, resilient systems. Why Other Options Are Wrong: tight: Leads to fragile code and harder refactoring. complete / free: Not standard categories; ambiguous. None of the above: Incorrect because ”loose” is the recognized best practice. Common Pitfalls: Mistaking low coupling for no communication; modules still need clear contracts. Confusing coupling with cohesion; they address different design axes. Final Answer: loose

Question 15

In modular programming terminology, sending a copy of data to a program module (so the callee receives only the current value) is called what?

Accepted Answer

Introduction / Context: When functions or modules interact, they often exchange data via parameters. The way those parameters are transmitted determines whether the callee can alter the caller's original variable. This question asks for the term describing the practice of sending only a copy of the data to the callee. Given Data / Assumptions: The callee should not modify the caller's original variable through the parameter. Common parameter-passing modes include by value, by reference, and by pointer. We focus on the copy semantics. Concept / Approach: Passing a value (pass-by-value) duplicates the data for the function's use. Making a reference creates an alias, enabling mutation of the original. Recursion is a control-flow pattern, not a data-passing mode. Step-by-Step Solution: Identify the desired behavior: callee gets only a copy of the data.Associate this with the term: passing a value.Therefore, the correct answer is ”passing a value”. Verification / Alternative check: Example: void f(int x){ x = 42; } int a=10; f(a); After the call, a remains 10 because x is a copy. Why Other Options Are Wrong: making a reference: Allows in-place modification of the caller's variable. recursion: Unrelated concept. setting a condition: Refers to control flow, not parameter semantics. None of the above: Incorrect because passing a value is the standard term. Common Pitfalls: Passing large objects by value can be expensive; consider const references or moves. Believing pass-by-value prevents all side effects; global state and pointers inside objects can still be modified. Final Answer: passing a value

Question 16

C/C++ literals: which of the following characters are valid inside a numeric literal token (as part of the literal itself) in standard C++?

Accepted Answer

Introduction / Context: Numeric literals in C and C++ follow strict lexical rules. Only certain characters are permitted within the token that represents an integer or floating-point literal. Understanding which characters are allowed prevents hard-to-spot compile errors and ensures code portability across compilers and locales. Given Data / Assumptions: We refer to the characters inside a numeric literal, not separators in source formatting. Standard C++ permits digits, decimal points, exponent markers (e/E, p/P for hex floats), sign characters in exponents, base prefixes (0x, 0b in C++14/20 compilers), digit separators ('') and type suffixes (u, l, f, etc.). We evaluate specific candidates: comma, dollar sign, percent sign, and space. Concept / Approach: Commas and spaces are token separators in the grammar, not part of numeric literals. Dollar ($) and percent (%) are ordinary punctuation/operators; they are not valid within numeric literals. Therefore, none of the listed characters are valid inside a numeric literal token. Step-by-Step Solution: Check each character against the lexical set for numeric literals.Comma → not allowed; Space → not allowed; $ and % → not allowed.Conclude: the correct option is ”None of the above”. Verification / Alternative check: Try compiling 1,000 or 1 000 or $100 or 50% as literals: each fails or parses differently than intended. Use 1000, 1'000 (C++14 digit separator), or 0.5 for 50% semantics. Why Other Options Are Wrong: a comma / a space: Break tokens into multiple tokens. a dollar sign ($) / a percent sign (%): Not part of literal syntax; % is the modulo operator. Common Pitfalls: Copying numbers from documents with thousands separators; remove commas or use the digit separator ''. Confusing formatting symbols (%, $) with literal syntax; those belong in strings or comments. Final Answer: None of the above

Question 17

C++ string literals: select the single option that is an invalid string constant (i.e., not a valid string literal) while others are valid strings.

Accepted Answer

Introduction / Context: In C and C++, a string constant (string literal) is a sequence of characters enclosed in double quotes. It produces an array of characters terminated by a null character. This question asks you to identify which presented token is not a valid string literal, ensuring clarity about the difference between character and string constants. Given Data / Assumptions: Valid string literals use double quotes, for example, "text". Character literals use single quotes and represent a single code unit (e.g., 'A'). Options include both quoted forms and content with digits and spaces. Concept / Approach: Anything in double quotes is a string literal, regardless of its textual content (digits, words, spaces). Single quotes denote a character literal; more than one character between single quotes is not a string literal and is invalid as a character literal in strictly conforming code (multi-character literals are implementation-defined integer constants, not strings). Therefore, an entry surrounded by single quotes containing multiple characters is not a valid string constant. Step-by-Step Solution: Inspect option A: "Hello, world!" → valid string literal.Option B: "7.15 pm" → valid string literal with digits, dot, and space.Option C: 'multi char' → uses single quotes and multiple characters → not a string literal; not a standard single character literal either.Option D: "i like e" → valid string literal.Option E: "1234e12" → still a string literal; numeric-like content does not change the type. Verification / Alternative check: Compile-time types: options A, B, D, E have type const char[N]; option C would be an implementation-defined multi-character literal of type int (not a string), or rejected under strict rules, hence invalid as a string constant. Why Other Options Are Wrong: "Hello, world!", "7.15 pm", "i like e", "1234e12": All are proper string literals because they use double quotes. Common Pitfalls: Confusing the lexical form (single vs double quotes) and assuming content determines type. Misusing single quotes for words; only double quotes produce strings. Final Answer: 'multi char'

Question 18

C++ One Definition Rule (ODR): can you define the same non-inline function more than once in the same program (across translation units)?

Accepted Answer

Introduction / Context: The One Definition Rule (ODR) in C++ governs how many definitions of an entity (functions, objects, types) may appear in a program. Violating the ODR often leads to linker errors or undefined behavior. This question asks whether you may define the same (non-inline) function more than once in the same program. Given Data / Assumptions: We are discussing ordinary (non-inline, non-template, non-special) functions. Multiple translation units are linked together to form one program. Header inclusion may replicate declarations, but not definitions, unless special rules apply. Concept / Approach: Under the ODR, each function must have exactly one definition in the entire program (inline functions and templates have special rules). Multiple identical definitions of a non-inline function across translation units violate the ODR. Correct practice: place the function definition in a single .cpp file and declare it in headers with extern linkage as needed. Step-by-Step Solution: Identify entity: non-inline function.Apply ODR: only one definition is permitted in the program.Therefore, the correct answer states that multiple definitions are not allowed. Verification / Alternative check: Creating two .cpp files each defining the same function foo() leads to ”multiple definition” linker errors on most toolchains. Why Other Options Are Wrong: Identical definitions / separate includes / repeated includes: All still produce multiple definitions unless the function is marked inline or is a template defined consistently, which is not the case stated. None of the above: Incorrect because the ODR prohibition applies. Common Pitfalls: Placing non-inline function definitions in headers and including them in multiple translation units. Confusing declarations (allowed in many places) with definitions (must be unique). Final Answer: C++ does not allow you to define the same functions more than once in the same program

Question 19

Overloading in C++: overloaded functions are required to meet which condition?

Accepted Answer

Introduction / Context: Function overloading lets multiple functions share the same name while differing in parameter types or counts. Many myths surround what must match among overloads. This question targets those misconceptions by asking what overloaded functions are actually required to have in common. Given Data / Assumptions: We consider free functions or member functions with the same name in the same scope. Overloads must be distinguished by their parameter lists (types/order/arity). Return type alone cannot distinguish overloads during a call. Concept / Approach: There is no requirement that return types match. There is no requirement that the number of parameters match; arity may differ. Semantics (”perform the same basic function”) are conventional, not a language rule. The only strict requirement is that each overload's parameter list is different enough for overload resolution. Step-by-Step Solution: Evaluate options: same return type? not required.Same number of parameters? not required; both arity and types may vary.Perform same function? not enforced by the compiler; only name/parameters matter.Therefore, the correct choice is ”None of the above”. Verification / Alternative check: Examples from the standard library: std::abs has many overloads for int, long, long long, float, double, etc., with different parameter types and same name; semantics are similar by convention, not by rule. Why Other Options Are Wrong: same return type: False; two overloads may return different types (though not advisable for ambiguity). same number of parameters: False; overloading by arity is common. perform the same basic functions: Not a language requirement. All of the above: Incorrect for the reasons above. Common Pitfalls: Trying to rely on return type alone to resolve calls; the compiler cannot choose an overload based only on return type. Creating ambiguous overload sets via excessive implicit conversions. Final Answer: None of the above

Question 20

In C++ input and output using iostreams, which statement correctly allows the user to enter (read) a value from the keyboard into the variable named currentPay?

Accepted Answer

Introduction / Context: User interaction in C++ commonly relies on the standard input and output streams provided by the iostream library. The statement used must correctly apply the stream extraction or insertion operators to move data between the keyboard buffer, the program, and the console. This question tests recognition of the proper operator direction for reading a value into a variable from the keyboard. Given Data / Assumptions: The program includes the iostream header and uses the std::cin and std::cout streams. Variable currentPay has been declared with a suitable numeric type (for example, int, double, or long double). Default locale and formatting are assumed, and error handling is not explicitly shown. Concept / Approach: In C++, stream extraction with the operator >> pulls data from an input stream into a program variable. Conversely, stream insertion with the operator << sends data from a program expression to an output stream. For keyboard input, std::cin represents the standard input stream, typically connected to the console. Therefore the correct form to read a value is cin >> variable;. Using cout with >> or cin with << is a direction and stream mismatch and will not compile as intended. Step-by-Step Solution: Confirm the goal: move data from the keyboard into currentPay.Identify the correct stream: std::cin for input.Choose the correct operator: >> is the extraction operator for input streams.Write the statement: cin >> currentPay; which extracts the next token and stores it in currentPay. Verification / Alternative check: A simple test program that prints a prompt, executes cin >> currentPay;, and then echoes the value with cout << currentPay; will demonstrate correct input and output flow. If the operators or streams are reversed, the code will fail to compile or will not behave correctly. Why Other Options Are Wrong: cin << currentPay; uses the insertion operator with an input stream, which is incorrect. cout << currentPay; outputs a value; it does not read input. cout >> currentPay; attempts to extract from an output stream, which is invalid. None of the above is wrong because cin >> currentPay; is correct. Common Pitfalls: Forgetting that >> is extraction and << is insertion, or confusing cout and cin. Also, not checking stream state after input can cause subtle bugs if the user enters data of the wrong type. Final Answer: cin >> currentPay;.

Object Oriented Programming Using C++ Questions