Question 1

C++ default arguments: which statement below is incorrect regarding default function arguments?

Accepted Answer

Introduction / Context:Default arguments in C++ let callers omit trailing parameters. They are inserted by the compiler at the call site. Understanding where defaults are allowed and the one-definition rules prevents ambiguous interfaces and linker surprises—especially in multi-declaration scenarios and for function-pointer parameters. Given Data / Assumptions: We consider regular functions and parameters that may be function pointers. We allow all parameters to have defaults if desired. We respect the rule: provide defaults once (typically in a header), not repeatedly. Concept / Approach: Default arguments may be supplied for any parameter, including a pointer-to-function parameter: e.g., void f(int, int (*pf)() = nullptr);. An entire parameter list may be defaulted, making the function callable with no arguments. However, a default argument must be specified only once for a given parameter across declarations; redeclaring a different default later is ill-formed. Therefore, the incorrect statement is the claim that “Default argument cannot be provided for pointers to functions.” It can be provided. Step-by-Step Solution: Evaluate A: allowed → correct statement. Evaluate B: allowed (all parameters may have defaults) → correct statement. Evaluate C: claims prohibition → incorrect. Evaluate D: redeclaration/redefinition of a default is not allowed → correct statement. Verification / Alternative check: Compile a sample where a function-pointer parameter has a default. It compiles. Add a second declaration that attempts to change the default and observe a compile-time error, confirming D and refuting C. Why Other Options Are Wrong: Labelled “wrong” here means “not the incorrect statement.” A, B, and D are all accurate rules of C++ defaults. Common Pitfalls: Placing defaults in multiple headers or both declaration and definition. Forgetting that callers must omit only a suffix of arguments; you cannot skip a middle parameter. Final Answer: Default argument cannot be provided for pointers to functions.

Question 2

C++ default arguments: which statement is correct about redefinition and using function calls as defaults?

Accepted Answer

Introduction / Context:Default arguments simplify function calls by supplying omitted values. Two frequent sources of confusion are whether the default can be a function call and whether a default can be specified again in another declaration. Clarifying these rules avoids ODR and ambiguity problems in headers and source files. Given Data / Assumptions: We may declare the same function more than once across translation units. A default argument is substituted at the call site. Expressions used as defaults must be visible at the point of declaration. Concept / Approach: C++ does allow a default argument to be any valid expression (subject to scope), including a function call such as int f(int x = get_default()); as long as the callee is declared beforehand. However, C++ forbids redefining the default for the same parameter in another declaration; you should place the default once (typically in a header) and omit it from later declarations/definitions. Thus, statement A is false, statement B is false, and statement D is the correct choice: redefinition of a default parameter is not allowed. Step-by-Step Solution: Check A: “cannot be function call” → false; function calls are allowed as defaults. Check B: “allows redefinition” → false; violates the one-default rule. Therefore D (no redefinition allowed) is the correct statement. C says both are true; it is therefore wrong. Verification / Alternative check: Write two declarations: one with = get_default() and a later one trying = 42. The compiler rejects the second. Ensure get_default is declared before the defaulted parameter; compilation then succeeds, proving A is false. Why Other Options Are Wrong: A: contradicts the language; defaults are ordinary expressions evaluated at the call site. B: contradicts ODR-style rules for defaults. C: a combination of two false statements. Common Pitfalls: Putting the same default both in the header and the definition file. Using non-visible names in the default expression. Final Answer: C++ does not allow the redefinition of a default parameter.

Question 3

C++ default parameters: identify which declarations are invalid and choose the best summary.

Accepted Answer

Introduction / Context:Default parameters in C++ must be supplied from the rightmost side leftward. Once a parameter has a default, all parameters to its right must also have defaults. Violating this rule results in declarations that cannot be called unambiguously because you would need to “skip” a middle parameter at the call site, which is not allowed. Given Data / Assumptions: We review three function declarations using default arguments. Parameters without defaults must appear before parameters with defaults. Defaults are inserted at the call site for omitted trailing arguments. Concept / Approach: Declaration A is valid: defaults are at the end (b and c), so callers may pass 1, 2, or 3 arguments. Declaration B is invalid because it gives a default to the first parameter but not to the second; callers would have to omit the first but still supply the second, which C++ cannot express. Declaration C is also invalid because a non-defaulted parameter b appears between defaulted parameters; callers could not omit the middle argument while taking the third’s default. Therefore, the best summary is that B and C are incorrect. Step-by-Step Solution: Analyze A: ok → trailing defaults only. Analyze B: defaulted a, non-default b → violates trailing rule. Analyze C: non-default b between defaulted a and c → violates trailing rule. Choose “Both B and C are incorrect.” Verification / Alternative check: Attempt to compile B and C: compilers emit errors. A compiles and is callable as Sum(1), Sum(1,2), and Sum(1,2,3). Why Other Options Are Wrong: “All are correct” is wrong because B and C break the rule. Any single choice misses that both B and C fail. Common Pitfalls: Assuming you can skip a middle parameter; you cannot. Redefining defaults across declarations—place them once in a header. Final Answer: Both B and C are incorrect.

Question 4

C++ default arguments usage: in what effective order do omitted arguments get supplied at the call site?

Accepted Answer

Introduction / Context:Default arguments in C++ are applied to trailing parameters that the caller omits. Practically, this means you provide actuals for the leftmost parameters and let the compiler fill in the rest using the defaults. Many MCQs summarize this as “defaults are taken from right to left.” Given Data / Assumptions: Defaults are specified in the function declaration. Callers may omit only a suffix of arguments. Evaluation of defaults happens at the call site. Concept / Approach: Because only the rightmost parameters can be defaulted in a usable way, when a caller omits arguments, the compiler supplies defaults beginning with the rightmost parameter and moving leftward as needed. This is why declarations must place non-defaulted parameters before defaulted ones. Any attempt to default a middle parameter creates unusable or ambiguous calls and is ill-formed. Step-by-Step Solution: Consider f(a, b = B, c = C). Call f(x) → b takes B, c takes C (filled from right to left). Call f(x, y) → c takes C only; b uses y. Call f(x, y, z) → no defaults used. Verification / Alternative check: Compile examples where you omit only trailing arguments; successful calls confirm the right-to-left filling. Try skipping a middle parameter; compilation fails, reinforcing the trailing rule and right-to-left mental model. Why Other Options Are Wrong: Left to right: contradicts the trailing-parameter rule. Alternate or random: defaults follow a strict, deterministic rule, not arbitrary order. Common Pitfalls: Defining defaults for non-trailing parameters. Redeclaring defaults across multiple declarations. Final Answer: The order of the default argument will be right to left.

Question 5

C++ overloading limits: which of the following functions cannot be overloaded? (Choose the only correct option.)

Accepted Answer

Introduction / Context:Function overloading in C++ permits multiple functions with the same name to co-exist in the same scope as long as their parameter lists differ. However, not every function name in a program is eligible for overloading. Recognizing the exceptions prevents invalid API designs and linker conflicts. Given Data / Assumptions: Overloading is distinguished strictly by the parameter list (not return type alone). We consider free functions and class member functions of various kinds. We must identify the one that the language forbids to overload. Concept / Approach: The program entry point main has a unique, implementation-defined signature (commonly int main() or int main(int, char**)) and cannot be overloaded. By contrast, ordinary member functions (including static and virtual) may be overloaded within their class scope by providing different parameter lists. Note that “virtual” concerns overriding across a hierarchy, which is orthogonal to overloading within the same scope. Step-by-Step Solution: List candidates: main, non-static member, static member, virtual member. Recall the special rule: main must be unique → cannot be overloaded. Confirm the rest: all can be overloaded by varying parameter lists. Select “The function main.” Verification / Alternative check: Attempt to provide two main definitions with different parameters; the program is ill-formed. In a class, define several functions with the same name but different parameters (static or non-static, virtual or not) and they overload successfully in that class scope. Why Other Options Are Wrong: Non-static, static, and virtual members may all be overloaded (overriding is a different concept for virtuals). Common Pitfalls: Confusing overloading (same scope, different signatures) with overriding (derived class replaces a virtual function). Expecting return type differences alone to create overloads; they do not. Final Answer: The function main

Question 6

C++ function overloading: which statement about parameter counts and types is correct?

Accepted Answer

Introduction / Context:Function overloading lets you offer multiple functions with the same name but different parameter lists. The compiler chooses the best match based on argument types and counts at the call site. Clarifying what may differ (or remain the same) across overloads avoids myths about required differences in both arity and types, or about return types controlling overloading (they do not). Given Data / Assumptions: Overload resolution uses parameter types, qualifiers, and counts. Return type alone cannot distinguish overloads. We compare claims about what “must” differ across overloads. Concept / Approach: Overloaded functions may have the same number of parameters and still overload successfully if the types differ (e.g., void f(int) vs void f(double)). They may also have a different number of parameters (e.g., arity 1 vs 2). What they cannot do is rely solely on differing return types; the parameter list must differ. Therefore, the correct statement is that overloaded functions can accept the same number of arguments (with different types). Step-by-Step Solution: Example: void area(int r); void area(double r); → same count, different types. Example: void log(const char*); void log(const char*, int); → different counts. Attempt: int f(int); double f(int); → invalid (return type alone). Thus, count may be the same; types must differ in some way. Verification / Alternative check: Compile examples above: the first two pairs succeed; the last fails. This demonstrates the real constraints on overloading. Why Other Options Are Wrong: “Always return same type”: return type does not govern overloading. “Only same number and same type”: identical signatures would be redefinitions, not overloads. “Only different number and different type”: too restrictive; types alone can differ with same count. Common Pitfalls: Forgetting that default arguments can interact with overloads and cause ambiguity. Depending on implicit conversions that make overload resolution surprising—prefer distinct signatures. Final Answer: Overloaded functions can accept same number of arguments.

Question 7

In C++ default-argument rules, which of the following statements is incorrect? Read carefully and select the option that violates how default parameters work in real code.

Accepted Answer

Introduction / Context:Default arguments in C++ allow you to omit trailing parameters at call sites, improving API ergonomics. However, the language enforces strict placement and declaration rules so that overload resolution remains unambiguous and readable. This question asks you to identify the statement that contradicts those rules. Given Data / Assumptions: We are discussing C++ function parameters and their default values. Default arguments are specified in a declaration (prototype or definition), not at the call site. Evaluation of default expressions happens at the point of call; name lookup/type checking happens at the point of declaration. Concept / Approach:C++ requires that once a parameter is given a default value, all parameters to its right must also have defaults. In other words, defaults must be trailing in the parameter list. You therefore cannot “skip” and default just a middle parameter while leaving a later parameter non-defaulted. Doing so would make the call syntax ambiguous and break predictable argument binding. Step-by-Step Solution:1) Consider f(a, b = 10, c). This is ill-formed because c has no default after b does.2) A correct arrangement is f(a, b, c = 42) or f(a, b = 10, c = 42).3) Type checking of the default expression occurs at the declaration; its evaluation happens each time the default is actually used at a call site.4) Hence, the statement claiming you can default “a middle” parameter while leaving later ones undecided is the incorrect one. Verification / Alternative check:Try compiling a function with a middle default and a non-default trailing parameter. Compilers reject it with diagnostics indicating that a parameter with no default follows a parameter with a default. Why Other Options Are Wrong:Type-checked-at-declaration and evaluated-at-call is correct per the language model.“We cannot provide a default value in the middle” is a correct statement of the rule.Usefulness claim is correct: defaults simplify common-case calls. Common Pitfalls:Repeating default values in multiple declarations (ODR hazards) or attempting to default only some non-trailing parameters, causing compile errors. Final Answer:We can provide a default value to a particular argument in the middle of an argument list.

Question 8

Default parameters in C++: which statement is correct about how many parameters may be defaulted? Choose the rule that best reflects the language design.

Accepted Answer

Introduction / Context:Default arguments let callers omit values and rely on sensible defaults. Understanding how many parameters may carry defaults is essential for designing friendly APIs without ambiguity. Given Data / Assumptions: A “default parameter” means a parameter that has a default value specified in a declaration. Defaulted parameters must be trailing (once a default appears, all following parameters must also have defaults). We are considering standard C++ rules. Concept / Approach:C++ places no hard numeric limit on how many parameters can be defaulted. In fact, every parameter can have a default so long as ordering rules are obeyed. There is no requirement that at least one parameter be defaulted, and certainly more than one may be defaulted. Step-by-Step Solution:1) Legal example: void f(int a = 1, int b = 2, int c = 3); // all defaulted2) Also legal: void g(int a, int b = 2, int c = 3); // defaults are trailing3) Illegal: void h(int a = 1, int b, int c = 3); // non-trailing b violates the rule4) Therefore, saying “all parameters can be default” is correct. Verification / Alternative check:Compile the examples above to see that fully defaulted parameter lists work, while the non-trailing default fails. Why Other Options Are Wrong:“Only one” is false; many parameters may have defaults.“Minimum one must be default” is false; defaults are optional.“No parameter can be default” contradicts the language feature. Common Pitfalls:Forgetting that once a default appears, all subsequent parameters must also have defaults; mixing defaults with overloading in ways that cause ambiguity. Final Answer:All the parameters of a function can be default parameters.

Question 9

Function overloading: which statement is correct under standard C++ rules? Assume normal overload resolution; default arguments do not change a function’s signature.

Accepted Answer

Introduction / Context:Overloading allows multiple functions to share a name while differing in their parameter lists. This enables more intuitive APIs when operations conceptually share a name but work on different types or arities. Given Data / Assumptions: Signatures differ by parameter count and/or types and/or cv/ref qualifiers. Default arguments do not participate in the function type and do not distinguish overloaded functions. We are not considering templates here, only ordinary overloading. Concept / Approach:A program may provide more than two overloads of the same function name—“overloaded more than once”—as long as each overload has a distinct signature. By contrast, two functions that have identical parameter lists cannot be overloaded regardless of whether they use default arguments. Default arguments influence call sites but not the function's type identity. Step-by-Step Solution:1) Legal: void f(int); void f(double); void f(int, int); // three overloads2) Illegal: void f(int); and again void f(int); // identical signatures3) Irrelevant: adding/removing defaults does not fix identical signatures.4) Therefore, the correct statement is that a function can be overloaded multiple times. Verification / Alternative check:Create several overloads with unique parameter lists and compile; then attempt two identical ones (with or without defaults) and observe a redefinition error. Why Other Options Are Wrong:Same number/order/type: cannot be overloaded; defaults do not help.“Must have default arguments”: untrue; defaults are optional and unrelated to overloading.“Defaults starting from left”: ordering rule is trailing-from-the-right, and defaults are not required for overloading. Common Pitfalls:Mixing defaults with overloads in headers and sources inconsistently, causing ambiguous calls; prefer to specify defaults once in a single declaration. Final Answer:A function can be overloaded more than once.

Question 10

If a function has three parameters, which position(s) may legally have default arguments under standard C++ rules? Choose the most accurate statement.

Accepted Answer

Introduction / Context:Default arguments must be placed so that call sites remain unambiguous. The conventional rule is that once a default is introduced, all parameters to the right must also have defaults. This governs which positions can legally carry defaults when some parameters remain non-defaulted. Given Data / Assumptions: There are exactly three parameters. We are considering cases where at least one parameter has no default. Standard C++ constraints apply. Concept / Approach:If any parameter lacks a default, then any defaults must appear only after that parameter. Hence, the rightmost (trailing) parameter is the safe and typical candidate for a default when earlier parameters remain non-defaulted. Alternatively, it is legal to default all three, but not legal to default a middle parameter while leaving a trailing parameter without a default. Step-by-Step Solution:1) Legal: void f(int a, int b, int c = 0); // trailing default2) Also legal: void f(int a, int b = 1, int c = 0); // trailing block of defaults3) Illegal: void f(int a = 1, int b, int c = 0); // non-trailing b breaks the rule4) Therefore, the most accurate general statement is that the trailing argument is (may be) the default one. Verification / Alternative check:Compile the examples to observe success for trailing defaults and failure for the middle-default case with a non-default trailing parameter. Why Other Options Are Wrong:First-only default with later non-defaults violates the trailing rule.Middle-only default with a non-default trailing parameter is ill-formed.“All arguments” can be defaulted, but that statement is not the best characterization when the question contrasts single-position cases; the safe, general choice is the trailing position. Common Pitfalls:Assuming any parameter can be defaulted in isolation; remember the trailing-block rule for defaults. Final Answer:The trailing argument will be the default argument.

Question 11

Which statement is correct about constructors and default parameters in C++? Pick the option that matches the language capabilities.

Accepted Answer

Introduction / Context:Constructors are ordinary functions with special roles. They follow most of the same parameter rules, including the ability to specify default values to streamline object creation across common cases. Given Data / Assumptions: C++ default-argument rules apply to constructors as well. Defaults must be trailing, and they are specified in a declaration. There is no arbitrary upper bound enforced by the language on how many defaults a constructor may have. Concept / Approach:Because constructors are functions, they can certainly include default parameters. This enables multiple construction patterns without writing numerous overloads. The same caveats apply: avoid ambiguous overloads, and place defaults only at the right end of the parameter list (or default all remaining parameters to the right). Step-by-Step Solution:1) Legal: struct T { T(int x = 0, int y = 0); };2) Calls: T a; T b(5); T c(5, 6); // all valid thanks to defaults3) There is no rule forbidding multiple defaults; the “five parameter” suggestion is fictitious.4) Therefore, the correct statement is that constructors can have default parameters. Verification / Alternative check:Implement such a constructor and instantiate objects with 0, 1, and 2 arguments; observe successful compilation and execution. Why Other Options Are Wrong:Cannot have defaults: contradicts standard practice.“Cannot have more than one” and “at most five”: both are arbitrary and false. Common Pitfalls:Combining defaulted constructors with similarly shaped overloads may create ambiguous calls; design parameter sets to avoid ambiguity. Final Answer:Constructors can have default parameters.

Question 12

Const-correctness for function parameters in C++: which statement is correct? Focus on what it means to accept constants and the restrictions on modification.

Accepted Answer

Introduction / Context:Const-correctness helps express intent and prevents accidental mutation. It applies to parameters (e.g., const int, const T&, const T*), return types, and member functions. This question checks basic understanding of accepting “constant” arguments and the promise not to modify them. Given Data / Assumptions: “Take constants as an argument” means parameters may be declared const-qualified where meaningful. Modifying a parameter declared const is ill-formed. We are not referring to top-level const copies that can still be shadowed; we focus on the prohibition against mutation of the const-qualified entity. Concept / Approach:Declaring parameters as const (e.g., const T& param) expresses that the function will not modify the object referred to. Pointers to const (const T* p) limit mutation through that pointer. Such declarations are core C++ usage. Therefore, it is correct that functions can accept const-qualified parameters and that those const-qualified parameters cannot be modified within the function body. Step-by-Step Solution:1) Example: void f(const std::string& s) { /* cannot modify s / }2) Attempting s.append("x"); would be ill-formed because s is const-qualified.3) Example with pointer: void g(const int p) { /* *p = 5; // ill-formed */ }4) These patterns directly support statements A and B. Verification / Alternative check:Compile examples that attempt to mutate const-qualified parameters; the compiler issues errors preventing changes, proving the rule. Why Other Options Are Wrong:“We cannot use the constant while defining the function” is meaningless/false; const is commonly used in function signatures. Common Pitfalls:Confusing top-level const on by-value parameters (which protects the local copy only) with const references/pointers that protect the underlying object. Final Answer:Both A and B.

Question 13

Default arguments: which statement is incorrect with respect to declaration and usage sites? Pick the option that violates best practice or standard rules.

Accepted Answer

Introduction / Context:Where you place default arguments affects readability and linkage. The language allows specifying defaults in a declaration; repeating them in multiple places leads to maintenance hazards and can violate the One Definition Rule (ODR) when headers and sources disagree. Given Data / Assumptions: Declarations may appear in headers; definitions often live in source files. The compiler relies on declarations to form calls during compilation. Global constants are in scope for use as default expressions. Concept / Approach:The standard practice is to specify default arguments exactly once—typically in the function prototype (declaration) in a header. They should not be repeated in the out-of-line definition; doing so duplicates information and can cause inconsistencies if values diverge across translation units. Step-by-Step Solution:1) Place defaults in a header: void f(int x = DefaultX);2) Define without repeating: void f(int x) { /* ... */ }3) The compiler uses the declaration to substitute missing arguments at call sites.4) Repeating defaults in the definition is discouraged/incorrect and may be ill-formed if it conflicts. Verification / Alternative check:Inspect any standard library header: defaults appear in declarations (e.g., ios flags manipulators). Out-of-line definitions omit default values. Why Other Options Are Wrong:Global constants as default values are fine.Defaults in the prototype are correct and conventional.The compiler indeed builds calls from the prototype information at the call site. Common Pitfalls:Putting different default values in multiple declarations across translation units, causing surprising behavior depending on which declaration a file sees. Final Answer:The default arguments are given in the function prototype and should be repeated in the function definition.

Question 14

Overloading with default arguments: which statement is correct under C++ rules? Assume you avoid ambiguity by careful design.

Accepted Answer

Introduction / Context:Overloading and default arguments interact. While both features are legal together, careless combinations can create ambiguous calls. The language itself does not forbid defaults on overloads; it only requires that declarations be consistent and unambiguous at call sites. Given Data / Assumptions: Multiple overloads of the same function name may exist. Any single function declaration can have multiple defaulted parameters, provided they are trailing. We are choosing a statement that reflects possibility, not necessarily best practice. Concept / Approach:All parameters of a particular overload can be defaulted, making that overload callable with zero explicit arguments. There is no “at most one default” restriction in the standard. Claims that overloads cannot have defaults are false; many real-world APIs mix both. The key is to ensure that different declarations do not lead to ambiguous calls, especially when some overloads have defaults and others do not. Step-by-Step Solution:1) Legal example: void f(int a = 1, int b = 2); // callable as f(), f(3), f(3,4)2) Coexist with overload: void f(double); // distinct signature3) Avoid ambiguous pairs like void f(int); and void f(int a = 0); within the same scope.4) Conclusion: It is correct that all arguments of an overloaded function can be defaulted. Verification / Alternative check:Compile a set of overloads where one has fully defaulted parameters and another has a clearly different signature; calls resolve correctly. Why Other Options Are Wrong:“At most one default”: false; multiple defaults are allowed.“Cannot have default”: false; perfectly legal.“Overloaded more than once cannot have default”: also false. Common Pitfalls:Specifying defaults for the same parameter in multiple declarations or crafting overload sets where omitted arguments cause ambiguity. Final Answer:All arguments of an overloaded function can be default.

Question 15

Where should the default value of a function parameter be specified in C++? Choose the place(s) allowed by the language (avoid duplicating across declarations).

Accepted Answer

Introduction / Context:Default arguments are part of a function declaration, not something written at the call site. C++ allows you to place them where you declare the function, but you must avoid repeating them in multiple declarations to prevent inconsistencies. Given Data / Assumptions: You may have a prototype in a header and a separate out-of-line definition in a source file. A definition is also a declaration in C++. The same default should not be written twice in different declarations in the same scope. Concept / Approach:You can specify defaults either in the function prototype (declaration) or, if there is no separate prototype, directly in the function definition (which is itself a declaration). Do not specify the same default in both prototype and definition. The call site never supplies the “= value” syntax; that syntax belongs only in declarations. Step-by-Step Solution:1) Header pattern: void f(int x = 1); // declaration with default2) Source definition: void f(int x) { /* ... / } // no repeat3) Single-file pattern: void g(int y = 2) { / ... */ } // default in definition (no separate prototype)4) Therefore, the correct answer is “Both B or C”. Verification / Alternative check:Move the default from the prototype to the definition and remove it from the prototype; compilation still succeeds as long as one visible declaration at the call site carries the default. Why Other Options Are Wrong:Function call: defaults are not written at call sites; they are inserted by the compiler.Picking only B or only C ignores that either location is valid when used singly. Common Pitfalls:Duplicating defaults across multiple declarations in headers and sources, risking divergence and ODR issues. Final Answer:Both B or C

Question 16

Which of the following function prototypes is perfectly acceptable in C++ for using a default argument? Assume referenced names are declared before the prototype.

Accepted Answer

Introduction / Context:Default arguments can be any valid expression that is type-checkable at the point of declaration and evaluable at the call site. This includes calling other functions, provided those functions are declared beforehand and the expression is well-formed. Given Data / Assumptions: The function Show() is declared and visible before the prototype using it as a default. Default argument expressions must be syntactically valid and convertible to the parameter type. We are comparing syntactic correctness of the options. Concept / Approach:Option A uses a valid expression: Show() is a function call with no arguments; its return value is used as the default for Tmp. The compiler type-checks this at the declaration and, if used, evaluates it at each call site where Tmp is omitted. Option B is ill-formed because it writes a type-list (Show(int, float)) in the default expression rather than an actual call with values, which is not valid C++ syntax. Option D is nonsensical and not a function prototype at all. Step-by-Step Solution:1) Check A: int Function(int Tmp = Show()); // valid if Show() is declared and returns a type convertible to int2) Check B: float Function(int Tmp = Show(int, float)); // invalid; default must be an expression, not a type signature3) Check D: not a valid prototype in C++ syntax.4) Therefore, only A is perfectly acceptable. Verification / Alternative check:Compile with a proper declaration of Show(): int Show(); and observe that Option A compiles and permits calls like Function(); which evaluates Show() at the call site for the omitted parameter. Why Other Options Are Wrong:B uses a type-spec list instead of an expression; it will not compile.D is malformed and not recognized as a function declaration.C is false because B and D are not valid; only A is acceptable. Common Pitfalls:Using undeclared names in default expressions (name lookup happens at the declaration) or repeating defaults across multiple declarations leading to ODR issues. Final Answer:int Function(int Tmp = Show());

Question 17

C++ default parameters: which function(s) cannot legally have default arguments?

Accepted Answer

Introduction / Context:Default arguments in C++ let you omit trailing parameters at the call site. They are inserted by the compiler during overload resolution, which makes APIs more convenient while keeping type safety. However, not every function may carry default arguments. This item focuses on identifying the exception among common function categories: ordinary member functions of classes and structures versus the special program entry point, main(). Given Data / Assumptions: C++ allows default arguments on ordinary functions and on member functions (both class and struct). Default arguments must be specified in a declaration that is visible to all call sites (typically headers). The function main() is a special entry point with an implementation-defined but fixed signature. Concept / Approach: The syntax rules for default arguments apply broadly: free functions, member functions, and even function-pointer parameters can use them. The single notable outlier is the program's entry point. main() must conform to one of the permitted signatures (commonly int main() or int main(int, char**)), and the standard does not allow you to modify that interface with defaulted parameters. By contrast, class and struct member functions are fully eligible for default arguments because, in C++, struct and class have identical member function rules (only the default access differs). Step-by-Step Solution: Check class member: allowed → eligible for defaults. Check struct member: same rules as class → eligible for defaults. Check main(): must match mandated signatures → defaults not allowed. Therefore, select main(). Verification / Alternative check: Attempt to declare int main(int argc = 0, char** argv = nullptr). Compilers reject this because main()'s signature is constrained. Conversely, adding defaults to a member function like void f(int x = 1) compiles and works as expected. Why Other Options Are Wrong: Member function of class — permitted; defaults are common in class APIs. Member function of structure — permitted; structs follow the same rules. Both B and C — incorrect because C is allowed while B is not. Common Pitfalls: Believing struct members follow different language rules from class members. Trying to place default arguments in multiple declarations, which is ill-formed. Final Answer: main()

Question 18

In C programming (assume sizeof(int) = 2 bytes), what will this program print?  #include <stdio.h> void fun(char**);  int main() {  char argv[] = {"ab", "cd", "ef", "gh"};  fun(argv);  return 0; } void fun(char p) {  char t;  t = (p += sizeof(int))[…

Accepted Answer

Introduction / Context:This question tests pointer arithmetic with pointer-to-pointer types in C. The function receives a char that points to the first element of an array of char* (C-strings). Understanding how pointer increments scale by the size of the pointed-to type is critical for predicting the printed output. Given Data / Assumptions: sizeof(int) = 2 bytes (as stated). Array: argv = { "ab", "cd", "ef", "gh" }. p is a char** initially pointing to &argv[0]. Expression: t = (p += sizeof(int))[-1]. Concept / Approach:In C, pointer arithmetic advances by the size of the pointed-to type, not by bytes you write in code. Since p is a char**, p += 2 moves two elements forward (two pointers), not two bytes. Then the [-1] index selects the element immediately before the new position. Step-by-Step Solution:Start: p → &argv[0].Compute p += sizeof(int) → p += 2 → p now points to &argv[2].Index [-1] → *(p - 1) → argv[1].Assign t = argv[1] → t points to "cd".printf prints "cd". Verification / Alternative check:You can mentally rewrite (p += 2)[-1] as *(p + 2 - 1) with p originally at element 0, giving element 1 → "cd". Why Other Options Are Wrong:"ab" is argv[0]; "ef" is argv[2]; "gh" is argv[3]; none match the indexed location after the pointer math. "Undefined behavior" does not apply because indexing stays within the array bounds. Common Pitfalls:Confusing sizeof(int) with raw byte offset on a pointer-to-pointer; in C, pointer arithmetic already scales by element size. Also, misreading [-1] as invalid; it is valid when the pointer already advanced. Final Answer:cd

Question 19

In C, what will this program print? Focus on the comma operator used in the return expression.  #include<stdio.h>  int addmult(int ii, int jj) {  int kk, ll;  kk = ii + jj;  ll = ii * jj;  return (kk, ll); }  int main() {  int i=3, j=4, k, l;  k = a…

Accepted Answer

Introduction / Context:This problem examines the C comma operator inside a return statement. The comma operator evaluates its left operand, discards the result, then evaluates and yields the right operand. Understanding this behavior explains the function’s return value and the program’s output. Given Data / Assumptions: i = 3, j = 4. kk = i + j = 7; ll = i * j = 12. return (kk, ll) uses the comma operator. Concept / Approach:For the expression (kk, ll), C guarantees left-to-right evaluation with the result being the value of the rightmost expression. Thus, the function returns the value of ll, which is 12. Step-by-Step Solution:Compute kk = 3 + 4 = 7.Compute ll = 3 * 4 = 12.Evaluate (kk, ll): first kk (discard), then ll → result 12.So addmult returns 12 each call.k = 12 and l = 12; printf prints "12, 12". Verification / Alternative check:Replace return (kk, ll) with return ll; Behavior is the same, confirming the result. Why Other Options Are Wrong:"7, 7" or mixed values assume kk is returned; that contradicts the comma operator. No compile error occurs; the comma operator is valid. Common Pitfalls:Confusing the comma operator with the comma that separates function arguments. Inside an expression, it has defined evaluation and result rules. Final Answer:12, 12

Question 20

In C, predict the output and trace scope and parameter shadowing carefully.  #include<stdio.h> int i; int fun1(int); int fun2(int);  int main() {  extern int j;  int i=3;  fun1(i);  printf("%d,", i);  fun2(i);  printf("%d", i);  return 0; } int fun1…

Accepted Answer

Introduction / Context:This question checks understanding of variable scope, shadowing, parameter passing by value, and the order of prints. Local variables can shadow globals, and function parameters are copies, so increments inside functions do not modify the caller’s variable. Given Data / Assumptions: Global i (unused effectively) and global j = 1. Main declares local i = 3, shadowing global i. fun1 takes parameter j (by value) and pre-increments it. fun2 takes parameter i (by value) and pre-increments it. Concept / Approach:Each function prints its own incremented parameter. The main’s local i remains unchanged because C passes arguments by value. The sequence of prints is crucial: fun1 → main print → fun2 → main print. Step-by-Step Solution:Call fun1(i) with i = 3 → parameter j = 3 → ++j = 4, prints "4,".Back in main, print i (still 3) → prints "3,".Call fun2(i) with i = 3 → parameter i = 3 → ++i = 4, prints "4,".Back in main, print i (still 3) → prints "3". Verification / Alternative check:Add explicit addresses or change parameter names; you will still observe call-by-value behavior and the same print order. Why Other Options Are Wrong:Any option that changes the second or fourth value misunderstands that main’s i remains 3. Options with leading 3 ignore the pre-increment inside fun1. Common Pitfalls:Confusing extern j with parameter j; the parameter hides the global name within fun1’s scope. Also, assuming pass-by-reference when C uses pass-by-value. Final Answer:4, 3, 4, 3

Functions Questions

Questions

Practice smarter