Question bank — Namespaces — avoiding name collisions

namespace A { void f() {} }
namespace B { void f() {} }
using namespace A;
using namespace B;
int main() { f(); }
``` — what breaks and why? ::: The call `f()` is **ambiguous**: both using-directives put `A::f` and `B::f` into lookup with equal rank, so the compiler cannot choose. Fix by qualifying: `A::f();`.
 
```cpp
// in header "log.h"
using namespace std;
``` — why is this a defect even though it compiles? ::: Every file that `#include`s `log.h` silently inherits *all* of `std` into its scope, so a user's `distance` or `count` can suddenly clash with `std::distance`. Never place a using-directive in a [[Header Files and Include Guards|header]].
 
```cpp
namespace Ns { int x = 1; }   // in a.cpp
namespace Ns { int x = 2; }   // in b.cpp
``` — what does the linker say? ::: An ODR / "multiple definition of `Ns::x`" error. Both refer to the single entity `Ns::x`; a definition may appear only once across the program.
 
```cpp
using std::swap;
swap(a, b);   // wanted the global one
``` — how do you force the global `swap`? ::: Write `::swap(a, b)`. A leading `::` restarts lookup at the top-level global namespace, bypassing the `using`-introduced `std::swap`.
 
```cpp
namespace Company { namespace Project { int port; } }
int p = Project::port;
``` — why won't this compile? ::: `Project` is not a top-level name; its full name is `Company::Project`. You must write `Company::Project::port` (or make an alias).
 
```cpp
namespace {
    int helper() { return 7; }
}
// then in another .cpp file:
extern int helper();   // trying to reuse it
``` — why does the link fail? ::: The unnamed-namespace `helper` has internal linkage, so it is invisible outside its own TU. The other file's `extern` declaration finds no matching external symbol.
 
---
 
## Why questions
 
Why does `Foo::bar` never trigger a lookup search through enclosing scopes? ::: The qualification forces the candidate set to exactly `{Foo::bar}` — there is nothing to search. Unqualified `bar` is what triggers the scope-by-scope search that can end in ambiguity.
 
Why is a using-directive riskier than a using-declaration? ::: A using-declaration names one identifier you consciously chose; a using-directive imports *every* name from the namespace, so future additions to that namespace (or to [[The Standard Library (std)|std]]) can start clashing with your code without you touching a thing.
 
Why do library authors wrap their public API in a namespace at all? ::: So users can keep their own short names (like a variable `parse`) without coordinating with the library — different prefixes give different full names, letting both coexist. It removes the need for global name coordination "with everyone on Earth."
 
Why does a namespace alias make code more readable without sacrificing uniqueness? ::: The long prefix `Company::Project::Net` is unique but unreadable; the alias `CPN` is a short *local* synonym that still resolves to that exact unique box — you keep uniqueness and gain brevity.
 
Why can the same name exist as `std::count` and `App::count` at once, but not as two `count`s in the global scope? ::: The two namespaced versions have distinct full names, so lookup can always tell them apart. Two global `count`s share one full name (`::count`) — that is a genuine collision / redefinition.
 
Why is putting helpers in an unnamed namespace better than making them global? ::: File-local helpers with the same name in different `.cpp` files would otherwise collide at link time; internal linkage confines each to its own TU, eliminating cross-file clashes entirely.
 
---
 
## Edge cases
 
What is the full name of a name defined in the global scope, and how do you write it explicitly? ::: Its "prefix" is empty (the unnamed top-level namespace), and you write it explicitly as `::name` with nothing before the `::`.
 
If a namespace is *reopened* in a third file to add a new function, is that legal? ::: Yes — namespaces are open, so adding *new distinct* members across files is fine. Only re-*defining the same* member is the ODR problem.
 
What happens if two using-directives import the same name but that name is never actually called? ::: Nothing. Ambiguity is only diagnosed at the *point of use*; merely making two `f`s visible is legal until you write an unqualified `f()`.
 
Can an unnamed namespace contain a *type* (a class), and does that class have internal linkage? ::: Yes — types are allowed, and the type is confined to the TU. This is one thing file-scope `static` could never do, which is why unnamed namespaces replaced it.
 
If a local `using std::cout;` and a global variable `cout` both exist, which does an unqualified `cout` pick inside that block? ::: Lookup finds the nearer, block-scope `using`-introduced `std::cout` first, shadowing the global; write `::cout` to reach the global one deliberately.
 
Does `namespace Company::Project::Net { ... }` (C++17 nesting) create three new namespaces or reopen existing ones? ::: It opens (creating if absent, reopening if present) each level in turn — it is pure shorthand for the three separate nested `namespace` blocks, with identical meaning.
 
Is `A::f()` still unambiguous if *only* `using namespace A;` is active (no `B`)? ::: Yes, and even the unqualified `f()` would be fine then — ambiguity needs two equally-ranked candidates. One visible `f` resolves cleanly.
 
---
 
> [!mnemonic] The trap-spotter's checklist
> **"Prefix, Open, Not-private, Header-danger."**
> - **Prefix** → different box ⇒ different full name ⇒ no collision.
> - **Open** → same `Ns::x` in two files ⇒ ODR error.
> - **Not-private** → namespaces rename, they don't hide.
> - **Header-danger** → never `using namespace` in a header.
 
---
 
## Connections
- [[Namespaces — avoiding name collisions]]
- [[One Definition Rule (ODR)]]
- [[Linkage — internal vs external]]
- [[Scope and Storage Duration]]
- [[Header Files and Include Guards]]
- [[The Standard Library (std)]]
- [[Classes and Encapsulation]]