通过预编译头文件来提高CB的编译速度
有一种朋友不在生活里,却在生命力;有一种陪伴不在身边,却在心间。图老师即在大家的生活中又在身边。这么贴心的服务你感受到了吗?话不多说下面就和大家分享通过预编译头文件来提高CB的编译速度吧。
为什么delphi会比c++builder快这么多?是否有方法来c++builder的编译速度?本文就讲解了为什么C++的编译器速度会慢,并且介绍了一个简单的方法来减少c++builder的编译时间。
为什么c++编译器的速度会慢?
c++builder 使用者怎么通过预编译头文件来减少编译时间?
讲解基于VCL可视化工程的预编译头文件方法
优化c++builder对预编译头文件的使用
结论
注重事项
为什么c++编译器速度慢?
在C++中,你只能使用预定义或是预先声明了的函数,这意味什么?来看一个简单的例子,函数A()调用函数B(),函数A()只能在函数B()的原型或是函数体在A()之前才能调用它。下面的例子说明了这一点:
// declaration or prototype for B
void B();
void A()
{
B();
}
// definition, or function body of B
void B()
{
cout "hello";
}
没有B()的原型,这个代码不会编译通过的,除非函数B()的函数体移到函数A()之前。
对于编译器来说,函数的原型很重要。当你运行程序时,编译器都要插入恰当的代码来调用程序。编译器必需知道要有多少个参数传给函数。也要知道函数的参数应该在栈里还是在寄存器里。总而言这,编译器必需知道怎么来产生正确的代码来调用这个函数,这就要求编译器必需知道预先声明或定义了的被调用的函数。
为使函数或类的原型简单化,C++提供了一个#include 指令。#include代表答应源文件在函数原型被调用的位置之前包含的一个头文件中找到函数原型。#include 指令在win32C++编程中很重要。C RTL函数的原型都包含在标准的头文件集中。win32API的原型全在微软提供的头文件集中,VCL中的类和函数的在原型则在随C++builder发行的头文件中。没有这些,你几乎做不了什么。
头文件提供了一种让程序员很轻易治理的方式来执行C++的类型检查,但是也带来了很大的代价。当编译器运行到一个#include 指令时,它会打开这个头文件并插入到当前文件中,然后编译器象分析已编译的文件一样来分析这些包含进来的文件。当被包含的文件中还包含有其它的头文件时会怎么样呢?编译器仍会插入那个文件再分析它,想象一下,当10、20甚至100个文件被包含时呢?尽管如此数量的包含文件听起来很多,但当你加入window sdk头文件和所有vcl头文件时,这并不是不可能的。
来举个例子说明一下编译器是如何展开和翻译被包含的文件的。这是一个我用console wizard建立的一个简单的控制台程序。为了试验代码,在options-project-compiler在把pre-compiled headers选项关掉。
// include some standard header files
//包含了一些标准的头文件
#include stdio.h
#include string.h
#include iostream.h
#include windows.h
#pragma hdrstop
#include condefs.h
//-----------------------------------------------
int main()
{
printf("Hello from printf.");
cout "Hello from cout" endl;
MessageBeep(0);
return 0;
}
当用c++builder编译工程时,编译进度对话框显示工程中包含有130,000行代码。13万行!怎么回事?源文件中只有大约四行代码,这13万行都包含在stdio.h,string.h,iostream.h,windows.h和被这四个头文件所包含的头文件里。
好,现在来看一下当工程中包含多个cpp文件时情况是怎么样的。停止编译这个工程,再加一个已有的文件到这个工程中。在第二个文件中加一个简单的函数。再到第一个文件中来调用这个新函数。
//-------------------------------------------------------
// UN99v1.CPP
#include stdio.h
#include string.h
#include iostream.h
#include windows.h
#include "Unit1.h" // prototype A() in unit1.h
#pragma hdrstop
void A()
{
printf("Hello from function A.");
}
//-------------------------------------------------------
//-------------------------------------------------------
// PROJECT1.cpp
#include stdio.h
#include string.h
#include iostream.h
#include windows.h
#include "Unit1.h"
#pragma hdrstop
#include condefs.h
//-------------------------------------------------------
USEUN99v("Unit1.cpp");
//-------------------------------------------------------
int main()
{
printf("Hello from printf.");
cout "Hello from cout" endl;
A();
MessageBeep(0);
return 0;
}
//-------------------------------------------------------
好,现在再来编译这个工程。假如在编译之前你关掉了pre-compiled头文件选项,当你编译完时你会发现编译进度对话框显示共有260,000行代码。可以看到,编译器不得不把两个文件都包含的相同的头文件集都做处理。在前面的例子里,编译器多处理了这些头文件带来的13万行代码。第二个文件又让编译器处理了同样的13万行代码,总共26万行。不难想象在一个大工程里行数将会以什么速度增长。一遍又一遍的处理这些相同的头文件大大的增加了编译的时间。
C++Builder是如何通过预编译头文件的方法来减少编译时间的
Borland的工程师熟悉到可以设计一个不用一遍又一遍处理同样的头文件的编译器来减少编译时间。于是Borland c++3.0中引入了预编译头文件的概念。处理方法很简单,当编译器处理源文件中的一组头文件时,把编译好的映象文件保存在磁盘上,当其它的源文件是引用同样的一组头文件时编译器直接读取编译好的文件而不是再一次分析。
修改一下刚才的控制台程序来看看预编译头文件是如何减少编译时间的。代码本身不用修改,仅仅把工程选项中的预编译头文件选项再选中就行了。选择Options-Project-Compiler并选中Use pre-compiled headers或是Cache pre-compiled headers。在预编译头文件名一栏中填入PCH.CSM。改好之后从重编译工程。
编译过程中注重一下编译进度对话框。你会发现当编译器编译project1.cpp时要处理130,000行代码,而编译UN99v1.cpp时只处理20行代码。当编译器分析第一个源文件时产生了一个预见编译头文件的映象,在处理第二个文件时直接用来提高编译速度。可以想象当源文件的数目不是2而是50时,性能会提高多少!
VCL GUI工程中预编译头文件的说明
通过预编译头文件的方法,上一个示例起码减少了50%的编译时间。而这不过仅仅是一个没什么功能的简单的控制台程序而已。你也会到在VCLGUI程序中会怎么样呢?缺省情况下,c++builder自动打开工程的预编译头文件选项的。但它仅仅对vcl.h文件进行预处理,这个头文件可以在任何一个窗体的源文件顶端找到。
#include vcl.h
#pragma hdrstop
#pragma hdrstop指令通知编译器停止产生预编译映象。在hdrstop指令之前的#include语句会被预编译,之后的就不会了。
那当vcl.h被预编译时到底有多少头文件也被预编译了呢?可以查看一下vcl.h,看到它包含了另一个叫做vcl0.h的头文件。假如你没有更改C++builder的缺省设置,vcl0.h就包含了一小组vcl的头文件,它们是:
// Core (minimal) VCL headers
//
#include sysdefs.h
#include system.hpp
#include windows.hpp
#include messages.hpp
#include sysutils.hpp
#include classes.hpp
#include graphics.hpp
#include controls.hpp
#include forms.hpp
#include dialogs.hpp
#include stdctrls.hpp