包含所有内容，用“使用”分开

我正在开发一个C++库。这让我想到了Java和C＃处理包含库的不同组件的方式。例如，Java使用“导入”来允许使用其他包中的类，而C＃只是使用“使用”来导入整个模块。包含所有内容，用“使用”分开

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

编辑： 良好的反应，到目前为止，这里有一些缓解因素，我觉得到这个念头：

1）内部的#includes保持正常（短和对点）
2）的文件，其中包括一切任选库提供给那些谁愿意使用它
3）你可以任意让大包括预编译头文件的一部分

2011-03-01 Dave

如果您限定名称，例如'new java.util.LinkedList （）'，您可以使用Java *中不带*进口的其他包中的类。 Java的'import'更像C++的''using''，Java没有任何类似于C++''include'预处理指令的东西。 – fredoverflow 2011-03-01 08:47:32

您在C++中混淆了#include语句的用途。它们的行为不像Java中的import语句或在C＃中使用语句。 #include做了什么;即加载并解析整个指示文件作为当前翻译单元的一部分。单独包含的原因是不必花费编译时间解析每个文件中的整个标准库。相反，您试图使#include表现得像这样的陈述仅仅是为了程序员组织的目的。

#include是用于管理编译过程;不用于分离用途。（事实上，你不能使用单独的头来强制单独使用，因为这样做会违反一个定义规则）

tl; dr - >不，你不应该那样做。 #include尽可能少。当你的项目变大时，当你没有等待几个小时来编译你的项目时，你会感谢你自己。

来源

2011-03-01 05:24:29

+1为tl; dr :) – 2011-03-01 05:27:21

您提出了一些优点。我将我的评论添加到编辑部分。但是，我会告诉你一个很好的旧Windows.h，你最终只能使用一小部分，但却被迫将所有的东西都包括在内，这使得编译需要更长的时间。 – Dave 2011-03-01 05:57:53

@Dave：我不能多说''这么大头的原因。不过，我相信其原因是因为它允许重构Windows SDK中的头文件而不破坏客户端程序。（例如，Vista的SDK经历了大量的头文件更改，但用户程序'#include '仍然编译得很好。） – 2011-03-01 15:23:11

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

来源

2011-03-01 05:15:15

我可能会因此而失望，但我认为你会提出一个有趣的想法。这可能会减慢编译速度，但我认为这个概念很整洁。

只要你谨慎地使用了using--只为你需要的命名空间 - 其他开发者可以通过浏览顶部来了解文件中使用了哪些类。它不会像看到一个#include d文件列表一样细致，但看到包含的头文件列表真的非常有用吗？我不这么认为。

只要确保所有头文件都使用inclusion guards，当然。 :)

来源

2011-03-01 05:19:37 ClosureCowboy

正如@Billy ONeal所说，最重要的是#include是一个预处理程序指令，它会导致代码的“^ C，^ V”（复制粘贴），从而增加编译时间。

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

当然，M $编译器及其预编译头文件往往会做相反的事情，并附上您的建议。但是任何试图在这些编译器上移植代码的人都非常清楚它是如何发臭的。

像Qt这样的图书馆广泛使用前向声明。看看它，看看你是否喜欢它的味道。

来源

2011-03-01 17:51:43 j4x

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

提供一个包含所有文件实际上也没有什么帮助，因为用户可以很容易地自己创建一个，实际使用库的部分。然后可以添加到预编译头中，如果使用了。

来源

2011-03-01 18:38:19

包含所有内容，用“使用”分开

回答

相关问题