为什么禁止一次打开多个命名空间？答案

【问题标题】：Why is it forbidden to open multiple namespaces at a stretch?为什么禁止一次打开多个命名空间？
【发布时间】：2011-09-13 10:35:01
【问题描述】：

可以做到using namespace foo::bar;（即使用内部命名空间而不首先使用外部命名空间/），为什么标准禁止这样做？

namespace foo::bar {
  // open nested namespace bar in foo and extend it...
}

我不是在寻找解决方法，只是想说明为什么不允许这样做。

【问题讨论】：

【解决方案1】：

我不确定“禁止”是正确的词 - 也许这只是一个疏忽。这是一个相当小的好东西，并不是什么大不了的事。

您还可以认为，当您编写 foo::bar 时，命名空间 foo 尚未创建，因此允许该语法使其看起来就像 foo 已创建，但实际上并非如此。

您还可以更进一步，请求编写class Foo::MyClass {... 以在命名空间MyClass 中定义Foo 的能力，函数、变量等也是如此。但是这个功能真的有必要并解决任何特别紧迫的问题吗?

【讨论】：

如果您将命名空间功能视为整个 C++ 语言中的一个功能，那么这没什么大不了的。但是，如果您只使用命名空间功能本身，并将其与其他语言（例如 C#）中的工作方式进行比较，那么它真的很糟糕。此外，我想不出由于在复合命名空间表达式中递归创建缺少的命名空间而引起的任何歧义，解决您的第二段。
你确定你说“真的很糟糕”没有反应过度吗？它几乎不会使命名空间变得无用或根本不如任何其他系统。这只是 IMO 的一个小疏忽。
如果你在namespace Foo {...} 中转发声明class MyClass;，你可以说class Foo::MyClass {...};（至少使用GCC）。
是的，“真的很烂”中的“真的”可能太强了。尽管如此，C++ 开发人员似乎讨厌嵌套超过 3 个级别的名称（根据 DeadMG 的答案的 cmets），我不禁认为这与这个问题有关。例如，在 C++ 中，您不希望为您的名称空间使用类似 Java 的命名约定（org::apache::commons::collections::BidiMap，有人吗？），而且 syntax 是此类名称的主要障碍，这有点奇怪.
语法不会阻止它，请参阅 DeadMG 的答案。另外，我猜大多数时候命名空间声明之间有一些东西，所以你甚至不会使用 foo::bar 语法。它是如此微小的东西，它真的影响了任何东西吗？它甚至应该说它“糟透了”吗？我说不是……！

【解决方案2】：

既然可以做到，为什么还要让编译器实现它

namespace foo { namespace bar {

}}

【讨论】：

既然用户可以自己模拟，为什么还要让编译器实现any功能？总是一样的原因：减少用户的工作量。
嗯，这不是一个真正的答案，不是吗？ OP 没有明确要求解决方法，而是可能的推理。另外，考虑嵌套> 3。我知道，不应该做这种可憎的事情，但它们在野外存在。 ://
@Konrad：编译器节省了用户重要的工作。不是十个字。 @Xeo：不让人们实现它是不标准化它的一个完全正当的理由——看看export。
@DeadMG 我觉得这很重要。 C++ 有大量的语法混乱，以至于我在 C++ 中花费了很大一部分编程时间实际上是打字。任何现代语言都不应要求这样做。特别是，必须打开嵌套的命名空间声明是真的很烦人。如果我可以写namespace x::y::z 这将非常节省时间。
DeadMG，我不同意您的论点，即编译器 only 为用户节省了大量工作。这只是倒退。从 C++03 到 C++11，我们获得了在嵌套模板参数（如 std::vector<std::vector<int>>）之间消除单个空格字符的能力。谁会喜欢一种对你有帮助的语言？这个功能也不会妨碍高级用户。