大型图书馆中的命名空间使用和滥用[关闭]答案

【问题标题】：Namespace use and abuse in a big library [closed]大型图书馆中的命名空间使用和滥用[关闭]
【发布时间】：2012-10-04 10:12:42
【问题描述】：

我目前正在思考什么方法可以让我的（合理的）大库看起来不太胖，一些贡献者建议使用多个命名空间来对事物进行分类。

虽然我理解有必要为这个库的用户明确说明问题，但我怀疑命名空间是否是一个合适的解决方案，因为它使编写代码更加冗长，例如：

namespace1::namespace2::namespace3::SomeClass myObject* = new namespace1::namespace2::namespace3::SomeClass();

这个 c++ 特性在社区中的一般用途是什么？

整个库的单个命名空间 + 类的命名约定，或者 doxygen 文档中的 \addtosection 会更好吗？

【问题讨论】：

不能将胖库拆分成正交的小库？
@AlexandreC。实际上，该库并不那么胖（20-30 cpps），但为了清晰起见，它需要分组功能。如果库真的变大，拆分成组件可能会成为一种选择......

【解决方案1】：

整个库都需要一个命名空间吗？

命名空间的主要目的是避免符号名称相似的问题以及由此产生的符号名称冲突。
最好为您的库和有意义的指示类名称提供一个命名空间。这将有助于避免名称分类以及不太笨拙。

你可以一直使用，

如果您有嵌套的命名空间，无论出于何种原因都无法避免。

【讨论】：

说起来容易做起来难。有时，同一个名称在许多上下文中都可能有意义，并且您的库中可能同时具有这两个上下文。考虑Expression。
@pmr：这是基于感知和选择/偏好的问题，可以无休止地争论。
我知道，我只是想指出这并不像你说的那么容易。
@pmr：也没有你说的那么难。
就我个人而言，我只喜欢好的老式前缀。不用担心 ADL，对于那些经常使用声明/定义编写的人来说，减少与外部库发生冲突的可能性，更容易转发声明类型等。也就是说，我更喜欢库的单个命名空间，而不是涉及嵌套命名空间的库。单个库不得不担心自己的命名空间内的冲突似乎有点不协调。

【解决方案2】：

使用命名空间别名可以使深层命名空间级别变得漂亮，所以我不会认为这是一个很大的问题。这也是你不能用在类名前面加上模块名的命名约定来做的事情。

我认为 doxygen 中的组织与实际命名是正交的。如果您的代码没有明确的包含依赖项，则可以使用 doxygen 组。否则，我会以 doxygen 页面的形式提供文件级文档和文件层次结构指南。这样我就不需要手动对事物进行分组并同时检查我的包含内容。

【讨论】：

在 cmets 中询问 downvoting 并不是对 cmets 的适当使用（不仅因为它是徒劳的，因为没有人通知，而且因为它是噪音，cmets 是为了在帖子上澄清，不适用于元讨论）。今后请不要这样做。

【解决方案3】：

这是 Boost 使用的方法。但 Boost 是库的集合，每个库都在自己的命名空间中。

在函数内部，如果需要，您可以使用using 指令来减轻一些负担，例如using namespace std::placeholders 或using std::placeholders::_1。

或者您可以使用命名空间别名：namespace ns = name1::name2::name3。

最好的总体方法是创建几个独立的小型库，它们对彼此的假设最少，并给它们一个不同的命名空间。如果这不可行，您可能需要查看总体设计。

【讨论】：