避免过度使用命名空间
我的库使用几个嵌套的命名空间,布局如下:
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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
看看标准库(或 boost)是如何组织的。几乎所有内容都位于单个
std
命名空间内。将所有内容都放在自己的命名空间中几乎没有什么好处。Boost 将大部分内容放入
boost
中,而主要库则获得单个子命名空间(boost::mpl
,或<例如,code>boost::filesystem)。库通常为内部实现细节定义一个 aux 子命名空间。但您通常不会看到深层或细粒度的命名空间层次结构,因为使用它们非常痛苦,而且几乎没有任何好处。
以下是一些好的经验规则:
与特定类相关的辅助函数应与该类位于同一命名空间中,以便 ADL 能够正常工作。然后,在调用辅助函数时,您根本不需要限定辅助函数的名称。 (就像如何在
std
中定义的迭代器上调用sort
而不是std::sort
一样)。对于其他一切,请记住命名空间的目的是避免名称冲突,仅此而已。因此,您的所有库都应该位于a命名空间中,以避免与用户代码发生冲突,但在该命名空间内,没有技术上需要更多的子命名空间,除非您打算引入冲突的名称。
您可能希望将库的内部分离到子命名空间中,这样用户就不会意外地从主命名空间中获取它们,类似于 Boost 的
aux
。但一般来说,我建议尽可能少的嵌套命名空间。
最后,我倾向于为我的命名空间使用简短、易于输入和易于阅读的名称(同样,
std
是一个很好的例子。简短且易于理解)点,并且几乎总是没有进一步嵌套的命名空间,因此您不会因为经常编写它而感到紧张,因此它不会使您的源代码变得过于混乱。)仅关于辅助函数和 ADL 的第一条规则将允许你的例子要这样重写相反:
然后我们可以将
MyLibrary
重命名为Lib
:这样您就可以轻松管理了。
不同类的相似实用函数之间不应存在任何冲突。 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
, orboost::filesystem
, for example). And libraries commonly define a singleaux
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 ofstd::sort
on iterators defined instd
).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:
Then we could rename
MyLibrary
to, say,Lib
: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)
andInsert(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.
如果有什么事情让你感到疼痛,就停止做它。绝对没有必要在 C++ 中使用深度嵌套的命名空间 - 它们并不是为了成为架构设备。我自己的代码始终使用单级命名空间。
如果您坚持使用嵌套命名空间,您始终可以为它们创建短别名:
然后:
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:
then:
头文件中的声明要求命名空间不污染全局命名空间:
但在源文件中您可以使用 usings:
A declaration in a header file necessitates the namespacing to not pollute the global namespace:
But in the source file you can use usings:
完全限定的名称实际上对我来说看起来并没有那么糟糕,但我喜欢在方法和类名称中明确显示。但是
using
可以帮助解决问题:您可能可以在源文件的全局范围内使用
using namespace MyLibrary
,从而使其:然后您可以导入特定的函数您需要:
使用 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:And then you can import the specific functions you need:
using MyLibrary::Utilities::MyContainer::Insert
and then
MyContainer<int> Numbers = Insert(OtherContainer, 123, 456);