为什么我们不能在一个类中声明一个命名空间？

Question

在类中声明类是有效的。 （嵌套类）

在类中声明命名空间是无效的。

问题是：有什么好的理由（除了 c++ 语法/语法问题）禁止在类中声明命名空间吗？

---

至于我为什么要这样做，这里有一个例子：

让我们有一个二叉树容器的基本说明

template<typename Data>
class binary_tree
{
 public:
  ... stuff ....

 private:
  ... iterators class declaration ...

 public:
  typedef left_depth_iterator_impl     left_depth_iterator;
  typedef right_depth_iterator_impl    right_depth_iterator;
  typedef left_breadth_iterator_impl   left_breadth_iterator;
  typedef right_breadth_iterator_impl  right_breadth_iterator;

  ... stuff ....

 private:
  Data         data;
  binary_tree* left;
  binary_tree* right;
};

现在我注意到我的类中有很多迭代器，所以我想在同一个命名空间中重新组合它们，如下所示：

 template<typename Data>
class binary_tree
{
 public:
  ... stuff ....

 private:
  ... iterators class declaration ...

 public:
  namespace iterator
  {
    typedef left_depth_iterator_impl     left_depth;
    typedef right_depth_iterator_impl    right_depth;
    typedef left_breadth_iterator_impl   left_breadth;
    typedef right_breadth_iterator_impl  right_breadth;
  }

  ... stuff ....

 private:
  Data         data;
  binary_tree* left;
  binary_tree* right;
};

这将允许一个简单的用法：

 void  function()
{
  binary_tree::iterator::left_depth   it;

  ...stuff...
}

如果我使用一个类而不是命名空间，这会起作用，但是我被迫声明一个永远不会被实例化的类，它是一个相当命名空间。

为什么允许嵌套类并禁止在类中嵌套命名空间？这是遗留负担吗？

---

具有语义原因的答案不仅引用标准的一部分（尤其是语法部分）将被欣赏:)

原文由 Drax 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

将这样的功能添加到语言中并没有真正的优势。除非有需求，否则通常不会添加功能。

类中的命名空间会给你带来什么？你真的宁愿说 binary_tree::iterator::left_depth 而不是简单的 binary_tree::left_depth 吗？也许如果您有多个名称空间，您可以使用它们来区分 binary_tree::depth_iterator::left 和 binary_tree::breadth_iterator::right 。

在任何情况下，您都可以使用内部类作为差劲程序员的命名空间来获得所需的结果，这也是为什么在类中不需要真正的命名空间的更多原因。

原文由 Adrian McCarthy 发布，翻译遵循 CC BY-SA 3.0 许可协议

Answer 2

我在这里不同意其他人的意见。我不会说没有真正的优势。有时我只想在没有额外含义的情况下隔离代码。例如，我在一个多线程 ringbuffer 模块中工作，并希望将状态成员（其中一些是原子的和/或内存对齐的）拆分为生产者和消费者的命名空间。

通过使用 producer 或 consumer 前缀（这是我当前令人讨厌的实现）来命名所有内容，我添加了污染，使代码更难阅读。例如，当生产者拥有的所有内容都以 producer 开头时，您的大脑在阅读时更容易意外 producerProducerTimer （生产者计时器的生产者副本）为 producerConsumerTimer （消费者计时器的生产者影子）或 consumerProducerTimer （生产者计时器的消费者影子）。由于代码不再可浏览，因此调试所需的时间比需要的时间长。

通过创建嵌套类/结构：

• 我可能会给下一个维护此代码的开发人员一个想法，即在上下文中可以/应该实例化、复制和分配多个这些代码中的一个以上，所以现在我不仅要担心命名，还必须 = delete 这些东西。
• 我可以使用结构对齐填充将内存占用添加到上下文中，否则这可能是不必要的。
• 将所有成员设为静态不是一种选择，因为可以实例化多个需要其自己的生产者/消费者状态变量的上下文。
• 这种结构的函数不再可以访问其他成员数据或函数，例如双方共享的常量或函数，而是必须将这些东西作为参数。

理想情况下，我希望能够改变这样的事情：

 rbptr producerPosition;
rbptr consumerPosition;

对此：

 namespace producer
{
    rbptr position;
}
namespace consumer
{
    rbptr position;
}

然后，应该只接触消费者成员的函数可以使用消费者命名空间，只应该接触生产者成员的函数可以使用生产者命名空间，而需要接触两者的函数必须明确限定它们。在仅使用生产者命名空间的函数中，无法意外触及消费者变量。

在这种情况下，希望纯粹是为了减少事物的生产者和消费者副本之间的命名冲突，而减少命名冲突是命名空间存在的目的。出于这个原因，我支持能够在类中声明命名空间的提议。

原文由 ErsatzStoat 发布，翻译遵循 CC BY-SA 3.0 许可协议