嵌套命名空间，纠正静态库设计问题

Question

我目前正在开发一个相当大的静态库，完成后某些工具将使用该库。现在，由于这个项目比我迄今为止参与的任何项目都要大，我意识到是时候为这个项目考虑一个好的结构了。使用命名空间是这些合乎逻辑的步骤之一。

我目前的方法是将库分成几部分（它们不是独立的，但它们的目的需要这样的分离）。我有一个“核心”部分，它现在只包含一些非常常见的 typedef 和常量（由库的许多不同部分使用）。其他部分是例如一些'utils'（散列等）、文件i/o等。这些部分中的每一个都有自己的命名空间。我几乎完成了“utils”部分，并意识到我的方法可能不是最好的。问题（如果我们想这样称呼它）是在 'utils' 命名空间中，我需要来自 'core' 命名空间的一些东西，这会导致包含核心头文件和许多 using 指令。

所以我开始认为这可能不是一件好事，应该以某种方式改变。我的第一个想法是使用嵌套命名空间来拥有类似 core::utils 的东西。由于这将需要一些繁重的重构，我想先在这里问一下。你怎么看？你会怎么处理这个？或更笼统地说：如何根据命名空间和代码组织正确设计静态库？如果有一些关于它的指南或文章，也请提及。谢谢。

注意：我很确定还有更多的好方法，而不仅仅是一种。随意发表你的想法、建议等。因为我正在设计这个库，所以我希望它真的很棒。目标是使其尽可能干净和快速。唯一的问题是我将不得不整合大量现有代码并对其进行重构，这确实是一个痛苦的过程（sigh）——这就是为什么良好的结构如此重要）

Answer 1

我自己的方法是每个库使用一个命名空间。我不认为嵌套命名空间会给聚会带来任何好处，除非你喜欢打字（在键盘上）。这对我来说是零问题。

Answer 2

好吧，我认为在 core.h 标头中，您会有类似的东西

#include <string>
#include <iostream>
namespace core
{
    typedef std::string mystring;
    #define mycout std::cout
}

而不是一个using 指令，以防止污染全局命名空间。在utils.h 标头中，您可以使用以下内容：

#include "core.h"
namespace utils
{
    core::mystring stringfunction(core::mystring &stuff)
    {
        core::mystring result;
        // do stuff
        return result;
    }
}

因此，除了 core:: 之外，任何地方都没有 mystring。它涉及更多的输入，但这就是命名空间的用途，让自己知道从哪里获取类型/函数/类。

更新

故事的另一面是这样的：

core.h 标头在上面的核心命名空间中声明内容。

utils.h 标头在 core::utils 命名空间中声明内容，然后是 namespace utils = core::utils 语句。这使得这两种方法与用户相同，并允许您在 utils*.h 标头和 *.cpp 文件中编写 mystring 而不是 core::mystring 之类的内容。

utils.h 是这样的：

#include "core.h"
namespace core
{
    namespace utils
    {
        mystring stringfunction(mystring &stuff)
        {
            mystring result;
            // do stuff
            return result;
        }
    }
}
namespace utils = core::utils; // allow user to type utils::stringfunction

这会稍微清理用户和库代码。