1

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

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

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

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

4

2 回答 2

3

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

于 2010-06-11T13:34:11.880 回答
1

好吧，我认为在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;
    }
}

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

更新

故事的另一面是这样的：

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

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

像这样的东西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

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

于 2010-06-11T12:48:31.180 回答