9、新增容器：std::array、std::forward_list、std::unordered_map/set、std::tuple 的深度解析

C++11 在标准库容器这块，可以说是来了一次大补强。说实话，C++98/03 时代的容器虽然够用，但总有些场景让人感觉「差那么一点」。比如想要一个固定大小的数组，又不想用 C 风格指针提心吊胆；或者想用哈希表做快速查找，却只能自己造轮子。嗯，C++11 把这些坑都填上了。

我个人习惯把这四个新容器分成两类：序列容器（array、forward_list）和无序关联容器（unordered_map/set），外加一个元组（tuple）——它严格来说不算容器，但作为数据聚合工具，在实际项目中出场率极高。

核心要点：std::array 替代 C 数组，std::forward_list 是内存友好的单向链表，unordered 系列用哈希表实现 O(1) 查找，std::tuple 让你摆脱繁琐的结构体定义。

9.1 std::array：固定大小数组的正确打开方式

你想想看，C 风格数组有什么毛病？传参时退化成指针、不能直接赋值、没有 size() 方法、越界检查全靠自觉。我在项目中遇到过好几次因为数组越界导致的诡异崩溃，查了两天才定位到问题。后来我定了个规矩：只要数组大小在编译期已知，一律用 std::array。

#include <array>
#include <iostream>

int main() {
    // 声明一个包含5个int的数组
    std::array<int, 5> arr = {1, 2, 3, 4, 5};
    
    // 安全访问
    std::cout << arr.at(2) << std::endl;  // 带越界检查
    std::cout << arr[2] << std::endl;     // 无检查，但更高效
    
    // 获取大小
    std::cout << "Size: " << arr.size() << std::endl;
    
    // 支持迭代器
    for (auto& val : arr) {
        val *= 2;
    }
    
    // 可以直接赋值
    std::array<int, 5> arr2 = arr;
    
    return 0;
}

这里有个细节要注意：std::array 的大小是类型的一部分。也就是说 std::array<int, 5> 和 std::array<int, 10> 是两种不同的类型。这既是优点也是限制——你不能像 vector 那样动态改变大小。

我的建议：如果你需要栈上分配的固定大小数组，std::array 是首选。它没有动态内存分配的开销，性能与 C 数组完全一致，但提供了 STL 容器的所有接口。

9.2 std::forward_list：单向链表的极致优化

std::forward_list 是个很有意思的容器。它只提供前向迭代器，不支持反向遍历。说白了，它就是 C 语言里那种单向链表的 C++ 封装版。为什么 C++11 要加这个？因为有些场景下双向链表（list）太浪费了——每个节点多存一个 prev 指针，内存开销增加 50% 以上。

#include <forward_list>
#include <iostream>

int main() {
    std::forward_list<int> flist = {1, 2, 3, 4, 5};
    
    // 在头部插入（单向链表没有 push_back）
    flist.push_front(0);
    
    // 插入到指定位置之后
    auto it = flist.begin();
    std::advance(it, 2);  // 移动到第3个元素
    flist.insert_after(it, 99);
    
    // 遍历
    for (int val : flist) {
        std::cout << val << " ";
    }
    // 输出: 0 1 2 99 3 4 5
    
    return 0;
}

我曾经踩过的坑：std::forward_list 没有 size() 方法！因为维护 size 变量需要额外开销，而单向链表的设计初衷就是极致轻量。如果你需要知道元素个数，得自己遍历计数。另外，它的 insert 和 erase 都是 insert_after 和 erase_after，操作的是指定位置之后的元素，刚上手时很容易搞混。

什么时候用 forward_list？我个人经验是：当你的链表元素数量很大，且只需要前向遍历时。比如实现一个简单的哈希表链地址法，或者做内存池管理，forward_list 比 list 节省将近一半的内存。

9.3 std::unordered_map/set：哈希表的正式加盟

这是 C++11 最受欢迎的容器之一。在 C++98 时代，想要用哈希表要么用 boost，要么自己实现。我记得第一次用 unordered_map 时，那种「终于等到你」的感觉特别强烈。

unordered_map 和 unordered_set 的内部实现是哈希表，平均复杂度 O(1)，最坏情况 O(n)。而 map/set 是红黑树，稳定 O(log n)。怎么选？如果你对元素顺序有要求，用 map/set；如果只关心查找速度，用 unordered 系列。

#include <unordered_map>
#include <string>
#include <iostream>

int main() {
    std::unordered_map<std::string, int> scores;
    
    // 插入
    scores["Alice"] = 95;
    scores["Bob"] = 87;
    scores.insert({"Charlie", 92});
    
    // 查找
    auto it = scores.find("Bob");
    if (it != scores.end()) {
        std::cout << "Bob's score: " << it->second << std::endl;
    }
    
    // 遍历（注意：无序！）
    for (const auto& [name, score] : scores) {
        std::cout << name << ": " << score << std::endl;
    }
    
    // 检查是否存在
    if (scores.count("David") == 0) {
        std::cout << "David not found" << std::endl;
    }
    
    return 0;
}

性能对比（实测数据）：

操作 std::map (红黑树) std::unordered_map (哈希表)
查找 100 万元素 ~20 次比较 ~1 次哈希计算
插入 100 万元素 O(log n) 平衡开销 O(1) 均摊，但可能 rehash
有序遍历 ✅ 天然有序 ❌ 无序
内存占用 较低（每个节点 3 指针） 较高（哈希表 + 链表）

这里有个关键点：自定义类型作为 unordered_map 的键时，需要提供哈希函数。标准库为基本类型和 string 提供了默认哈希，但如果你用自定义结构体做键，就得自己写 hash 特化。

struct Person {
    std::string name;
    int age;
    
    bool operator==(const Person& other) const {
        return name == other.name && age == other.age;
    }
};

// 自定义哈希函数
struct PersonHash {
    std::size_t operator()(const Person& p) const {
        return std::hash<std::string>()(p.name) ^ 
               (std::hash<int>()(p.age) << 1);
    }
};

std::unordered_map<Person, std::string, PersonHash> personMap;

避坑指南：我曾经在项目中用 unordered_map 存储大量数据，结果发现性能越来越慢。排查后发现是哈希冲突太严重——我用的哈希函数质量太差。后来改用 std::hash 的组合方式，问题解决。记住：哈希函数的质量直接影响性能，不要随便用简单的异或。

9.4 std::tuple：比 pair 更强大的数据聚合

std::tuple 是 std::pair 的泛化版本。pair 只能装两个元素，tuple 可以装任意多个。说实话，tuple 在 C++ 中的使用频率不如 Python 那么高，但在某些场景下确实能简化代码。

#include <tuple>
#include <iostream>
#include <string>

int main() {
    // 创建 tuple
    std::tuple<int, std::string, double> t1(42, "hello", 3.14);
    
    // C++17 的类模板参数推导
    auto t2 = std::make_tuple(100, "world", 2.718);
    
    // 访问元素
    std::cout << std::get<0>(t1) << std::endl;  // 42
    std::cout << std::get<1>(t1) << std::endl;  // hello
    std::cout << std::get<double>(t1) << std::endl;  // 3.14（按类型访问）
    
    // 结构化绑定（C++17）
    auto [id, msg, value] = t1;
    std::cout << id << " " << msg << " " << value << std::endl;
    
    // 拼接 tuple
    auto t3 = std::tuple_cat(t1, t2);
    
    return 0;
}

tuple 最实用的场景是什么？我个人觉得是函数返回多个值。以前要么用输出参数（引用/指针），要么定义一个结构体。有了 tuple，可以直接返回，配合结构化绑定使用起来非常优雅。

// 返回多个值的函数
std::tuple<bool, int, std::string> parseConfig(const std::string& key) {
    // 模拟解析过程
    if (key == "timeout") {
        return {true, 30, ""};
    }
    return {false, 0, "Key not found"};
}

// 调用
auto [success, value, error] = parseConfig("timeout");
if (success) {
    std::cout << "Value: " << value << std::endl;
} else {
    std::cerr << "Error: " << error << std::endl;
}

注意：tuple 虽然方便，但不要滥用。如果返回的数据有明确的语义（比如一个「学生」包含姓名、年龄、成绩），还是定义一个结构体更清晰。tuple 适合那些临时组合、语义不强的数据聚合。

9.5 知识体系总览

为了让你更直观地理解这四个容器的定位和关系，我画了一张图：

C++11 新增容器知识体系 std::array std::forward_list unordered_map/set std::tuple 序列容器 序列容器 无序关联容器 元组工具 核心特性对比 固定大小 栈上分配 无动态内存 替代C数组 单向链表 前向迭代器 内存节省 无size() 哈希表实现 O(1)查找 无序存储 需哈希函数 异构数据 任意数量 结构化绑定 临时聚合 选择建议：需要固定大小 → array | 需要单向遍历 → forward_list 需要快速查找 → unordered | 需要临时聚合 → tuple

9.6 实战选择指南

说了这么多，到底什么时候用哪个？我根据自己的项目经验，总结了一个简单的决策流程：

  1. 需要固定大小的数组？ → std::array（不要犹豫，直接替代 C 数组）
  2. 需要链表结构，且只向前遍历？ → std::forward_list（内存敏感场景首选）
  3. 需要快速查找，不关心顺序？ → std::unordered_map/set（哈希表就是为速度而生）
  4. 需要临时组合多个值？ → std::tuple（比定义结构体更轻量）
  5. 需要有序的键值对？ → 还是用 std::map/set（红黑树稳定可靠）

我的个人习惯：在写新代码时，我会默认用 unordered_map 替代 map，除非明确需要有序遍历。对于数组，只要大小在编译期确定，一律用 array。forward_list 用得相对少，但在做内存池或实现某些算法时，它确实比 list 更合适。tuple 则是在写工具函数或临时数据处理时才会用，正式接口我还是倾向于定义结构体——代码可读性更重要。

好了，这四种新增容器的核心内容就这些。记住：工具没有好坏，只有合不合适。理解每种容器的设计初衷和适用场景，才能在项目中做出正确的选择。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →