避免过度使用命名空间

发布于 2024-11-04 21:10:52 字数 776 浏览 4 评论 0原文

我的库使用几个嵌套的命名空间,布局如下:

Library name
    Class name 1
    Class name 2
    Class name 3
    [...]
    Utilities
        Class name 1
            [...]
        Class name 2
            [...]
        Class name 3
            [...]
        [...]

“Utilities”命名空间包含每个类的有用扩展,但不保证包含在实际类本身中。

“库名称”命名空间是必要的,因为它避免与其他库发生广泛冲突,“实用程序”命名空间是必要的,以避免 类似的东西,以及其中的“类名”命名空间避免了为类似类编写的实用程序之间的名称冲突。

尽管如此,在实践中这仍然是一个巨大的麻烦。以下面的例子为例:

MyLibrary::MyContainer<int> Numbers = MyLibrary::Utilities::MyContainer::Insert(OtherContainer, 123, 456);
// Oh God, my eyes...

这让我觉得我正在做一些严重错误的事情。有没有更简单的方法来让事情变得井然有序、直观且明确?

My library uses several nested namespaces, laid out like the following:

Library name
    Class name 1
    Class name 2
    Class name 3
    [...]
    Utilities
        Class name 1
            [...]
        Class name 2
            [...]
        Class name 3
            [...]
        [...]

The "Utilities" namespace contains useful extensions to each of the classes that don't warrant being included in the actual class itself.

The "Library name" namespace is necessary because it avoids broad conflicts with other libraries, the "Utilities" namespace is necessary to avoid the type of ambiguity that arises from things like this, and the "Class name" namespaces inside it avoid name clashes between utilities written for similar classes.

Despite this, it's still an enormous hassle in practice. Take the following, for example:

MyLibrary::MyContainer<int> Numbers = MyLibrary::Utilities::MyContainer::Insert(OtherContainer, 123, 456);
// Oh God, my eyes...

This makes me think I'm doing something seriously wrong. Is there an easier way to keep things organized, intuitive and unambiguous?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

输什么也不输骨气 2024-11-11 21:10:52

看看标准库(或 boost)是如何组织的。几乎所有内容都位于单个 std 命名空间内。将所有内容都放在自己的命名空间中几乎没有什么好处。

Boost 将大部分内容放入boost中,而主要库则获得单个子命名空间(boost::mpl,或<例如,code>boost::filesystem)。库通常为内部实现细节定义一个 aux 子命名空间。

但您通常不会看到深层或细粒度的命名空间层次结构,因为使用它们非常痛苦,而且几乎没有任何好处。

以下是一些好的经验规则:

与特定类相关的辅助函数应与该类位于同一命名空间中,以便 ADL 能够正常工作。然后,在调用辅助函数时,您根本不需要限定辅助函数的名称。 (就像如何在 std 中定义的迭代器上调用 sort 而不是 std::sort 一样)。

对于其他一切,请记住命名空间的目的是避免名称冲突,仅此而已。因此,您的所有库都应该位于a命名空间中,以避免与用户代码发生冲突,但在该命名空间内,没有技术上需要更多的子命名空间,除非您打算引入冲突的名称。

您可能希望将库的内部分离到子命名空间中,这样用户就不会意外地从主命名空间中获取它们,类似于 Boost 的 aux

但一般来说,我建议尽可能少的嵌套命名空间。

最后,我倾向于为我的命名空间使用简短、易于输入和易于阅读的名称(同样,std 是一个很好的例子。简短且易于理解)点,并且几乎总是没有进一步嵌套的命名空间,因此您不会因为经常编写它而感到紧张,因此它不会使您的源代码变得过于混乱。)

仅关于辅助函数和 ADL 的第一条规则将允许你的例子要这样重写相反:

MyLibrary::MyContainer<int> Numbers = Insert(OtherContainer, 123, 456);

然后我们可以将 MyLibrary 重命名为 Lib

Lib::MyContainer<int> Numbers = Insert(OtherContainer, 123, 456);

这样您就可以轻松管理了。

不同类的相似实用函数之间不应存在任何冲突。 C++ 允许您重载函数并专门化模板,以便您可以在同一命名空间中同时拥有 Insert(ContainerA)Insert(ContainerB)

当然,只有当您实际上拥有额外的嵌套命名空间时,命名空间和类之间才有可能发生冲突。

请记住,在您的Library命名空间中,独自决定引入哪些名称。因此,您可以通过不创建任何冲突的名称来避免名称冲突。将用户代码与库代码分开的命名空间很重要,因为两者可能不了解彼此,因此可能会无意中发生冲突。

但在您的库中,您可以为所有内容指定不冲突的名称。

Look at how the standard library (or boost) is organized. Nearly all of it is inside the single std namespace. There's just little to be gained by putting everything inside its own namespace.

Boost puts most things inside boost, while major libraries get a single subnamespace (boost::mpl, or boost::filesystem, for example). And libraries commonly define a single aux subnamespace for internal implementation details.

But you don't typically see deep or fine-grained namespace hierarchies, because they're just painful to work with, and there's little to no benefit from them.

Here are some good rules of thumb:

Helper functions related to a specific class should be in the same namespace as the class, to enable ADL to work. Then you don't need to qualify the name of the helper function at all when calling it. (Like how you can call sort instead of std::sort on iterators defined in std).

For everything else, remember that the purpose of namespaces is to avoid name clashes and not much else. So all your library should be in a namespace, to avoid clashes with user code, but within that namespace, there's no technical need for further subnamespaces unless you plan to introduce clashing names.

You may want to separate internals of your library into a sub-namespace, so users don't accidentally pick them up from the main namespace, similar to Boost's aux.

But generally, I'd suggest as few nested namespaces as possible.

And finally, I tend to make a point of using short, easy-to-type and easy-to-read names for my namespaces (again, std is a good example to follow. Short and to the point, and nearly always without further nested namespaces, so you don't get a cramp from having to write it often, and so it doesn't clutter your source code too much.)

Just the first rule about helper functions and ADL would allow your example to be rewritten like this instead:

MyLibrary::MyContainer<int> Numbers = Insert(OtherContainer, 123, 456);

Then we could rename MyLibrary to, say, Lib:

Lib::MyContainer<int> Numbers = Insert(OtherContainer, 123, 456);

and you're down to something pretty manageable.

There shouldn't be any clashes between similar utility functions for different classes. C++ allows you to overload functions, and specialize templates, so that you can have both an Insert(ContainerA) and Insert(ContainerB) in the same namespace.

And of course, clashes between namespaces and classes are only possible if you actually have additional nested namespaces.

Remember that within your Library namespace, you alone dictate which names are introduced. And so you can avoid name clashes just by, well, not creating any clashing names. A namespace to separate user code from library code is important because the two may not know about each others, and so clashes can occur unintentionally.

But within your library, you can just give everything non-clashing names.

や莫失莫忘 2024-11-11 21:10:52

如果有什么事情让你感到疼痛,就停止做它。绝对没有必要在 C++ 中使用深度嵌套的命名空间 - 它们并不是为了成为架构设备。我自己的代码始终使用单级命名空间。

如果您坚持使用嵌套命名空间,您始终可以为它们创建短别名:

namespace Util = Library::Utility;

然后:

int x = Util::somefunc();   // calls Library::Utility::somefunc()

If something hurts, stop doing it. There is absolutely no need to use deeply nested namespaces in C++ - they are not intended to be architectural devices. My own code always uses a single level of namespaces.

If you insist on using nested namespaces, you can always create short aliases for them:

namespace Util = Library::Utility;

then:

int x = Util::somefunc();   // calls Library::Utility::somefunc()
以往的大感动 2024-11-11 21:10:52

头文件中的声明要求命名空间不污染全局命名空间:

MyLibrary::Utilities::MyContainer<int> Numbers;

但在源文件中您可以使用 usings:

using namespace MyLibrary::Utilities;

...

MyContainer<int> Numbers;
Numbers.Insert(OtherContainer, 123, 456);

A declaration in a header file necessitates the namespacing to not pollute the global namespace:

MyLibrary::Utilities::MyContainer<int> Numbers;

But in the source file you can use usings:

using namespace MyLibrary::Utilities;

...

MyContainer<int> Numbers;
Numbers.Insert(OtherContainer, 123, 456);
感情洁癖 2024-11-11 21:10:52

完全限定的名称实际上对我来说看起来并没有那么糟糕,但我喜欢在方法和类名称中明确显示。但是 using 可以帮助解决问题:

您可能可以在源文件的全局范围内使用 using namespace MyLibrary ,从而使其:

MyContainer<int> Numbers = Utilities::MyContainer::Insert(OtherContainer, 123, 456);

然后您可以导入特定的函数您需要:

使用 MyLibrary::Utilities::MyContainer::Insert

然后
MyContainer;数字 = 插入(OtherContainer, 123, 456);

The fully qualified name doesn't actually look that bad to me, but I like being explicit in method and class names. But using can help things out:

You could probably get away with a using namespace MyLibrary at global scope in your source files, making it:

MyContainer<int> Numbers = Utilities::MyContainer::Insert(OtherContainer, 123, 456);

And then you can import the specific functions you need:

using MyLibrary::Utilities::MyContainer::Insert

and then
MyContainer<int> Numbers = Insert(OtherContainer, 123, 456);

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文