C++ 中的前向声明- 什么时候有关系？

Question

我认为这是 C++ 的精神——你不为你不做的事付出代价 想要（你明确地为你需要的东西付费）：

// a.h
#include <iosfwd>

template< class T >
class QVector;

struct A
{
void process( QVector<int> );

void print( std::ostream& );
};

// some.cpp

#include "a.h"

#include <iostream> // I need only A::print() in this module, not full interface

...
A().print( std::cout );
...

这就是为什么我认为禁止开发人员工作是不公平的 这样使用STL（ C++11 STL 是否有前向声明文件？）。

但我也看到一件坏事：模块 A 的依赖项 将在外部上下文中传播（#include指令的重复），并且可能导致硬重构 当界面发生变化时（例如，将 QVector 替换为 QList - 现在您需要将所有出现的 替换为 ）。

这个问题的解决方案是：

#include <iostream>
#include <QVector>

struct A
{
void process( QVector<int> );

void print( std::ostream& );
};

我们是否应该将此称为习语“接口的基本类型” - 模块 接口的类型应该像基本类型一样（总是 已定义且可用）？也有道理，但还是不太明白 什么方法更好（例如Qt混合了两种方法）。

我个人的决定 - 始终提供两种方式以获得更好的模块化（当我们有足够的依赖项时）：

// a_decl.h
#include <iosfwd>

template< class T >
class QVector;

struct A
{
void process( QVector<int> );

void print( std::ostream& );
};

// a.h
// Include this file if you want to use most interface methods
// and don't want to write a lot of `#include`
#include <iostream>
#include <QVector>

#include "a_decl.h"

并让开发人员选择要包含的内容。

对于这些方法您有什么想说的？哪种方式更适合您？为什么？我们是否在所有情况下都有一个明显的赢家，还是总是取决于具体情况？

来自我与语言创建者的通信（我没有收到最终答案）

更新：

Boost 1.48.0 带来了容器库，它允许定义未定义用户类型的容器（ 了解更多 ）。

Answer 1

C++ 是一种给程序员留下很多自由度的语言，因此不可避免地有不同的方法来做同一件事。

IMO，您定义的“解决方案”，即在任何 .h 文件中包含所有必要的包含或前向声明，是避免“不完整的头文件”的方法，我一直遵循这条规则。

有一本有趣的书，全面讨论了这样做或不这样做的所有利弊：John Lakos 的《Large-Scale C++ Software Design》，上面的规则就来自于此。

具体谈到前向声明，Lakos 区分了“仅在名称中”和“在大小中”类用法；只有在第二种情况下（根据他的意见）使用前向声明才是合法的：

定义：如果编译 f 的主体需要首先查看 T 的定义，则函数 f 使用类型 T 大小。

定义：如果编译 f 以及 f 可能依赖的任何组件不需要首先查看 T 的定义，则函数 f 仅在名称上使用类型 T。

(来源）

具体来说，Lakos 的推理围绕着以下含义：大规模系统（即具有一定复杂性的系统）的某些 C++ 编程风格，但我认为他的建议也非常适合任何规模的系统。

希望他的帮助。

Answer 2

我认为两者都是正确的方法。

创建前向标头很简单，并且是库维护者的主要责任。

然后，开发人员/客户可以根据他/她的需要选择使用前向标头或物理标头。

在可能的情况下，大型项目肯定会青睐并受益于前向标头。

包含物理标头并不能真正解决依赖性问题，但在许多情况下会引入新的依赖性。例如“如果我从这个标头中删除 #include ，那么某些编译将会失败（并且可能会因您正在使用的库及其平台差异而异）。

我认为一个好的库维护者< em>应该提供前向标头，因为其他人根据平台、版本等维护任何差异和更新是一件痛苦的事情。当项目变得足够大时，就会有一个明显的赢家 - 两者兼而有之，你总是有选择。