Question 1

C++ return by reference: evaluate the two claims  We can return a global variable by reference. 2) We cannot return a local variable by reference.

Accepted Answer

Introduction / Context: Returning by reference can avoid copies and enable idioms like chaining assignments. However, a returned reference must remain valid after the function returns. Understanding object lifetime is essential to decide which references are safe to return from a function. Given Data / Assumptions: Global (or static storage duration) variables outlive function calls. Local automatic variables are destroyed when a function returns. We discuss references to non-temporary objects. Concept / Approach: A function may safely return a reference to an object that continues to exist after the function ends, such as a global or static variable, because the reference remains bound to a live object. Conversely, a reference to a local automatic variable becomes dangling as soon as the function returns, leading to undefined behavior. Therefore, returning a global by reference is acceptable, while returning a local by reference is not. Step-by-Step Solution: Evaluate claim 1: global variables have static storage duration ⇒ reference remains valid ⇒ correct. Evaluate claim 2: local automatic variables are destroyed at function end ⇒ reference would dangle ⇒ correct. Therefore, both statements are correct. Select “Both 1 and 2 are correct.” Verification / Alternative check: Returning a reference to a static local is also permissible because it persists across calls. Compilers with warnings enabled will often flag returning a reference to a local automatic variable as a dangerous error pattern. Why Other Options Are Wrong: Only 1 or only 2: ignores the validity of the other correct statement. Both incorrect: contradicts standard lifetime rules. Common Pitfalls: Accidentally returning references to temporaries (e.g., the result of an expression), which also dangle. Misunderstanding that returning by value is often safer and optimized via copy elision or move semantics. Final Answer: Both 1 and 2 are correct.

Question 2

C++ references: evaluate the two claims  Once a variable and a reference are linked, they remain tied. 2) After declaring one reference to a variable, another reference to the same variable is not allowed.

Accepted Answer

Introduction / Context: References in C++ act as aliases for existing objects. They are widely used in function parameters, operator overloads, and APIs to avoid copying. This question asks you to judge two statements about reference binding and whether multiple references can refer to the same object. Given Data / Assumptions: A reference must be initialized to bind to an object. Once initialized, a reference cannot be reseated to a different object. There is no language limit that allows only one reference per object. Concept / Approach: Statement 1 is true: binding is permanent for a reference. Statement 2 is false: any number of references may be created to the same underlying object. The language does not restrict multiple references; in fact, functions often return or accept references simultaneously, all aliasing the same variable. Therefore, the correct choice is “Only 1 is correct.” Step-by-Step Solution: Check 1: int x; int& r = x; — r cannot later be bound to y ⇒ true. Check 2: int& r2 = x; — compiles and is valid; multiple references may alias x ⇒ false claim. Thus, exactly statement 1 is correct. Choose “Only 1 is correct.” Verification / Alternative check: Demonstrate with code: create r1 and r2 both referring to x; modifications via either alias are visible via the other, confirming permissibility and aliasing behavior. No rule forbids additional references. Why Other Options Are Wrong: Only 2: incorrect because you can create multiple references to one variable. Both correct: wrong due to statement 2. Both incorrect: wrong because statement 1 is right. Common Pitfalls: Confusing references with unique ownership concepts (which are modeled by smart pointers, not references). Assuming references imply thread safety or uniqueness; they do not. Final Answer: Only 1 is correct.

Question 3

In C++ language fundamentals, a reference behaves most like which of the following? Choose the closest conceptual analogy used in programming pedagogy to describe a reference (while remembering that a reference is an alias, not a separate object).

Accepted Answer

Introduction / Context: A C++ reference is frequently explained to beginners by comparing it to a pointer, because both allow indirect access to an object. This question asks for the closest analogy among the given options, with the understanding that a reference is an alias to an existing object rather than a standalone entity. Given Data / Assumptions: C++ references must be bound (initialized) to an existing object. After binding, a reference cannot be reseated to refer to a different object. Syntactically, using a reference does not require explicit dereferencing. Concept / Approach: The most common teaching analogy is that a reference behaves like an automatically dereferenced, non-null, constant pointer to an object. This captures the indirect access idea while reminding us that references are safer: they cannot be null by default (barring abuse), and they cannot be reseated. Step-by-Step Solution: 1) Identify what a reference provides: aliasing semantics for an existing object.2) Compare to options: structure, macro, enum are unrelated to indirection.3) Choose 'Pointer' as the closest analogy, noting the critical differences.4) Summarize: a reference acts like a safe, always-dereferenced handle to an object. Verification / Alternative check: Consider passing an int by reference to a function. Inside the function, assigning to the reference changes the original int, similar to using a pointer parameter and dereferencing it, but with cleaner syntax. Why Other Options Are Wrong: Structure: aggregates members; not an indirection mechanism.Macro: a preprocessor substitution tool; not runtime indirection.Enum: defines named integral constants; no aliasing behavior. Common Pitfalls: Thinking a reference is identical to a pointer. It is not: a reference must be initialized, cannot be reseated, and generally does not require * to access the referent. Also, taking the address of a reference gives the address of the underlying object. Final Answer: Pointer

Question 4

In C++, which statement about references is correct? Select the rule that always applies to reference initialization and binding.

Accepted Answer

Introduction / Context: References in C++ are aliases to existing objects. Unlike pointers, a reference must be bound to an object at the point of its declaration. This question focuses on the unconditional requirement for reference initialization. Given Data / Assumptions: A reference binds to an existing, valid object. Environment: standard C++ (no compiler extensions). Local scope or global scope does not change the fundamental rule. Concept / Approach: The language requires that a reference be initialized as part of its declaration. This is independent of whether the reference appears in a function body, as a global/static, or as a class data member (members can be initialized in constructors’ initializer lists). There is no 'null reference' by default and no way to leave a reference unbound. Step-by-Step Solution: 1) Evaluate scope-based claims (inside vs outside functions): these do not change the rule.2) Recognize the universal constraint: binding must occur at declaration.3) The only answer that reflects this universal constraint is 'A reference must always be initialized.'4) Therefore select option C. Verification / Alternative check: Attempt to compile 'int &r;' without an initializer. The compiler will emit an error requiring initialization. For class members, use constructor initializer lists: 'MyType(int &x) : ref(x) {}'. Why Other Options Are Wrong: 'Inside functions' or 'outside all functions': scope is irrelevant to the rule.'Both A and C': A is not universally true; the correct universal rule is C alone. Common Pitfalls: Confusing references with pointers and expecting to assign a target later. Rebinding is not allowed; if reseating is needed, use pointers or std::reference_wrapper for certain patterns. Final Answer: A reference must always be initialized.

Question 5

Accessing through a C++ reference: which statement is correct? Choose how you read or write the referred value via a reference.

Accepted Answer

Introduction / Context: Unlike pointers, C++ references are used exactly like the underlying object. This question checks whether you know that references do not require the * operator to access the value they alias. Given Data / Assumptions: We have a valid reference bound to an object. No pointer types are involved in the syntax under discussion. Standard expression semantics apply. Concept / Approach: A reference is an alias. Using the reference name accesses the referred object directly. You do not write *r to read or write; you simply use r. In contrast, a pointer p requires p to access the pointee. This syntactic difference is a primary reason references often lead to cleaner APIs. Step-by-Step Solution: 1) Bind reference: 'int a = 10; int &r = a;'2) Access via reference: 'r = 20;' sets a = 20 without ''.3) Compare to pointer: 'int *p = &a; *p = 30;' requires explicit dereference.4) Conclude: no explicit dereference needed for references. Verification / Alternative check: Compile and run a simple program that assigns through a reference; observe the underlying object changes. Replace the reference with a pointer to see the syntactic difference. Why Other Options Are Wrong: Must dereference / double dereference: incorrect for references; they are not pointers-to-pointers.'Depends on the type': for references, access is uniform; the alias behaves like the underlying object. Common Pitfalls: Thinking that references support reseating or null semantics. They do not by default. If you need optional binding, use pointers or std::optional>. Final Answer: A referenced does not need to be de-referenced to access a value.

Question 6

Returning a reference from a function in C++: which reasons are valid?  The returned information is a large object, so returning a reference is more efficient than copying.  The function's type must be an R-value.

Accepted Answer

Introduction / Context: Functions in C++ may return by value, by lvalue reference, or by rvalue reference. Choosing to return a reference can avoid copying large objects or provide direct access to an existing object. This question evaluates two proposed reasons for returning a reference. Given Data / Assumptions: Returning a reference avoids copying and refers to an existing, still-valid object. R-value refers to a temporary/prvalue, not a requirement for function return types. Lifetime and aliasing safety must be considered. Concept / Approach: Reason 1 is valid: returning a reference to an existing large object can be more efficient than copying (provided the referent outlives the use). Reason 2 is incorrect: a function's return type need not be an R-value; you explicitly choose a return type such as T, T&, or T&&. There is no rule that 'the type must be an R-value'. Step-by-Step Solution: 1) Evaluate 1: Large object → return T& when safe → avoids copying.2) Evaluate 2: Misconception; functions are free to return lvalues or rvalues depending on declared type.3) Conclude only statement 1 is correct.4) Choose 'Only 1 is correct.' Verification / Alternative check: Inspect common APIs: 'operator[]' on std::vector returns T& for lvalue containers (to allow assignment). That leverages references for efficiency and semantics. Why Other Options Are Wrong: Only 2 / Both 1 and 2 / Both incorrect: each incorrectly treats R-value as a mandate or denies the efficiency benefit of references. Common Pitfalls: Returning a reference to a local variable (dangling). Ensure the referenced object's lifetime exceeds the caller's use. Final Answer: Only 1 is correct.

Question 7

C++ reference reseating: which statement is correct? Choose the rule that governs whether a reference can later refer to another variable.

Accepted Answer

Introduction / Context: One of the most important properties of C++ references is that, after initialization, they are bound permanently to the same object. This question checks your understanding of that non-reseating rule. Given Data / Assumptions: We are discussing lvalue references such as 'int &r = x;' Initialization happens at the point of declaration. No later reassignment syntax exists for references. Concept / Approach: A reference is an alias. After binding, it always denotes the same object. Assigning to the reference assigns to the referent, not to the binding. By contrast, pointers can be reseated to point elsewhere; references cannot. Also, '&&' denotes rvalue references in declarations (type&&), not the general indicator that 'this entity is a reference' in all contexts. Step-by-Step Solution: 1) Bind: 'int a; int &r = a;'2) Attempt 'r = b;' does not reseat; it assigns a = b.3) There is no syntax to make r refer to a different object later.4) Therefore, option C states the correct rule. Verification / Alternative check: Compile a test where you try to 'rebind' the reference via assignment. Observe it simply writes into the original variable. Why Other Options Are Wrong: A: contradicts the language rule; only pointers can be reseated.B: '&&' is the syntax for rvalue references in type declarations, not a general indicator as written.D: references must be initialized at declaration; you cannot leave them uninitialized and fill later. Common Pitfalls: Confusing assigning through a reference (affects the referent) with changing what the reference refers to (impossible). Final Answer: Once a reference variable has been defined to refer to a particular variable it cannot refer to any other variable.

Question 8

References in declarations: which statements are correct?  An array of references is acceptable.  We can create a reference to a reference.

Accepted Answer

Introduction / Context: C++ references have deliberate restrictions that simplify usage and avoid certain categories of errors. This question tests familiarity with two such restrictions: arrays of references and references to references. Given Data / Assumptions: We are discussing direct declarations, not template reference collapsing rules. Standard C++ syntax and type system apply. No compiler extensions are assumed. Concept / Approach: (1) Arrays of references are ill-formed because references are not objects; they are aliases and must be bound individually. You can have an array of pointers or an array of std::reference_wrapper objects, but not an array of T&. (2) A 'reference to a reference' is not a distinct type in ordinary declarations; attempts to declare T&& & collapse during template deduction to a reference, but direct 'reference of reference' is ill-formed. Reference collapsing rules apply in templates and type aliases, not as a way to form nested reference types. Step-by-Step Solution: 1) Try declaring 'int &arr[3];' → compilation error.2) Try declaring 'int & &rr = ...;' → ill-formed in direct code.3) Use alternatives: pointers or std::reference_wrapper for arrays; rely on reference collapsing only in template contexts.4) Conclude both statements are incorrect. Verification / Alternative check: Compile minimal examples with common compilers; both constructs fail outside of template deduction scenarios, confirming the rule. Why Other Options Are Wrong: Any option asserting 1 or 2 is correct contradicts standard C++ rules. Common Pitfalls: Confusing reference collapsing (e.g., T& & → T&) with the notion that references to references are allowed generally. They are not; collapses are a template metaprogramming rule. Final Answer: Both 1 and 2 are incorrect.

Question 9

Which statement about C++ references is correct? Select the fact that accurately reflects how references behave in real code.

Accepted Answer

Introduction / Context: References are aliases. Nothing prevents multiple distinct references from aliasing the same object. This question seeks the statement that correctly captures legal and common reference usage. Given Data / Assumptions: Standard C++ reference rules apply: must initialize at declaration; cannot reseat. Syntax: & is used for declaring references. Scope (class vs function) does not change the initialization rule. Concept / Approach: Any number of references can bind to the same object. They are simply additional names (aliases) for that object. Declaring a reference uses the & symbol in the type. Initialization is required regardless of being inside a class or function; class data members are typically initialized via constructors. Step-by-Step Solution: 1) Consider 'int x; int &r1 = x; int &r2 = x;' → legal; two references alias x.2) Rule out '' syntax: that declares pointers, not references.3) Rule out reseating: references cannot later refer to another object.4) Rule out 'within classes': initialization is always required, not only within classes. Verification / Alternative check: Compile a small sample with multiple references to one variable and verify that modifying through any reference changes the same underlying object. Why Other Options Are Wrong: ' operator': that is pointer declaration syntax.Reseating claim: contradicts the binding rule.'Must be initialized within classes': scope does not create a special exception; it is always required. Common Pitfalls: Assuming references are unique handles. They are not; you can create many references to the same object, which can complicate alias analysis. Final Answer: A variable can have multiple references.

Question 10

Storage and placement: where is a C++ reference stored? Choose the most appropriate statement from the given options.

Accepted Answer

Introduction / Context: The standard treats references as aliases, not objects with mandatory storage. However, at the implementation level, where and how a reference is represented depends on the context (local variable, data member, temporary binding). This question uses common multiple-choice phrasing and expects the most plausible placement among the offered options. Given Data / Assumptions: Choices are limited to simplistic storage locations. We consider a typical local (automatic) reference variable. Practical implementations may realize references similarly to pointers under the hood. Concept / Approach: Conceptually, a reference is just another name; it does not have independent storage requirements in the abstract machine. Practically, a local reference binding (e.g., 'int &r = x;') is represented in the function's activation record along with other locals—i.e., on the stack—on conventional architectures. If a reference is a data member, its representation is within the object's storage. Among the provided options, 'stack' most closely matches typical local usage. Step-by-Step Solution: 1) Identify the scenario implied by MCQs: local references.2) Map to typical storage: locals live on the stack frame.3) Note that references can be optimized away; still, 'stack' is the best of the given choices.4) Select 'A reference is stored on stack.' Verification / Alternative check: Inspect compiler output with optimizations off; you may observe a slot allocated for the reference binding in the stack frame. With optimization, the reference may be elided entirely. Why Other Options Are Wrong: Heap: used for dynamic allocation via new; references are not allocated with new by themselves.Queue / Binary tree: data structures, not storage segments. Common Pitfalls: Believing references always occupy storage or never do. The standard allows elision; compilers choose representations. For MCQ purposes, 'stack' fits ordinary local references. Final Answer: A reference is stored on stack.

Question 11

Which statement about C++ references is correct? Pick the most accurate description from the options provided.

Accepted Answer

Introduction / Context: In teaching, a common mental model is to think of a reference as if it were a constant pointer that is automatically dereferenced. While not literally true in the type system, this analogy helps explain binding and non-reseating behavior. This question asks you to choose the best fit among imperfect options. Given Data / Assumptions: References must be initialized and cannot be reseated. They provide aliasing semantics and implicit dereference. Other options propose constructs that are ill-formed (arrays of references, references to references). Concept / Approach: Among the answers, 'A reference is a constant pointer' is the closest analogy: like a const pointer to T (T *const), a reference always refers to the same object and does not require explicit dereference to access it. Options C and D are false in standard C++; option B contradicts the commonly accepted analogy and the semantics of binding. Step-by-Step Solution: 1) Eliminate C and D based on language rules (both constructs are disallowed directly).2) Between A and B, choose the analogy that reflects non-reseating and automatic access.3) Select A as the best descriptive (didactic) fit.4) Clarify that this is an analogy, not strict type equivalence. Verification / Alternative check: Compare behavior: assigning through a reference changes the referent, akin to assigning through a const pointer to the same object. Why Other Options Are Wrong: B: rejects the useful and widely taught analogy.C: arrays of references are ill-formed.D: direct references to references are ill-formed; only template reference collapsing exists. Common Pitfalls: Taking the analogy as literal identity. In the type system, references are not pointers and have distinct rules (e.g., cannot be null by default). Final Answer: A reference is a constant pointer.

Question 12

C++ syntax check: a reference is declared using which symbol? Select the correct token used in declarations.

Accepted Answer

Introduction / Context: Understanding the basic declaration syntax of references is foundational in C++. This question asks which symbol denotes a reference in a type declaration. Given Data / Assumptions: We are declaring lvalue references (e.g., int &r). Standard C++ tokens apply. We distinguish between logical operators and reference declarators. Concept / Approach: The ampersand '&' in a declaration forms an lvalue reference type: 'T &'. Although '&&' denotes an rvalue reference in type syntax (since C++11), the plain lvalue reference uses a single '&'. The other tokens are logical OR and logical NOT operators, which are unrelated to declaring reference types. Step-by-Step Solution: 1) Recall examples: 'int &r = x;' binds r to x.2) Distinguish from rvalue references: 'int &&rr = 5;' uses '&&'.3) Recognize that '||' and '!' are not used in type declarations.4) Choose '&' for lvalue references in general declarations. Verification / Alternative check: Compile minimal code declaring both lvalue and rvalue references to see the required tokens. Why Other Options Are Wrong: '&&': rvalue reference (a different category), not the generic reference symbol asked by the question.'||' / '!': logical operators, not type declarators. Common Pitfalls: Forgetting that '&' in expressions is address-of, while in declarations it forms a reference type. Context determines meaning. Final Answer: &

Question 13

C++ references: evaluate two claims  Once a reference variable has been defined to refer to a particular variable it can refer to any other variable.  A reference is not a constant pointer. Choose the single best option.

Accepted Answer

Introduction / Context: This question checks precise understanding of C++ references versus pointers. A reference acts as an alias to an existing object and is subject to strict binding rules. Many beginners mistakenly equate references with “constant pointers,” which leads to confusion about reseating, nullability, and dereferencing syntax. Given Data / Assumptions: Statement 1: After binding a reference to one variable, it can later refer to another variable. Statement 2: A reference is not a constant pointer. We consider standard C++ semantics without compiler extensions. Concept / Approach: A reference must be initialized to a valid object at its point of declaration and cannot be reseated to name a different object afterward. That is why references are often considered “aliases.” While some teaching materials loosely compare a reference to a “const pointer,” this is only an analogy and not a type identity. Pointers are objects with their own address and can be reassigned; references are not objects on their own and participate directly in expressions as the referred-to entity. Hence, it is more accurate to state “a reference is not a constant pointer.” Step-by-Step Solution: Check statement 1: false, because a reference cannot be reseated after initialization. Check statement 2: true, because references are not pointers (neither constant nor non-constant); they are aliases with different language rules. Conclusion: only statement 2 holds. Verification / Alternative check: Consider int x = 5; int& r = x; int y = 9; Attempting r = y; assigns to x through the reference; it does not reseat r. Taking &r yields the address of x, not a separate “reference object,” reinforcing that a reference is not a pointer variable. Why Other Options Are Wrong: Only 1 is correct — wrong; reseating is not permitted. Both correct — wrong because statement 1 fails. Both incorrect — wrong because statement 2 is accurate. Common Pitfalls: Confusing assignment through a reference with reseating the reference. Thinking references can be null or re-bound like pointers. Final Answer: Only 2 is correct.

Question 14

C++ references: evaluate two claims  A reference is not a constant pointer.  A reference is automatically dereferenced when used. Choose the single best option.

Accepted Answer

Introduction / Context: This item distinguishes C++ references from pointers and highlights how expression semantics differ. References behave like aliases to objects, removing the need for explicit * dereferencing that pointers require. The question asks you to validate two common statements about references. Given Data / Assumptions: Statement 1: A reference is not a constant pointer. Statement 2: A reference is automatically dereferenced in expressions. Standard C++ (no vendor-specific extensions) is assumed. Concept / Approach: References are not pointer variables; they do not store an address that you can reseat. Instead, the reference name is another name for the same object. When you write operations using a reference, the language automatically accesses the underlying object; hence there is no need to write *r to get the referent. This automatic dereferencing is why code using references often looks cleaner than the equivalent pointer code. Therefore, both statements align with core C++ rules. Step-by-Step Solution: Evaluate statement 1: true — a reference is an alias, not a constant pointer variable. Evaluate statement 2: true — expressions on a reference are applied to the referent directly, with no explicit * required. Conclude both statements are correct. Verification / Alternative check: Example: int x = 10; int& r = x; r++; After increment, x == 11. No *r was needed. Attempting to reseat r to another variable fails, confirming it is not a pointer that can be reassigned. Why Other Options Are Wrong: Only 1 or only 2 — each ignores the correctness of the other statement. Both incorrect — contradicts well-defined reference semantics. Common Pitfalls: Misinterpreting “automatic dereference” as “magically safe lifetime”; references still require valid lifetimes of referents. Confusing references with pointers regarding nullability and reseating. Final Answer: Both 1 and 2 are correct.

Question 15

C++ references: which statement about arrays of references and reseating is correct?

Accepted Answer

Introduction / Context: Unlike pointers, C++ references must bind to an object at initialization and cannot be left unbound. This property affects whether you can create arrays of references and whether a reference can later “point” somewhere else. The question probes both ideas through multiple choices. Given Data / Assumptions: References must be initialized and cannot be reseated. Arrays require elements to be assignable entities with default construction rules unless explicitly initialized. We compare references with pointers and aggregates to clarify misconceptions. Concept / Approach: Because references must be bound at initialization and have no “null” state, standard C++ does not allow arrays of references as first-class types. You can, however, have arrays of pointers or arrays of reference wrappers (e.g., std::reference_wrapper) that emulate reference semantics. Additionally, a reference cannot later refer to a different variable, so claims of reseating are false. The notion that a reference is “like a structure” is baseless; it is an aliasing mechanism, not an aggregate type. Step-by-Step Solution: Assess array of references: disallowed by language rules ⇒ “not acceptable.” Assess reseating: impossible once a reference is bound. Assess “like a structure”: incorrect classification. Therefore, option “An array of references is not acceptable.” is correct. Verification / Alternative check: Attempt to declare int& a[3]; Most compilers emit an error. Using std::reference_wrapper<int> a[3]; is legal, illustrating the preferred pattern when reference-like arrays are required. Why Other Options Are Wrong: Array acceptable — contradicts the language rule. Reseating a reference — violates reference semantics. Like a structure — a reference is not an aggregate type. Common Pitfalls: Confusing arrays of references with arrays of pointers. Assuming a reference can be rebound after assignment; assignments through a reference modify the referent, not the binding. Final Answer: An array of references is not acceptable.

Question 16

C++ references vs pointers: evaluate two claims  Pointer to a reference and reference to a pointer are both valid.  When we use a reference, we are referring to its referent (the underlying object).

Accepted Answer

Introduction / Context: This question checks nuanced type-formation rules and semantics for references. It asks whether you can form a pointer-to-reference type and whether a reference name denotes the underlying object directly in expressions. Understanding these points helps avoid invalid type declarations and improves API design. Given Data / Assumptions: We use standard C++ type rules. References must bind to objects and are not objects themselves. A reference can bind to a pointer type (i.e., reference-to-pointer is allowed). Concept / Approach: A “pointer to a reference” is ill-formed, because references do not exist as independent objects to which you can point. However, a “reference to a pointer” is valid; for example, int* p; int*& rp = p; binds a reference to a pointer variable. Separately, when you use a reference in an expression, the language automatically treats it as the referred-to object. Hence, statement 2 is true, but statement 1 is false because half of its conjunction (“pointer to a reference”) is invalid. Step-by-Step Solution: Test claim 1: pointer to reference — invalid; reference to pointer — valid ⇒ overall claim is false. Test claim 2: using a reference denotes the referent directly ⇒ true. Therefore, only statement 2 is correct. Verification / Alternative check: Compilation check: int& *pp; is rejected; int*& rp = p; is accepted. Using rp in expressions behaves exactly like using p, confirming “refer to the referent.” Why Other Options Are Wrong: Only 1 — wrong because pointer-to-reference is not a legal type. Both correct — wrong because claim 1 is half-invalid. Both incorrect — wrong because claim 2 is valid. Common Pitfalls: Thinking references are first-class objects; they are aliases and cannot be the target of pointers. Confusing reference-to-pointer with pointer-to-reference. Final Answer: Only 2 is correct.

Question 17

C++ references: evaluate two claims  Changing through a reference changes the referent (the bound object).  We can create an array of references.

Accepted Answer

Introduction / Context: References in C++ provide aliasing. When you modify a reference, you are actually modifying the underlying object. However, the language imposes restrictions on forming certain compound types with references, notably arrays. This question asks you to separate these two facts. Given Data / Assumptions: A reference is permanently bound to an object at initialization. Operations on the reference operate on the referent. Standard C++ does not support arrays of references. Concept / Approach: Because a reference is an alias, any assignment or mutation using the reference applies to the same storage as the original variable. Conversely, arrays of references are not allowed because references are not objects with independent identity and cannot exist “unbound.” If you need array-like behavior, use arrays of pointers or std::reference_wrapper to emulate collections of references. Step-by-Step Solution: Check 1: true — writing r = 42; updates the original object. Check 2: false — declarations like int& a[5]; are ill-formed in standard C++. Therefore, only statement 1 is correct. Verification / Alternative check: Demonstrate: int x = 7; int& rx = x; rx++; Then x == 8. Attempt to compile int& arr[3]; and observe a compile-time error. Use std::reference_wrapper<int> if you need an array-like container of referents. Why Other Options Are Wrong: Only 2 — wrong because arrays of references are disallowed. Both correct — fails due to statement 2. Both incorrect — fails because statement 1 is true. Common Pitfalls: Confusing changing the binding with changing the value; references cannot be reseated but can mutate the referent. Assuming reference collections exist natively; use pointers or reference wrappers instead. Final Answer: Only 1 is correct.

Question 18

C++ (old iostream.h): trace the ternary, references, and side effects—what does this program output and why?  #include<iostream.h> int CuriousTabFunction(int m) {  m *= m;  return ((10) * (m /= m)); } int main() {  int c = 9, *d = &c, e;  int &z = e…

Accepted Answer

Introduction / Context: This problem checks understanding of the conditional (ternary) operator, pointer indirection, pre/post increment semantics, and references in C++. The code also includes a function that normalizes a nonzero number to 1 via m /= m. Given Data / Assumptions: Old-style headers (<iostream.h>) but otherwise standard semantics. Initial c = 9, d points to c. Reference z bound to e. Concept / Approach: Evaluate the ternary condition carefully, track post-decrement and compound assignments, then propagate values through the function and the reference. Integer division and sequence points matter for the final value of e. Step-by-Step Solution: 1) Condition: c-- % 3. The value used is 9 % 3 = 0, then c becomes 8. 2) False branch executes: (*d *= *d). Since d points to c (currently 8), c becomes 64. The argument to the function is 64. 3) In CuriousTabFunction: m *= m makes m = 4096; m /= m makes m = 1; returns 10 * 1 = 10. 4) Back in main: e = 10. Then, with z referencing e, z = z + e / 10 makes e = 10 + 1 = 11 (integer division). 5) Final print: c is 64; e is 11. Verification / Alternative check: Replace the function with a direct expression returning 10 to confirm that only the normalization to 1 affects the result, not the squared size. Why Other Options Are Wrong: Compile error: Code is valid in classic compilers. 64 9 / 64 10: Miss the final reference update by e/10. 8 11: Ignores that c was squared to 64. Common Pitfalls: Forgetting that c-- uses 9 in the expression; misunderstanding reference aliasing; overlooking integer division. Final Answer: 64 11

Question 19

C++ references with enum-backed ints: after chained increments and assignments, what are p, q, and z?  #include <iostream.h> enum xyz { a, b, c }; int main() {  int x = a, y = b, z = c; // 0,1,2  int &p = x, &q = y, &r = z;  p = z;  p = ++q;  q = ++…

Accepted Answer

Introduction / Context: This item probes careful sequencing of pre/post increment with references bound to ordinary integers initialized from enum constants. The emphasis is on precise order of evaluation and aliasing via references. Given Data / Assumptions: Initial values: x=0, y=1, z=2. References: p=&x, q=&y, r=&z. Concept / Approach: Apply pre-increment (changes value, yields new value) and post-increment (yields old value, changes later) carefully. Assignment to p writes to x because p aliases x. Step-by-Step Solution: 1) p = z; sets x = 2. 2) p = ++q; increments y to 2, then assigns 2 to x (still 2). 3) q = ++p; increments x to 3, assigns 3 to y. 4) z = ++q + p++;: pre-increment y to 4 (yields 4), use p++ as 3 then increment x to 4; sum is 7; assign to z. 5) Final values: x=4, y=4, z=7. Verification / Alternative check: Manually simulate with a small table of values after each statement to confirm the 4/4/7 state before the print. Why Other Options Are Wrong: Other tuples mismatch the post-increment of p or the pre-increment of q in the final expression. Common Pitfalls: Treating p++ as if it yields the incremented value; mixing up the aliasing of references; forgetting that z is updated last. Final Answer: 4 4 7

Question 20

C++ reference semantics (post-increment in stream): what exact output appears and why?  #include<iostream.h> int main() {  int x = 10;  int &y = x;  x++;  cout << x << " " << y++;  return 0; }

Accepted Answer

Introduction / Context: This problem ensures you understand references and post-increment when used inside a streaming expression. Because y is a reference to x, y++ modifies x after yielding its current value. Given Data / Assumptions: Start: x=10. int &y = x; so y aliases x. Then x++; makes x=11. Concept / Approach: Post-increment (y++) yields the old value of y (which equals the current x) and then increments the object. Streaming prints values in order, using the produced value of each subexpression. Step-by-Step Solution: 1) After x++, x becomes 11. 2) cout << x prints 11 first. 3) y++ yields 11 (the current value), then increments the same underlying x to 12. 4) The output tokens are thus 11 and 11; the final state is x=12. Verification / Alternative check: Replace y with x; x++ in the stream shows identical printed result but changes the final state after printing. Why Other Options Are Wrong: Options showing 12 as the first number ignore that increment happened before printing; options showing 12 as the second number forget that post-increment prints the old value. Common Pitfalls: Confusing pre- vs post-increment result value; forgetting that y and x are the same object. Final Answer: 11 11

References Questions