包括所有内容,与“使用”分开

时间:2011-03-01 05:06:08

标签: c++ api api-design

我正在开发一个C ++库。它让我想到了Java和C#处理的方式,包括库的不同组件。例如,Java使用“import”来允许使用来自其他包的类,而C#只使用“using”来导入整个模块。

我的问题是,在一个大型包含中#include库中的所有内容,然后只使用using指令导入特定的类和模块,这是一个好主意吗?或者这只是疯了吗?

修改 到目前为止反应良好,这里有一些缓解因素我觉得这个想法增加了:

1)内部#includes保持正常(简短到点)
2)包含所有内容的文件可选择随图书馆一起提供给想要使用它的人 3)你可以选择大包括预编译头文件的文件部分

5 个答案:

答案 0 :(得分:5)

你在C ++中混淆了#include语句的目的。它们的行为与Java中的import语句或C#中的语句不同。 #include按照说法行事;即,加载并解析整个指示文件作为当前翻译单元的一部分。单独包含的原因是不必花费编译时间来解析每个文件中的整个标准库。相反,您尝试使#include表达的语句仅用于程序员组织目的。

#include用于管理编译过程;不适用于分离用途。 (事实上​​,你不能使用单独的标题来强制执行单独的使用,因为这样做会违反一个定义规则)

tl; dr - >不,你不应该这样做。 #include尽可能少。当你的项目变得很大时,当你没有等待很多时间来编译你的项目时,你会感激不尽。

答案 1 :(得分:2)

我个人建议只在您需要时才包含标题,以明确显示您的文件需要哪些功能。同时,这样做会阻止您访问您可能不一定需要的功能,例如与文件目标无关的功能。当然,这没什么大不了的,但我认为当你无法访问不必要的函数/类时,维护和更改代码会更容易;它只是让它更直接。

答案 2 :(得分:1)

我可能会因此而被投票,但我认为你提出了一个有趣的想法。它可能会减慢编译速度,但我认为这个概念很简洁。

只要您谨慎地使用using - 仅用于您需要的命名空间 - 其他开发人员可以通过浏览顶部来了解文件中使用的类。它不会像看到#include d文件列表一样精细,但是看到包含的头文件列表真的非常有用吗?我不这么认为。

当然,请确保所有标头文件都使用inclusion guards。 :)

答案 3 :(得分:0)

如@Billy ONeal所说,主要的是#include是一个预处理器指令,它导致编译的“^ C,^ V”(复制粘贴)导致编译时间增加。

C ++中考虑得最好的策略是在“.h”文件中转发声明所有可能的类,并将它们包含在“.cpp”文件中。它隔离了依赖关系,因为如果依赖包含文件被更改,C / C ++项目将被级联重建。

当然,M $编译器及其预编译的头文件往往会反过来,包含在你建议的内容中。但是那些试图在这些编译器上移植代码的人都非常清楚它有多么臭。

像Qt这样的一些库广泛使用了前向声明。看看它是否喜欢它的味道。

答案 4 :(得分:0)

我认为这会令人困惑。当你编写C ++时,你应该避免使它看起来像Java或C#(或C :-)。我真的很想知道你为什么这么做。

提供include-all文件也不是真的有用,因为用户可以轻松地创建一个,实际使用库的部分。然后可以添加到预编译的头文件中,如果使用的话。