【问题标题】:Should one forward declare classes from a namespaced library?是否应该前向声明命名空间库中的类?
【发布时间】:2015-06-16 11:00:02
【问题描述】:

我正在设计一个 C++ 库,它将放置在命名空间中。

如果我的库的用户只需要我的一个类的前向声明,并且由于您不能对命名空间内的事物进行前向声明,例如class ns_name::class_name;,我应该吗

  • 告诉他们改为包含包含该类的整个头文件,
  • 或者,为他们提供一种从我的库中转发声明内容的方法?例如:

    #define MD_FORWARD_DECLARE(x) namespace md { x; }
    

    然后可以这样使用:

    MD_FORWARD_DECLARE(class foo)
    

    值得吗?

  • 或者,让他们自己做namespace md { class foo; }
  • 或者,如DevSolar 所述,制作一个包含前向声明的专用头文件,如<iosfwd>?这对我来说似乎最优雅。

【问题讨论】:

  • 让他们为所欲为。这个宏对我来说似乎不是很有用。
  • 您不能在命名空间中前向声明某些东西? <iosfwd> 让我觉得你真的可以...
  • @DevSolar 这是个好主意。我以前怎么不知道<iosfwd>……我会把它作为第四选择添加到我的问题中。
  • 选项 3。namespace md { class foo; } 命名空间内事物的前向声明。
  • @molbdnilo 是的,但它看起来很尴尬,就好像你正在向一个不属于你的命名空间添加新内容一样。我个人觉得宏解决方案比这更有吸引力。

标签: c++ namespaces forward-declaration


【解决方案1】:

正如@molbdnilo 指出的那样,使用命名空间前向声明没有任何问题。第一个选项根本不是一个选项,由于各种原因,我不想包含标题,直到我必须这样做,前向声明始终是首选方式。 为什么不像许多 boost 实现那样只提供带有前向声明的标题?比如提升精神 numerics_fwd.hpp?

啊,错过了@DevSolar 评论。恕我直言,这是最好的解决方案。

【讨论】:

  • 我可能会采用 STL 方式,即包含整个标题而不是前向声明。如果编译时间成为问题,我会写<numerics_fwd.hpp>
猜你喜欢
  • 2012-12-27
  • 1970-01-01
  • 1970-01-01
  • 2012-12-15
  • 1970-01-01
  • 1970-01-01
  • 2023-03-06
  • 2015-05-10
  • 1970-01-01
相关资源
最近更新 更多