- Which single edit is sufficient to make the program compile without introducing a using-directive?
Answer: Replace string with std::string.
Whenever you see a question about missing names in C++, ask yourself: which names are unqualified, and what declarations cover them? The file uses using std::cout;, which covers cout, and std::endl is already fully qualified. The only bare name with no declaration backing it is string — it lives in the std namespace and nothing brings it into scope.
That makes A correct. Writing std::string fully qualifies the name, so the compiler knows exactly where to find it — no using-directive needed, no other changes required.
B is wrong because cout is already handled. The using std::cout; declaration at the top of the file introduces cout into the global scope, so replacing it with std::cout would compile fine too, but it's not the fix the program needs — cout isn't the broken name here.
C goes the wrong direction. std::endl is already correctly qualified; stripping the std:: prefix would break it, since there's no using-directive or declaration to cover a bare endl.
D is a red herring. Moving using std::cout; inside main still covers cout and still does nothing for the unqualified string. The program would remain broken.
A handy rule of thumb: for every unqualified name in your code, trace it to exactly one declaration — either a using-declaration, a using-directive, or qualify it yourself with std::. If you can't find the declaration, that's your bug.
- Which statement correctly describes this program?
Answer: Only first compiles; the using-directive does not make level visible in second.
When you see a question about using namespace directives in C++, your first instinct should be to ask: what is the scope of that directive? Scope rules govern where names are visible, and they apply to using directives just as they do to variables.
A using namespace directive placed inside a function body has function scope — it only makes the namespace's names available within that specific function's curly braces. In first(), the line using namespace Settings; brings level into scope locally, so std::cout << level resolves correctly. However, once you exit first(), that directive expires. In second(), there is no using namespace Settings; and no explicit Settings::level qualification, so the compiler cannot find level — it simply doesn't exist in that scope. This makes A the correct answer: only first compiles successfully.
B is wrong because it describes a non-existent "file-level persistence" of function-scoped directives. A using directive inside a function does not leak out to the rest of the file — that would violate C++'s fundamental scoping rules.
C is wrong because it inverts the truth entirely. using directives are absolutely legal inside function bodies — in fact, that's often recommended to limit the directive's reach and avoid polluting the broader namespace.
D is wrong because explicit qualification (like Settings::level) is one option but not the only one. using namespace directives and using declarations are both valid alternatives.
Study tip: Think of using namespace like a local variable — it only lives inside the block where it's declared. If you need it in multiple functions, each function needs its own directive (or use it at namespace/global scope).
- Which statement best explains the result of the final call?
Answer: data::swap is called because argument-dependent lookup finds it and it is preferred to the generic template.
When a function call involves user-defined types, C++ performs argument-dependent lookup (ADL), also called Koenig lookup. This means the compiler searches for candidate functions not just in the current scope, but also in the namespaces associated with the types of the arguments. Recognizing this mechanism is key to understanding why using std::swap followed by an unqualified swap(first, second) doesn't always call std::swap.
Here, both first and second are of type data::Item. Because of ADL, the compiler looks into the data namespace and finds data::swap(Item&, Item&) — an exact match for the argument types. Meanwhile, std::swap is a generic template that would match via template instantiation. When a non-template function (like data::swap) and a function template (like std::swap<data::Item>) are both viable candidates, overload resolution prefers the non-template. So data::swap is called and "D" is printed — making C the correct answer.
A is wrong because the call isn't ambiguous — overload resolution has a clear rule that non-templates beat function templates when both are equally viable. B contains a false premise: using std::swap does not suppress ADL. It simply adds std::swap as a candidate; ADL still runs independently and adds namespace-associated candidates. D is entirely incorrect — a using-declaration legitimately introduces a name into the current scope, and the call syntax swap(...) is perfectly valid afterward.
The study tip here: the idiomatic C++ pattern using std::swap; swap(a, b); is designed to allow ADL to find a better, type-specific swap. That's the whole point of the pattern — don't mistake it for bypassing ADL.
- Which revision preserves the declaration while preventing standard-library names from being introduced globally into every including source file?
Answer: Remove the using-directive and declare std::string label(); inside widget.
When you see a question about headers and using directives, the core concern is namespace pollution: a using-directive in a header forces every file that includes it to inherit those names globally, whether they want them or not. This violates the principle of keeping headers self-contained and non-invasive.
The cleanest fix is to remove the using namespace std; entirely and write the fully qualified type name directly at the point of use — inside the namespace. That's exactly what B does: declaring std::string label(); inside widget makes the declaration self-sufficient without leaking anything into the global namespace of including files. Every translation unit that includes the header gets only what it explicitly asks for.
A is tempting but wrong — moving the using-directive below the declaration still places it at file scope in the header. Any source file including this header will still have string (and everything else from <string>) injected globally. The position relative to the declaration doesn't help.
C swaps a using-directive for a using-declaration (using std::string;), which is slightly narrower (only std::string, not the whole namespace), but it still pollutes the global namespace of every including file. It's a smaller problem, not a solved one.
D is syntactically invalid. widget::std::string is not a real qualified name — std is not nested inside widget, so this would fail to compile entirely.
As a study rule: **never put using directives or declarations at file scope in a header**. Always use fully qualified names (std::string, std::vector) in headers to avoid imposing your namespace choices on everyone else's code.
- What happens when this program is compiled and run?
Answer: It displays 5 because both namespace blocks contribute members to config.
When you see a namespace appear more than once in C++, the key concept to recall is that namespaces are open — they can be extended across multiple blocks, even across different files. Every block that shares a name contributes its declarations to the same namespace, not a separate one.
In this program, the first config block declares int base = 2, and the second config block defines int total(). Because both blocks belong to the same config namespace, total() can see base directly — no qualification needed. When total() executes, it returns base + 3, which is 2 + 3 = 5. That's exactly what gets printed, confirming that D is correct.
A reflects a common misconception: that namespaces work like classes or structs and can only be defined once. In reality, C++ explicitly permits — and encourages — splitting namespace definitions across multiple blocks or files. No compilation error occurs.
B is wrong because the second config block does not create a new, separate scope. It reopens the existing one. There is only one config namespace, so total() returns 5, not 3.
C would be correct if base truly were inaccessible — but since both blocks share the same namespace, all members from the first block are fully visible inside the second. No scoping barrier exists between them.
A handy rule of thumb: in C++, a namespace is like a folder you can open, add files to, close, and reopen later. Everything placed inside any block with that name ends up in the same folder.
- Adding declarations such as
counter to namespace std causes undefined behavior. Which rewrite preserves an output of 1 while placing each name in an appropriate namespace? Answer: Declare counter in namespace app and use std::cout << ++app::counter;.
Whenever you see C++ code that adds declarations to namespace std, your first instinct should be: this is undefined behavior. The C++ standard explicitly reserves namespace std for the standard library — injecting your own names into it is illegal, even if it compiles and appears to work.
The clean fix is to introduce your own namespace and keep std untouched. Option B does exactly this: it declares counter in namespace app, increments it with ++app::counter, and streams the result through std::cout. The output is still 1 because counter initializes to zero by default, the prefix increment brings it to 1, and std::cout handles the output correctly. Each name lives in the namespace that owns it — your data in app, the standard library in std.
Option A is tempting because static feels like it "contains" the variable, but marking it static only affects linkage, not the namespace violation. You're still adding a name to namespace std, which is still undefined behavior.
Option C moves counter correctly into app, but then uses app::cout — there is no cout in app. That's a compilation error, not a valid rewrite.
Option D creates a namespace alias (namespace app = std), which makes app simply another name for std itself. Declaring counter through that alias still puts it in namespace std, reintroducing the original undefined behavior.
As a study habit, remember: **never add to namespace std** — not with static, not with aliases. User-defined names always belong in user-defined namespaces.
- What happens when this program is compiled and run?
Answer: It compiles and displays A2.
Whenever you see a question mixing using declarations with local variable names, think about scope layering in C++. Each pair of braces creates a new scope, and names declared in inner scopes shadow — but don't destroy — names in outer scopes.
Here's what happens step by step. When show() begins, using std::cout brings cout into scope as a reference to the standard output stream. The first cout << "A" uses that declaration normally, printing A. Then a new block opens, and int cout = 2 declares a local integer named cout. Inside that block, the bare name cout now refers to the integer, shadowing the using declaration. However, std::cout is always accessible through its fully qualified name regardless of any local shadowing. So std::cout << cout sends the integer value 2 to standard output, printing 2. The result is A2, making A the correct answer.
B is wrong because there's no reason the second output would print A — cout inside the inner block refers to the integer 2, not the stream. C is wrong because declaring a local variable with the same name as a using-introduced name is perfectly legal in C++; it simply shadows it within that scope. D is wrong for the same reason — shadowing is local to the inner block only, and the using declaration remains valid in the outer scope of show.
A useful rule of thumb: **qualified names like std::cout are never shadowed** — you can always reach them by their full name, even when a local variable steals the short name.
- Inside
app::print, the unqualified name std resolves to app::std, so the statement std::cout << std::marker; does not compile as intended. Which replacement makes the program display 4? Answer: ::std::cout << std::marker;
When you see a question involving nested namespaces with names that shadow outer ones, think about name lookup and how C++ resolves unqualified vs. fully-qualified names.
Inside app::print, the name std is looked up in the enclosing scopes. Because app::std exists, it shadows the global ::std — so bare std refers to app::std, not the standard library namespace. This means std::cout fails (there's no cout in app::std) and std::marker would work, but you need both to behave correctly and independently.
Option C — ::std::cout << std::marker — is the correct fix. The leading :: on ::std::cout forces lookup to start at the global scope, reaching the real standard library std::cout. The unqualified std::marker then resolves to app::std::marker (since std still means app::std inside app::print), giving you the value 4. Both sides resolve exactly as needed.
Option A (::std::cout << ::std::marker) is wrong because ::std::marker looks for marker in the global ::std namespace — which doesn't have one. It would fail to compile. Option B (std::cout << ::std::marker) has the same two problems in reverse: std::cout fails because std resolves to app::std (no cout there), and ::std::marker still doesn't exist globally. Option D (cout << app::std::marker) would require a using namespace std; or qualified std::cout, and bare cout is unresolved.
As a study habit: whenever a local or nested namespace shares a name with a well-known one like std, remember that :: is your escape hatch to the global scope — and that each side of an expression resolves names independently.
- Which declaration can be inserted so that both qualified names in
main are valid? Answer: namespace original { int b = 2; }
When working with C++ namespaces, keep this in mind: a namespace alias like namespace short_name = original; doesn't create a new namespace — it simply creates another name that refers to the same namespace. So short_name::b and original::b are two ways of accessing the exact same entity.
That insight makes D the correct choice. By reopening namespace original { int b = 2; }, you add b to the original namespace. Since short_name is just an alias pointing to original, writing short_name::b is perfectly valid — it resolves directly to original::b.
Here's why the other options fail:
A — using namespace original; int b = 2; declares a global variable b, not a member of original. The using namespace directive makes original's members visible without qualification, but it doesn't adopt new declarations into that namespace. short_name::b would still be unresolved.
B — namespace short_name { int b = 2; } looks plausible but is actually illegal. You cannot use an alias as if it were a first-class namespace definition. Attempting to open short_name with curly braces is a compile error; only the original namespace name can be used to extend it.
C — namespace short_name = original { int b = 2; } is simply invalid C++ syntax. An alias declaration uses = but does not accept a body { }. This combines two unrelated syntaxes in a way the compiler will reject outright.
The key study tip: always remember that a namespace alias is a reference, not a copy — you can only add members through the original namespace name.
- What is the result of compiling and running this program?
Answer: It displays LR because overload resolution selects the closest match each time.
When multiple using namespace directives are active simultaneously, C++ doesn't simply pick one namespace over another — instead, it collects all visible names and applies normal overload resolution across them. This question tests whether you understand that distinction.
Here, using namespace Left brings Left::run(int) into scope, and using namespace Right brings Right::run(double) into scope. When the compiler sees run(3), it considers both candidates. An integer literal 3 matches Left::run(int) exactly, while converting it to double for Right::run(double) would require a standard conversion — so Left::run wins, printing L. For run(3.0), the literal 3.0 is already a double, making Right::run(double) the exact match over converting to int, so R is printed. The result is LR, confirming answer A.
Answer B is wrong because using directives carry no priority based on declaration order. C++ doesn't favor the first-declared namespace; it always performs overload resolution across all candidates equally. Answer C is wrong for the same reason in reverse — a double parameter can accept an int via implicit conversion, but that's a worse match than an exact int parameter, so it loses to Left::run. Answer D describes what would happen if both functions had identical signatures — ambiguity only arises when overload resolution cannot distinguish between candidates. Because these two functions have different parameter types, the call is always resolvable.
The key study tip: using namespace directives don't create ambiguity by themselves — they only cause errors when two candidates are equally good matches. As long as overload resolution can pick a winner, compilation succeeds normally.
