前向声明对编译时间有多少影响? [英] How much do forward declarations affect compile time?

查看:197
本文介绍了前向声明对编译时间有多少影响?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我对一些研究或经验数据非常感兴趣,它们显示两个相同的c ++项目之间的编译时间的比较,除非一个使用可能的前向声明,另一个使用无。



与完整包含相比,转发声明会如何改变编译时间?

  #includemyClass.h 

vs。

  class myClass; 

有没有任何研究来检查这个问题?



我意识到这是一个模糊的问题,很大程度上取决于项目。我不期望一个硬数字的答案。相反,我希望有人能够指导我对此进行研究。



我特别担心的项目有大约1200个文件。每个cpp平均有5个头。每个报头平均包含5个报头。这回退约4级深。看来,对于每个cpp编译,大约300个标头必须打开和解析,有时多次。 (包含树中有很多重复项。)有保护,但文件仍然打开。每个cpp单独编译gcc,所以没有标题缓存。



为了确保没有人误解,我当然主张在可能的情况下使用forward声明。我的雇主,但是,已经禁止他们。

解决方案

感谢您提供任何信息。 / div>

转发声明可以使得更容易理解的代码成为任何决定的目标。



对类来说,它有很多可能使2个类依赖于彼此,这使得它有点难以使用前进声明,而不会导致噩梦。



标题意味着您只需要在实际使用这些类的CPP中包括相关的标头。这实际上是DECREASES的编译时间。



编辑:给出上面的评论我会指出,包括一个头文件总是慢于转发宣布。任何时候,你包括一个头,你需要从磁盘加载经常只发现,头守卫意味着什么都没有发生。



编辑2 :硬数据相当难,因为它是一个非常愚蠢的规则。获得。有趣的是,我曾经做过一个项目,不是严格的头文件包括和构建时间大约45分钟在一个512MB RAM P3-500Mhz(这是一个回来)。在花了2个星期削减包括噩梦(通过使用远期声明)后,我设法得到的代码在4分钟内建立一点。

编辑3 :它也值得记住,使用forward有一个巨大的优势当涉及到对你的代码进行小的修改声明。如果头文件包含在整个商店,那么对头文件的修改可能会导致大量的文件被重建。



我也注意到许多其他人赞美美德的预编译头(PCH)。他们有自己的位置,他们真的可以帮助,但他们真的不应该被用来作为正确的前瞻性声明的替代。否则对头文件的修改可能会导致重新编译大量文件(如上所述)以及触发PCH重建的问题。 PCH可以为预构建的库提供大的胜利,但他们没有理由不使用正确的前瞻性声明。


I am very interested in some studies or empirical data that shows a comparison of compilation times between two c++ projects that are the same except one uses forward declarations where possible and the other uses none.

How drastically can forward declarations change compilation time as compared to full includes?

#include "myClass.h"

vs.

class myClass;

Are there any studies that examine this?

I realize that this is a vague question that greatly depends on the project. I don't expect a hard number for an answer. Rather, I'm hoping someone may be able to direct me to a study about this.

The project I'm specifically worried about has about 1200 files. Each cpp on average has 5 headers included. Each header has on average 5 headers included. This regresses about 4 levels deep. It would seem that for each cpp compiled, around 300 headers must be opened and parsed, some many times. (There are many duplicates in the include tree.) There are guards, but the files are still opened. Each cpp is separately compiled with gcc, so there's no header caching.

To be sure no one misunderstands, I certainly advocate using forward declarations where possible. My employer, however, has banned them. I'm trying to argue against that position.

Thank you for any information.

解决方案

Forward declarations can make for neater more understandable code which HAS to be the goal of any decision surely.

Couple that with the fact that when it comes to classes its quite possible for 2 classes to rely upon each other which makes it a bit hard to NOT use forward declaration without causing a nightmare.

Equally forward declaration of classes in a header means that you only need to include the relevant headers in the CPPs that actually USE those classes. That actually DECREASES compile time.

Edit: Given your comment above I would point out it is ALWAYS slower to include a header file than to forward declare. Any time you include a header you are necessitating a load from disk often only to find out that the header guards mean that nothing happens. That would waste immense amounts of time and is really a VERY stupid rule to be bringing in.

Edit 2: Hard data is pretty hard to obtain. Anecdotally, I once worked on a project that wasn't strict about its header includes and the build time was roughly 45 minute on a 512MB RAM P3-500Mhz (This was a while back). After spending 2 weeks cutting down the include nightmare (By using forward declarations) I had managed to get the code to build in a little under 4 minutes. Subsequently using forward declarations became a rule whenever possible.

Edit 3: Its also worth bearing in mind that there is a huge advantage from using forward declarations when it comes to making small modifications to your code. If headers are included all over the shop then a modification to a header file can cause vast amounts of files to be rebuilt.

I also note lots of other people extolling the virtues of pre-compiled headers (PCHs). They have their place and they can really help but they really shouldn't be used as an alternative to proper forward declaration. Otherwise modifications to header files can cause issues with recompilation of lots of files (as mentioned above) as well as triggering a PCH rebuild. PCHs can provide a big win for things like libraries that are pre-built but they are no reason not to use proper forward declarations.

这篇关于前向声明对编译时间有多少影响?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆