关注点、组织等的分离已经通过头部的定义实现。
是吗？
以Chapter 22: Utilities为例，这一章包含了13个独立的标题。标准本来可以有13个独立的章节，但是......为什么？这有什么好处？把所有这些内容放在独立的章节中有什么好处吗？因为它们比大多数其他章节都要短。
以Chapter 31: Input/Output为例，本章介绍了14个独立头文件中定义的内容，但这些头文件中的内容通常彼此高度相关，所有流最终都是基于iostream基类构建的，其中一些引用了其他头文件中的内容，比如文件流使用filesystem::path对象的能力。
但它们最终都是关于输入/输出的东西，所以把它们放在一章里是有意义的。
他们可以有14个单独的章节，每个标题一个，但这样做没有任何好处。实际上，你现在没有地方放Iostreams requirements section，它根本不绑定到 * 任何 * 标题。
说到不绑定到头部的重要信息，Container一章中最重要的部分之一是Requirements部分，它适用于 every container，这一部分对于理解任何container文档中发生的任何事情都是绝对重要的，并且在许多情况下定义了几个函数的行为，这些函数的定义没有在各个头文件的部分中列出。这是因为这些函数对所有容器的行为方式都相同。
我的意思是，我们真的需要看到begin、end等的定义重复9次吗？容器的全部意义在于有一个统一的接口，这样你就可以很容易地理解东西是如何工作的。如果你要有一个统一的接口，重复那个接口的定义是毫无意义的。
还有一些地方，标准可以直接指向一个章节，并说，“所有的东西也有这个属性。”最重要的是独立实现的概念。独立实现是不想实现整个标准库的C++实现，因为它有很多客户并不真正需要的东西（例如，微控制器并不关心文件系统），但标准库中的某些部分甚至必须由这些系统来实现。
这在C ++23之前的标准中更为突出，但在许多情况下，标准只会说“everything in this chapter/section must be in freestanding“。当一个章节/节可以包含尽可能多的标题时，这就容易多了。
这可能是为什么原子章节 * 不是 * 线程章节的一部分的部分原因（同样，C ++23之前的版本）。
这个组织纯粹是为了人类的目的，它与如何编写实现无关，除了独立的东西。