使用C++头(H)vs头文件加上实现(H + + CPP),缺点是什么?

在C++中,有两种方法可以分离这两种帮助。首先,如果你想在不改变接口的情况下更新一个库,那么C++文件中的代码意味着你只需更新库而不是库加头。其次,它隐藏了实现。也就是说,它强制人们只从接口的角度来看待你的类,如果代码写得很好,那么这个问题应该引起他们的关注。最后,这个分离附带的Interface+文档有一种微弱的清洁性。这是你必须习惯的事情,但过了一段时间你会觉得很自然(意见)。

不要忘记构建时间。

将实现代码放在头文件中会使它们更容易被更改。并且更改头文件将导致包括这些头文件的所有cpp文件的重建,从而增加生成时间。这在大型项目中可能很重要。

我也很喜欢将实现隐藏在我的库的用户面前。不幸的是,这对模板类不起作用。

我的经验法则是:将声明保存在.h文件中,将定义保存在.cpp文件中。

如果你想将C++与已经编译的二进制文件(典型地使用库时)相结合,那么在一个地方定义符号是比较酷的。假设您需要为二进制文件中的全局内容定义外部符号。如果在同一个文件中有.cpp和.h代码,则必须为每个此类文件定义二进制文件的符号。以两个文件的方式,您可以只拥有一个.h,其中包含二进制文件的定义,以及许多使用它的.cpp文件。

主要的区别在于 .h 文件将放在每个包含该头的编译单元中,这将在编译阶段创建冗余。 在最终的二进制可执行文件中 …与…分开时 h 和 .cpp 将在一个单独的对象文件中编译它,该文件稍后通过只包含一个实现头文件的已编译二进制代码与其他对象文件链接。

此外,如果您在 h 你不能在其他人之间共享变量和结构 CPP 文件夹。。

有趣的是,C类似乎在C/C++方向上有一定的进展,最近引入了部分类。

在IDE中,这一点的特殊优势在于,Visual Studio设计器将修改处理可视化控件或数据成员的类部分及其布局,而不必担心弄脏驻留在单独文件中的方法(应用程序逻辑)。

我会回应@wheaties并添加一些其他项目

1. 编译更容易(可能只有我一个人),如果您只修改头(就像所有包含它的实现文件一样),我就永远无法使编译工作正常。我相信makefiles需要手动添加依赖项,这在非常大的项目中是一个真正的痛苦(同样可能只有我自己)。所以,如果您在实现文件中有代码,那么更改仅仅意味着重新编译那个特定的文件——当您想要快速更改、构建和测试时非常有用。

2. 让我重复一下隐藏方面,由于代码的敏感特性,您通常不希望人们知道实现的细节,因此只公开头部和预构建的库,分离在这里是关键。

3. 前向声明,如果头文件中的任何代码中没有“使用”,则不需要在头文件中包含类的实现细节,但在实现文件中可以包含真正的头文件和“它都很好地工作”(如果有cycli,则有助于c依赖项-为什么会有它们是不同的问题!)

在最近的一个大型项目中,我想使用的系统的作者在.h文件中放置了大量代码。当将它们的.h文件包含到我自己的源代码中时,它会向我的文件添加更多的依赖项。在包含了他们项目的依赖项之后,我最终遇到了typedef冲突。如果他们把代码分开,只把声明放在.h文件中,就会简单得多。我建议使用POSIX类型,并且只将声明放入.h文件中。

我看到很多响应都提倡分离,主要是为了构建时间和实现隐藏好处。这两个都是肯定的优点,不过我要说的是反例: Boost .

大多数Boost库使用 .hpp 没有外部链接的文件。原因是在模板的情况下通常需要这样做,此时编译器必须从调用例程中知道参数类型。因此,如果你想坚持“现代”C++的方法来回避类的模板,那么你可能没有选择。

至于比较部分 .cs 对战 .cpp / .h 我认为你需要记住背景,首席建筑师C: Anders Hejlsberg . 在Delphi中,您也没有头和模块的区别(在讨论中忽略了包含文件)。在一个单元文件中只包含两个部分 initialization 和 implementation .

其他几点已经提到了。