减少大型项目的构建时间。 [英] Reducing build-times for large projects.
问题描述
我已阅读Exceptional C ++的第26项。这解释了一种最小化编译时依赖关系的方法，因此提高了编译速度。
该过程涉及用forward替换#include指令
来自头文件中的声明。
但是，可能有大量源文件可能依赖于删除的#include指令当下。因此，由于
修改和缺失而导致大量源文件无法编译，因此很可能是b $ b。 #include指令必须插入
中。这是一种痛苦。
这是一个例子。源文件Z.cpp包含Y.h. Yh中定义的函数是
内联。
// Xh
#include< iostream>
struct {void f（）{std :: cout<<英寸×:: F" <<的std :: ENDL;
// Yh
#include" X.h"
inline void y（X x）{ XF（）; }
// Z.cpp
#include" Y.h"
int main（）
{
y（X（））;
返回0;
}
当我们使用前向声明来删除Yh对Xh的依赖时，我们看到Z.cpp必须包含Xh，因为main调用X :: X（）。所以Z.cpp比以前更快地编译
。我们可能已经将依赖存在于
存在并为自己节省了所有额外的工作。
// Xh（和以前一样）
// Yh
class X;
void y（X x）;
// Y.cpp
#include" X.h"
void y（X x）{xf（）; }
// Z.cpp
#include" Y.h"
#include" X.h"
//（和以前一样休息）
这个例子说明最小化编译时间并不总是付出代价
依赖。这是个问题。你如何判断应该（或不应该）删除
依赖关系？任何想法都值得赞赏。
I have read item 26 of "Exceptional C++" that explains a way of minimising
compile-time dependencies and, therefore, a way to improve compile speeds.
The procedure involves replacing #include directives with forward
declarations from within header files.
However, a potentially large number of source files may have previously
relied on the removed #include directives being present. Therefore it is
likely that a large number of source files will not compile as a result of
the modification and the "missing" #include directives must be inserted into
each of them. This is a pain.
Here is an example. The source file Z.cpp includes Y.h. The function defined
in Y.h is inlined.
// X.h
#include <iostream>
struct { void f() { std::cout << "X::f" << std::endl; } };
// Y.h
#include "X.h"
inline void y(X x) { x.f(); }
// Z.cpp
#include "Y.h"
int main()
{
y(X());
return 0;
}
When we use a forward declaration to remove the dependency of Y.h on X.h, we
see that Z.cpp must include X.h because main calls X::X(). So Z.cpp compiles
no faster than before. We might as well have left the dependency in
existence and saved ourselves all the extra work.
// X.h (as before)
// Y.h
class X;
void y(X x);
// Y.cpp
#include "X.h"
void y(X x) { x.f(); }
// Z.cpp
#include "Y.h"
#include "X.h"
// (rest as before)
The example shows that it doesn''t always pay to minimise compile-time
dependencies. Here is the question. How do you make a judgement on what
dependencies should (or should not) be removed? Any thoughts are
appreciated.
推荐答案
我认为你有前向声明的概念错误。这个想法是
____________
// Xh
class X {};
// Yh
#include" X.h"
void foo（X * t）;
______________
可以替换为
____________
// Xh
class X {};
// Yh
class X;
void foo（X * t）; < br $>
______________
这是因为Y不需要知道X类的布局。但是在下面的
例子中你无法转发声明X为foo通过
值传递X.如果你做了你做的事。在每个cpp文件中，你必须在Y.h之前包含X.h
。这对于一个大型项目来说是一个坏主意
因为人们必须记住标题需要包含的订单。
包含在内。
_________________
// Xh
class X {};
// Yh
#include" X.h"
void foo（X t）;
______________
如果你想要加快编译速度。看看你的编译器是否支持一些预编译的头文件并使用它。不要使用太多的内联
函数。使用常规函数时，只有原型更改才会触发
重建。但是使用内联函数甚至更改函数体将会触发重建。
Raj
I think you have the concept of forward declaration wrong. The idea is
____________
// X.h
class X{};
//Y.h
#include "X.h"
void foo( X* t);
______________
can be replaced to
____________
// X.h
class X{};
//Y.h
class X;
void foo( X* t);
______________
This is because Y doesnt need to know the layout of class X. But in the
below example you cannot forward declare X as foo is passing X by
value. If you do what you have done. You will have to include X.h
before Y.h in every cpp file. This is a bad idea as on a large project
as people would have to remember what order the headers need to be
included in.
_________________
// X.h
class X{};
//Y.h
#include "X.h"
void foo( X t);
______________
If you want to speed up compilation. See if you compiler supports some
sort of precompiled headers and use that. Dont use too many inline
functions. With regular functions only a prototype change triggers a
rebuild. But with inline functions even changing the function body will
trigger rebuilds.
Raj
Jason Heyes写道：
Jason Heyes wrote:
但是，之前可能有大量源文件可能依赖于已删除的#include指令。因此，很可能由于修改和丢失而导致大量源文件无法编译。 #include指令必须插入到每个指令中。这是一种痛苦。
痛苦，也许，但好软件恕我直言。
在大项目中你绝对必须，必须减少耦合或链接
头文件随时随地。当然，需要查看完整声明的源文件
必须包含他们需要的标题
文件。这是一件好事 - 它让你知道他们正在抓住的东西是什么，而不必去浏览一下
zillion链接头文件。
此外，它*将*节省您编译源文件的时间，而不是
需要完整的声明。由于它们包含的标题将更简单，而不是链接到一堆无关的标题，它们将更快地编译
。
预编译的头文件和小到中等大小的项目会使许多程序员陷入懒惰的做法。然后你用几千个源文件点击一个带有几个b
百万SLOC的项目，突然之间它需要花费几个小时建造......： - （
这个例子表明，最小化编译时的依赖关系并不总是有效。这就是问题。你如何判断
依赖应该是什么（或者不应该）被删除？任何想法都会受到赞赏。
However, a potentially large number of source files may have previously
relied on the removed #include directives being present. Therefore it is
likely that a large number of source files will not compile as a result of
the modification and the "missing" #include directives must be inserted into
each of them. This is a pain.
A pain, maybe, but good sofware IMHO.
In big projects you absolutely must, must reduce coupling or chaining of
header files whenever and where ever possible. Sure, the source files
that need to see the full declarations will have to include the header
files that they need. This is a good thing - it lets you know what
they''re grabbing right there - without having to go grovelling through a
zillion chained header files.
Also, it *will* save you time on compiles of source files that do not
need the full declarations. Since the headers they include will be
simpler, not chained to a bunch of extraneous headers, they will compile
faster.
Precompiled headers and small to modest sized projects lull far to many
programmers into lazy practices. Then you hit a project with a few
million SLOC with a few thousand source files and all of a sudden it''s
taking hours to build... :-(
The example shows that it doesn''t always pay to minimise compile-time
dependencies. Here is the question. How do you make a judgement on what
dependencies should (or should not) be removed? Any thoughts are
appreciated.
相反，我会说最小化它总是要付出代价。 >
编译时依赖项。即使你没有立即看到或者b / b
令人印象深刻的编译时间减少。这很有意义，而且它是
减少文件和编译单元之间的耦合。
On the contrary, I would say that it does always pay to minimize
compile-time dependencies. Even if you don''t see an immediate or
impressive reduction in compile times. It makes good sense, and it
reduces coupling between files and compilation units.
" Phil Staite"< ph ** @ nospam.com>写在消息中
news：42 ************** @ nospam.com ...
"Phil Staite" <ph**@nospam.com> wrote in message
news:42**************@nospam.com...
Jason Heyes写道：
Jason Heyes wrote:
这个例子显示了t帽子并不总是为了最小化编译时的依赖性而付出代价。这是个问题。你如何判断应该（或不应该）删除哪些依赖关系？任何想法都表示赞赏。
The example shows that it doesn''t always pay to minimise compile-time
dependencies. Here is the question. How do you make a judgement on what
dependencies should (or should not) be removed? Any thoughts are
appreciated.
相反，我会说最小化编译时依赖性总是值得的。即使您没有看到编译时间立即或显着减少。这很有道理，它减少了文件和编译单元之间的耦合。
On the contrary, I would say that it does always pay to minimize
compile-time dependencies. Even if you don''t see an immediate or
impressive reduction in compile times. It makes good sense, and it
reduces coupling between files and compilation units.
感谢您的出色回复。
内联函数随着编译时依赖性的最小化而消失。你认为这是一个值得担心的问题吗？程序性能是否会因为编译速度而受到损害？
Thanks for your excellent reply.
Inline functions go away as compile-time dependencies are minimised. Do you
see this as an issue worth worrying about? Will program performance be
compromised in favour of compilation speed?
这篇关于减少大型项目的构建时间。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
