为什么需要命名空间#

假设你同时使用两个第三方库：

1
void print(const std::string& s);
2

3
// libB.h
4
void print(const std::string& s);

两个库都定义了 print，链接器会直接报错：multiple definition of print。这就是名称冲突（name collision）。

命名空间的作用是给名字套一个”容器”，把 print 变成 libA::print 和 libB::print，彻底消除歧义。std::cout 里的 std 就是标准库的命名空间，iostream 里所有的东西——cin、cout、string、vector——都住在 std 这个容器里。

定义命名空间#

语法很直接：

1
namespace mylib {
2
    void print(const std::string& s) {
3
        std::cout << s << '\n';
4
    }
5

6
    int version = 1;
7
}

调用时加上 :: 作用域解析符：

1
mylib::print("hello");
2
int v = mylib::version;

命名空间有一个和 class 不同的重要特性：同一个命名空间可以跨多个文件分散定义，不需要集中在一处。

1
namespace engine {
2
    void render();
3
}
4

5
// physics.h
6
namespace engine {
7
    void simulate();
8
}

这两个文件都在扩展同一个 engine 命名空间，完全合法。

嵌套命名空间#

命名空间可以嵌套，用来反映模块层级：

1
// C++17 之前
2
namespace engine {
3
    namespace render {
4
        namespace vulkan {
5
            void init();
6
        }
7
    }
8
}
9

10
// C++17 简写，完全等价
11
namespace engine::render::vulkan {
12
    void init();
13
}

调用时：

1
engine::render::vulkan::init();

using 声明与 using 指令#

写代码时频繁敲 std:: 会让代码很啰嗦，using 可以简化，但用法差别很大。

1
using std::cout;
2
using std::string;
3

4
cout << "hello" << '\n';  // OK，只有 cout 和 string 被引入

1
using namespace std;
2

3
cout << "hello" << '\n';  // 方便，但危险

1
int max(int a, int b);  // 项目自己的 max

1
#include <algorithm>
2
#include "utils.h"
3
using namespace std;
4

5
int result = max(3, 5);  // 调用的是哪个 max？

1
// bad_header.h  ← 这样写会污染所有 include 它的文件
2
#pragma once
3
#include <string>
4
using namespace std;  // 危险！
5

6
void doSomething(string s);

匿名命名空间#

1
namespace {
2
    void helper() {
3
        // 只在本文件内可见
4
    }
5

6
    int internalCounter = 0;
7
}

匿名命名空间等价于 static——它给里面的名字赋予内部链接（internal linkage），其他翻译单元看不到这些名字。这是现代 C++ 替代文件级 static 函数的推荐方式，语义更清晰。

命名空间别名#

深层嵌套的命名空间每次写全名太累：

1
// 每次都写这个？
2
std::experimental::filesystem::path p = "data/config.json";

用别名：

1
namespace fs = std::experimental::filesystem;
2

3
fs::path p = "data/config.json";
4
fs::exists(p);

在实际项目里，别名常用于隔离第三方库的版本变化——改一行别名定义就能切换底层实现。

inline namespace（简要提及）#

C++11 引入了 inline namespace，主要用于库的版本控制：

1
namespace mylib {
2
    inline namespace v2 {
3
        void api();  // 默认使用 v2
4
    }
5
    namespace v1 {
6
        void api();  // 旧版本，显式指定才能访问
7
    }
8
}
9

10
mylib::api();     // 调用 v2::api
11
mylib::v1::api(); // 显式调用旧版本

这样库作者可以在不破坏 ABI 的前提下演进接口。大多数应用层代码不需要定义 inline namespace，知道它存在即可。

AI Infra 视角#

有意思的是，C 语言没有命名空间，但大型 C 库通过命名前缀实现了相同的效果：

• cuBLAS：cublasCreate、cublasHandle_t、cublasSgemm
• NCCL：ncclCommInitRank、ncclAllReduce、ncclComm_t
• MPI：MPI_Init、MPI_Send、MPI_Comm

所有符号都以库名为前缀，手动实现命名空间的语义。这也是为什么这些 C 接口看起来有点啰嗦——这是在没有语言支持时的工程妥协。

现代 C++ 库则直接用命名空间：Abseil 的 absl::flat_hash_map，Protobuf 的 google::protobuf::Message，结构清晰，不需要靠命名前缀维持秩序。

小结#

命名空间本身不复杂，但用好它需要一点纪律：头文件里永远写完整名字，using namespace 只在实现文件的局部作用域里用。遵守这两条，你就不会被名称冲突坑到。