减少cpp文件中包含的数量 [英] Reducing the number of includes in a cpp file

查看:130
本文介绍了减少cpp文件中包含的数量的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前有大约50个或更多的包含在我的cpp文件。我想知道什么是组织这种情况的最佳政策。我应该继续添加更多包括?或者我应该采取另一种方法?

解决方案

1)将每个文件的范围限制为一个类,



如果你的cpp文件只有400到1000行代码,很难要求几十个



此外,当您移动和修改时,请重新评估每个文件中包含的标题。如果你最初使用向量实现了一些东西,然后切换到设置,请考虑删除#include<向量>



2)在头文件中,使用向前声明,将这些包含到cpp文件中。

这不直接解决你的问题,但它在管理编译时间是相关的。



如果ah包含bh且bh包含ch,则每当ch更改时,包括ah在内的任何内容都必须重新编译。将这些包括到.cpp文件(通常不包括#included)将限制这些级联更改。



让我们重新评估如果ah向前声明类在bh中定义,并且a.cpp包括bh,并且如果bh向前声明在ch中定义的类,并且b.cpp包括ch



当ch改变时,b.cpp需要重新编译,但a.cpp很好。



3)在扩展功能时重新组织 b

写代码可能会出现这样的情况:


  1. 计划实现某项功能。

  2. 编写代码以支持该计划。 (如果进行单元测试,请考虑先编写测试)

  3. 调试并确保代码符合您的要求。

但这里缺少了一些可以带来巨大改变的步骤。


  1. 重构你的代码,包括。 (这里是单元测试帮助的地方。)

  2. 再次调试


b $ b

最后两个步骤可能涉及将大型函数拆分为几个较小的函数,打破类,并且(与这个问题相关)创建新文件以扩展其当前编译单元的功能。



如果你在你的代码似乎工作的时候移动,不需要花一点时间来整理它就相当于一个木匠把腿踩到表,但从来没有花一点时间砂和抛光的结果。有时,可以有一块胶合板,有一些腿,但如果你想要一个漂亮的餐厅桌子,你会发现这种方法是不是由任务。






没有简单的方法来减少包含的cpp文件,最终那些包括需要存在某处(假如原来的代码依赖这些包括仍然存在,如果没有,然后只需删除无关的include),而.cpp文件比.h文件更好。但是通过仔细的管理和组织,您可以维护更小,更模块化的源代码。这是最终如何防止事情变得不可行。


I currently have about 50 or more includes in my cpp file. I wanted to know whats the best policy of organizing this situation. Should I continue adding more includes ? or should I take another approach ? If so what should that be ?

解决方案

1) Limit the scope of each file to one class, or to a small group of related classes with related behavior.

If your cpp file is only 400 to 1000 lines of code, it'll be pretty hard to require dozens of includes.

Also, as you move things around and make modifications, re-evaluate headers included in each file. If you originally implemented something using a vector, but then switched to set, consider removing the #include < vector >

2) In header files, use forward declarations, move those includes to the cpp file.

This doesn't address your question directly, but it is related in managing compile time. If you can get away with a forward declaration in a header file, do that.

If a.h includes b.h and b.h includes c.h, whenever c.h changes, anything including a.h has to recompile as well. Moving these includes to the .cpp file (which isn't typically #included) will limit these cascading changes.

Let's re-evaluate what happens if a.h forward-declares classes defined in b.h, and a.cpp includes b.h, and if b.h forward-declares classes defined in c.h, and b.cpp includes c.h.

When c.h changes, b.cpp needs to recompile, but a.cpp is fine.

3) Re-organize as you extend functionality.

Writing code can happen like this:

  1. Plan to implement a feature.
  2. Write code to support that plan. (If doing unit testing, consider writing the test first)
  3. Debug and ensure the code meets your requirements.

But this is missing a few steps that make a huge difference.

  1. Refactor your code, and remove extraneous includes. (Here's where unit testing helps.)
  2. Debug again.

These last two steps can involve splitting up large functions into several smaller ones, breaking classes up, and (relevant to this question) creating new files for functionality which has out-grown its current compilation unit.

If you move on the moment your code seems to work and do not take a moment to tidy up it is the equivalent of a carpenter hammering legs onto a table, but never taking a moment to sand and polish the result. Sometimes it's okay to have a slab of plywood with some legs, but if you want a nice dining room table, you'll find this approach is not up to the task.


There is no simple way of reducing includes for cpp files, ultimately those includes need to exist somewhere (provided the original code relying on those includes is still present, if it is not, then simply delete the extraneous include), and the .cpp file is way better than the .h file. But with careful management and organization you can maintain smaller, more modular source code. This is ultimately how you keep things from becoming unworkable.

这篇关于减少cpp文件中包含的数量的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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