有没有更好的方法在标头中用 C++ 表达嵌套命名空间 [英] Is there a better way to express nested namespaces in C++ within the header
问题描述
我从 C++ 切换到 Java 和 C#，并认为命名空间/包的使用在那里更好(结构良好).然后我回到 C++ 并尝试以相同的方式使用命名空间，但所需的语法在头文件中很糟糕.
I switched from C++ to Java and C# and think the usage of namespaces/packages is much better there (well structured). Then I came back to C++ and tried to use namespaces the same way but the required syntax is horrible within the header file.
namespace MyCompany
{
namespace MyModule
{
namespace MyModulePart //e.g. Input
{
namespace MySubModulePart
{
namespace ...
{
public class MyClass
以下内容对我来说也很奇怪(为了避免缩进):
The following seems strange to me too (to avoid the deep indent):
namespace MyCompany
{
namespace MyModule
{
namespace MyModulePart //e.g. Input
{
namespace MySubModulePart
{
namespace ...
{
public class MyClass
{
有没有更短的方式来表达上面的事情?我错过了类似的东西
Is there a shorter Way to express the above thing? I am missing something like
namespace MyCompany::MyModule::MyModulePart::...
{
public class MyClass
更新
好吧，有人说 Java/C# 和 C++ 中的用法概念不同.真的吗?我认为(动态)类加载不是命名空间的唯一目的(这是一个非常技术推理的观点).为什么我不应该将它用于可读性和结构化，例如考虑IntelliSense".
Ok, some say the concept of usage in Java/C# and C++ is different. Really? I think (dynamic) class loading is not the only purpose for namespaces (this is a very technical reasoned perspective). Why shouldn't I use it for a readability and structurization, e.g think of "IntelliSense".
目前，命名空间与您可以在其中找到的内容之间没有逻辑/粘合.Java 和 C# 在这方面做得更好... 为什么包括 <iostream> 并具有命名空间 std?好的，如果您说逻辑应该依赖标头来包含，为什么#include 不使用IntelliSense"友好语法，如 #include <std::io::stream> 或
Currently, there is no logic / glue between a namespace and what you can find there. Java and C# does this much better... Why including <iostream> and having namespace std?
Ok, if you say the logic should rely on the header to include, why does the #include does not uses an "IntelliSense" friendly syntax like #include <std::io::stream> or <std/io/stream>? I think the missing structurization in the default libs is one weakness of C++ compared to Java/C#.
如果狂热冲突的唯一性是一个点(这也是 C# 和 Java 的一个点)，一个好主意是使用项目名称或公司名称作为命名空间，你不这么认为吗?
If uniqueness to avid conflicts is one Point (which is a point of C# and Java, too) a good idea is to use the project name or company name as namespace, don't you think so?
一方面有人说 C++ 是最灵活的......但每个人都说不要这样做"?在我看来，C++ 可以做很多事情，但与 C# 相比，在许多情况下，即使是最简单的事情，它的语法也很糟糕.
On the one hand it's said C++ is the most flexible... but everyone said "don't do this"? It seems to me C++ can do many things but has a horrible syntax even for the easiest things in many cases compared to C#.
更新 2
大多数用户说创建比两个级别更深的嵌套是无稽之谈.好的，那么 Win8 开发中的 Windows::UI::Xaml 和 Windows::UI::Xaml::Controls::Primitives 命名空间呢?我认为微软对命名空间的使用是有道理的，而且它确实比 2 级更深.我认为更大的库/项目需要更深的嵌套(我讨厌像 ExtraLongClassName这样的类名，因为你可以把所有东西都放到全局命名空间中.)
Most users say it is nonsense to create a deeper nesting than two Levels. Ok, so what about Windows::UI::Xaml and Windows::UI::Xaml::Controls::Primitives namespaces in Win8 development? I think Microsoft's usage of namespaces makes sense and it is indeed deeper than just 2 Levels. I think bigger libraries / projects need a deeper nesting (I hate class names like ExtraLongClassNameBecauseEveryThingIsInTheSameNameSpace... then you could put everything into the global namespace, too.)
更新 3 - 结论
大多数人说不要这样做"，但是……即使是 boost 的嵌套也比一两层更深.是的，它是一个库，但是:如果您想要可重用的代码 - 将您自己的代码视为您将提供给其他人的库.我还使用更深的嵌套来使用命名空间进行发现.
Most say "don't do it", but... even boost has a deeper nesting then one or two levels. Yes, it is a library but: If you want reusable code - treat your own code like a library you would give someone else. I also use a deeper nesting for discovery purposes using namespaces.
推荐答案
C++17 可能会简化嵌套命名空间定义:
C++17 might simplify nested namespace definition:
namespace A::B::C {
}
等价于
namespace A { namespace B { namespace C {
} } }
请参阅 cppreference 上命名空间页面上的 (8):
http://en.cppreference.com/w/cpp/language/namespace
See (8) on namespace page on cppreference:
http://en.cppreference.com/w/cpp/language/namespace
这篇关于有没有更好的方法在标头中用 C++ 表达嵌套命名空间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
