包括 .cpp 而不是 header(.h)
Posted
技术标签:
【中文标题】包括 .cpp 而不是 header(.h)【英文标题】:Include .cpp instead of header(.h) 【发布时间】:2012-03-04 10:58:36 【问题描述】:在某些情况下,我们包含 .cpp 文件而不是标准头文件 (.h),例如:
#include "example.cpp"
而不是
#include "example.h"
这似乎有效,但这是安全的还是我应该避免它?
编译时间呢?
【问题讨论】:
它和你做的一样安全。通常不需要。编程不是盲目地跟随某架货机,而是理解你在做什么,并根据理解和推理做出决定。 我见过这样做的唯一正当理由是节省链接时间。 Unity Build is explained here. @sysop:正如我所说:了解你在做什么,并首先询问。 预处理器 处理包含,早在任何编译发生之前。了解预处理器,你就会知道什么时候可以包含东西。 【参考方案1】:这是懒惰的编码。使用头文件。是的,它们可以增加编译时间,但它们意味着您可以轻松地重新实现代码块,或者更好的是,其他开发人员可以随时重新实现。头文件用作C/C++
代码将要执行的操作的模板。丢弃或忽略它是个坏主意。
【讨论】:
我总是使用 .h,但我们在这里有很多争论,这就是我问的原因。 @sysop -- 公平地说,“这是惰性编码”有点夸张。在某些情况下,它实际上可能是正确的做法,但在一般情况下,我认为这是一种糟糕的形式。 包含.h
文件而不是.cpp
文件可以加快编译时间,因为它可以让您进行部分重新编译。【参考方案2】:
我同意 Kerrek SB。
我做过一次。我正在构建一个出色的、广泛使用的压缩库,它需要为 8 位图像和 12 位图像分别构建。我能想出的最简洁的方法是(过于简单化)有两个主 .cpp 文件,一个为 8 位构建设置 #defines,另一个为 12 位构建。然后主 .cpp 文件#included 压缩库的源文件。
如果您对一般规则有足够的了解以了解其原因以及它可能不适用于您的情况,则可以不遵守一般规则。 (但这种情况应该很少见。)
【讨论】:
【参考方案3】:#include "impl.cpp"
有合法用途:
测试对静态/等变量的访问
如果 c++ 模板机制被证明不合适(罕见),则类似这样的临时模板
#define MACRO (...)
#include "impl.cpp" // uses MACRO
请注意,#include "impl.cpp"
可能是不安全的,因为相同的文件包含在稍后链接在一起的单独编译单元中。
【讨论】:
【参考方案4】:我以前用过,没问题,但我不能确保它是安全的。有时这对我来说是唯一的选择,所以我使用了它,否则我将使用 .h 文件。
【讨论】:
总有另一种选择,也就是永不言败。以上是关于包括 .cpp 而不是 header(.h)的主要内容,如果未能解决你的问题,请参考以下文章