Namespaces and Name Conflicts

Trace the state

1. value is first declared inside the block owned by f.
2. The second declaration attempts to introduce another value into the same block.
3. The compiler can diagnose this before linking because the conflict is visible in one translation unit.
4. The fix is not a namespace; it is to remove, rename or narrow one of the local declarations.

Layer task

Classify each mini-exercise conflict as local, namespace, translation-unit or link-stage, then choose the smallest repair.

Example: compile-time conflict in one block

This is the simplest conflict: two declarations with the same identifier in the same local scope.

void f() {
    int value = 0;
    int value = 1; // redeclaration in the same scope
}

Applied task

Classify three name conflicts as block-scope, namespace-scope or cross-translation-unit.

Example: two definitions discovered at link time

Both source files can compile on their own, but they define the same external object.

// a.cpp
int counter = 0;

// b.cpp
int counter = 0; // multiple definition at link stage

// main.cpp
extern int counter;
int main() { return counter; }

Fix: declare in a header, define once

extern announces the shared object. Exactly one .cpp file owns the definition.

// counter.h
#pragma once
extern int counter;

// counter.cpp
#include "counter.h"
int counter = 0;

// main.cpp
#include "counter.h"
int main() { return counter; }

Applied task

Explain why extern belongs in the header but the storage definition belongs in exactly one .cpp file.

Example: same name, different namespace

Both modules can expose load because callers qualify the intended owner.

namespace img {
    void load();
}

namespace analyze {
    void load(); // different meaning in a different namespace
}

int main() {
    img::load();
    analyze::load();
}

Example: distinct ownership

The same short identifier can exist safely when each owner is explicit.

namespace telemetry {
    int counter = 0;
}

namespace billing {
    int counter = 0;
}

int totalEvents = telemetry::counter;
int totalInvoices = billing::counter;

Example: nested, alias and anonymous namespaces

Aliases shorten a clear namespace path. Anonymous namespaces keep helper symbols private to one .cpp file.

// Nested and alias
namespace mylib { namespace io { void save(); } }
namespace io = mylib::io;

io::save();

// Anonymous namespace: internal linkage, only this .cpp sees it
namespace {
    void helper_only_in_this_file();
}

Applied task

Choose namespace names for two modules that both need a function called parse, then explain how callers should qualify them.

Example: targeted using in a .cpp file

This shortens a single frequently used type without importing the whole namespace into every includer.

// Good in .cpp, targeted
using std::string;

string name = "Graham";

Avoid: broad using in a header

This leaks names into every source file that includes the header.

// Avoid in headers:
// using namespace std; // pollutes all includers

std::string make_label();

Applied task

Rewrite a header that uses using namespace std; so it exposes only qualified names or targeted declarations in source files.

Example: CPU/GPU implementation alias

Client code calls math::dot; the alias decides which implementation namespace that name currently means.

namespace math_cpu {
    double dot(const std::vector<double>& a, const std::vector<double>& b);
}

namespace math_gpu {
    double dot(const std::vector<double>& a, const std::vector<double>& b);
}

// Choose at build time:
#if defined(USE_GPU)
namespace math = math_gpu;
#else
namespace math = math_cpu;
#endif

// Client code:
double s = math::dot(a, b); // binding chosen by alias

Applied task

Design two namespaces with identical APIs, then write one alias switch that selects the implementation.

A. Multiple main functions

Both files are valid as separate programs. Together, they form one invalid executable target because they define two entry points.

// main_a.cpp
int main() { return 0; }

// main_b.cpp
int main() { return 0; } // multiple definition of 'main'

// Fix: build one executable per main, or exclude extra mains from the target.

B. Missing main

If every file is library code, the executable target has no entry point.

// math.cpp
int square(int x) { return x * x; }

// no file in this executable target defines main()
// Linker: undefined reference to main

// Fix: add one main.cpp, or build these files as a library target.

C. Global name collisions

Two libraries expose the same un-namespaced symbol. Wrap your code in a unique namespace.

// lib_a.cpp
void init() {}

// lib_b.cpp
void init() {} // collision if both are externally visible

namespace app_a { void init() {} }
namespace app_b { void init() {} }

Applied task

Given a linker error, decide whether the target contains duplicate main functions, duplicate global definitions or a missing implementation.

Preferred: anonymous namespace

Only this .cpp file can see helper.

// file.cpp
namespace {
    void helper() {} // only visible in this translation unit
}

Older alternative: static

This also gives internal linkage, but anonymous namespaces are clearer for C++ file-local groups.

static void helper2() {} // also internal linkage; prefer anonymous namespace in C++

Applied task

Find three helper functions in a .cpp file and decide whether each should be anonymous-namespace private or part of the public API.

Applied task

Choose one item from the checklist and find a concrete example in a small C++ project.

Applied task

Take one compiler or linker error and rewrite it as an ownership question about the identifier involved.

Case 1: Local duplicate

A function declares int value twice in one block. Decide whether namespaces are relevant or whether the local design should be simplified.

Case 2: Two global counters

Two source files define int counter. Decide whether this should be one shared object, two namespaced objects or two local static objects.

Case 3: Imported library collision

A library and your project both expose a function called parse. Decide whether qualification, namespace aliases or renamed public APIs would make the boundary clearer.

A. Same block conflict

Decide why this fails and whether a namespace would be the right fix.

void score() {
    int value = 10;
    int value = 20;
}

• Identify the scope where the conflict occurs.
• Remove or rename the redundant declaration.
• Explain why a namespace is not the natural repair for this case.

void score() {
    int initialValue = 10;
    int adjustedValue = 20;
}

B. Link-time conflict

Two .cpp files define the same externally visible object.

// a.cpp
int counter = 0;

// b.cpp
int counter = 0;

// main.cpp
extern int counter;
int main() { return counter; }

• Explain why this may compile file-by-file but fail at link time.
• Choose whether there should be one shared counter or two independent counters.
• Repair using either extern plus one definition, or namespaces for separate ownership.

// counter.h
#pragma once
extern int counter;

// counter.cpp
#include "counter.h"
int counter = 0;

// main.cpp
#include "counter.h"
int main() { return counter; }

C. Namespace ownership

Two modules both want parse. Make ownership explicit at the call site.

int parse(const char* text);
int parse(const std::string& text);

• Place each function into a namespace that communicates its domain.
• Write two call sites using qualified names.
• Explain when a namespace alias would help and when it would hide too much.

namespace config {
    int parse(const std::string& text);
}

namespace protocol {
    int parse(const char* packet);
}

int configResult = config::parse("threads=4");
int packetResult = protocol::parse(packetBytes);

D. Heal an ODR violation

The header below defines storage in every translation unit that includes it. Repair it with extern plus a single definition.

// counter.h
#pragma once
int counter = 0; // every includer gets a definition

// a.cpp
#include "counter.h"

// b.cpp
#include "counter.h"

• Explain why this violates the one definition rule for externally visible storage.
• Move the declaration into the header and the definition into one .cpp file.
• Explain when inline constexpr might be appropriate instead.

// counter.h
#pragma once
extern int counter;

// counter.cpp
#include "counter.h"
int counter = 0; // single definition

E. Clean up using in a header

This header exports a broad using directive to every file that includes it.

// label.h
#pragma once
#include <string>
using namespace std;

string make_label(string prefix);

• Remove the broad using directive.
• Use qualified names in the public header.
• If a source file wants a shorter name, use a targeted using declaration there instead.

// label.h
#pragma once
#include <string>

std::string make_label(std::string prefix);

// label.cpp
#include "label.h"
using std::string;

string make_label(string prefix) {
    return prefix + " label";
}

F. Switch implementations with an alias

Two implementations expose the same API. Choose one namespace behind a stable client-facing alias.

namespace store_memory {
    bool save(const std::string& key, const std::string& value);
}

namespace store_disk {
    bool save(const std::string& key, const std::string& value);
}

// TODO: choose one implementation namespace as `store`.
bool ok = store::save("user", "Graham");

• Add a build-time alias that maps store to either store_memory or store_disk.
• Explain why both namespaces must keep identical APIs.
• State whether this is clearer than passing an object or interface in this small example.

#if defined(USE_DISK_STORE)
namespace store = store_disk;
#else
namespace store = store_memory;
#endif

bool ok = store::save("user", "Graham");

G. Diagnose duplicate entry points

This project accidentally compiles two toy programs into one executable.

// main_a.cpp
int main() { return 0; }

// main_b.cpp
int main() { return 1; }

• Explain why namespaces are not the right repair.
• Separate the files into different executable targets or compile only one.
• Write the build-system question you would ask before changing code.

// Target toy_a uses: main_a.cpp
// Target toy_b uses: main_b.cpp
// One executable target should receive exactly one `main`.

H. Tame the collisions

Two utilities define init() and log() globally, so the linker cannot distinguish their ownership.

// util_a.cpp
void init() {}
void log(const char*) {}

// util_b.cpp
void init() {} // collides
void log(const char*) {} // collides

• Move both utilities into properly named namespaces.
• Export a small, distinct API and update call sites to qualify ownership, such as app::a::init() and app::b::init().
• Decide whether any helper functions should be anonymous-namespace private.

// util_a.cpp
namespace app { namespace a {
    void init() {}
    void log(const char*) {}
}}

// util_b.cpp
namespace app { namespace b {
    void init() {}
    void log(const char*) {}
}}

app::a::init();
app::b::init();

I. Make helpers private by default

This helper is externally visible even though only this file needs it.

// parser.cpp
void trim_buffer() {}

int parse_record(const char* text) {
    trim_buffer();
    return text ? 1 : 0;
}

• Move trim_buffer into an anonymous namespace.
• Explain why parse_record may remain externally visible if it is part of the API.
• Compare the anonymous namespace version with namespace-scope static.

// parser.cpp
namespace {
    void trim_buffer() {}
}

int parse_record(const char* text) {
    trim_buffer();
    return text ? 1 : 0;
}