副标题#e#
C++ Builder是最快的C＋＋编译器之一，从编译速度来说也可以说是最快的win32C＋＋编译器了。除了速度之外，C++builder的机能也在其它C＋＋编译器的之上，但很多delphi措施员仍受不了C++builder工程的编译速度。简直，delphi的速度要比任和c++的编译器都要快许多几何。Delphi在编译一个小工程的时候大概不到一秒，大的工程一般也在5秒钟这内编译完成了。
为什么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（）之前。
对付编译器来说，函数的原型很重要。当你运行措施时，编译器都要插入得当的代码来挪用措施。编译器必须知道要有几多个参数传给函数。也要知道函数的参数应该在栈里照旧在寄存器里。总而言这，编译器必须知道怎么来发生正确的代码来挪用这个函数，这就要求编译器必须知道预先声明或界说了的被挪用的函数。
#p#副标题#e#
为使函数或类的原型简朴化，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.\n");
cout << "Hello from cout" << endl;
MessageBeep(0);
return 0;
}
当用c++builder编译工程时，编译进度对话框显示工程中包括有130,000行代码。13万行！怎么回事？源文件中只有约莫四行代码，这13万行都包括在stdio.h,string.h,iostream.h,windows.h和被这四个头文件所包括的头文件里。
好，此刻来看一下当工程中包括多个cpp文件时环境是怎么样的。遏制编译这个工程，再加一个已有的文件到这个工程中。在第二个文件中加一个简朴的函数。再到第一个文件中来挪用这个新函数。
//-------------------------------------------------------
// UNIT1.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.\n");
}
//-------------------------------------------------------
//-------------------------------------------------------
// PROJECT1.cpp
#include <stdio.h>
#include <string.h>
#include <iostream.h>
#include <windows.h>
#include "Unit1.h"
#pragma hdrstop
#include <condefs.h>
//-------------------------------------------------------
USEUNIT("Unit1.cpp");
//-------------------------------------------------------
int main()
{
printf("Hello from printf.\n");
cout << "Hello from cout" << endl;
A();
MessageBeep(0);
return 0;
}
//-------------------------------------------------------
#p#分页标题#e#
好，此刻再来编译这个工程。假如在编译之前你关掉了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行代码，而编译UNIT1.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>
#include <extctrls.hpp>
这是一小部门常被反复包括的头文件，也许它只是大中型工程常用到的头文件的一个了集。vcl0.h还答允你通过界说条件（#define)来预编译更多的头文件。你可以通过#define一个叫做INC_VCLDB_HEADERS的变量来预编译数据库的头文件。同样，还可以界说INC_VCLEXT_HEADERS来预编译c++builder的扩展控件（Extra controls)。假如你还界说了INC＿OLE＿HEADERS，C++builder还会预编译一些SDK COM的头文件。这些界说要放在#include vcl.h语句这前。
#define INC_VCLDB_HEADERS
#define INC_VCLEXT_HEADERS
#include <vcl.h>
#pragma hdrstop
留意：假如你要利用这些成果的话，你要确保把这两个#define加到每个cpp文件，纵然是没有用到数据库或是扩展控件的文件。至于原因稍后会被讲到。
利用预编译头文件来优化c++builder。
缺省的预编译头文件配置确实淘汰了编译工程的时间。你可以通过打开和封锁观预编译头文件选项时完全编译一个大工程所要用的时间来证明这一点。本节的目标就是通过改进预编译头文件的要领来进一步淘汰编译时间。这里我要讲到两个技能。
#p#分页标题#e#
在接头这两个技能之前呢，有须要相识一下c++builder在编译源措施时是奈何来抉择是否利用已存在的预编译的头文件的映象的。c++builder会给你工程中的每一个源文件都发生一个独一的预编译头文件映象。这些映象被生存在硬盘上的一个文件里。编译器会在有两个源文件利用同样的预编译头文件映象时来重用一个映象文件。这是很重要的一点，两个源文件包括了完全一样的头文件时就会利用预编译头文件映象。再有就是他们包括这些头文件的顺序必须沟通。简朴的说：源文件的#pragma hdrstop指令之前必须完全沟通。下面是一些例子：
示例1：预编译头文件映象不匹配
//-------------------- //--------------------
// UNIT1.CPP // UNIT2.CPP
#include <stdio.h> #include <iostream.h>
#pragma hdrstop #pragma hdrstop
示例2：预编译头文件映象不匹配
//-------------------- //--------------------
// UNIT1.CPP // UNIT2.CPP
#include <stdio.h> #include <stdio.h>
#include <iostream.h> #pragma hdrstop
#pragma hdrstop
示例3：预编译头文件映象不匹配
//-------------------- //--------------------
// UNIT1.CPP // UNIT2.CPP
#include <stdio.h> #pragma hdrstop
#pragma hdrstop #include <stdio.h>
示例4：预编译映象匹配
//-------------------- //--------------------
// UNIT1.CPP // UNIT2.CPP
#include <stdio.h> #include <stdio.h>
#include <string.h> #include <string.h>
#include <iostream.h> #include <iostream.h>
#include <windows.h> #include <windows.h>
#include "unit1.h" #include "unit1.h"
#pragma hdrstop #pragma hdrstop
示例5：预编译映象匹配
//-------------------- //--------------------
// UNIT1.CPP // UNIT2.CPP
#define INC_VCLDB_HEADERS #define INC_VCLDB_HEADERS
#define INC_VCLEXT_HEADERS #define INC_VCLEXT_HEADERS
#include <vcl.h> #include <vcl.h>
#pragma hdrstop #pragma hdrstop
#include "unit1.h" #include "unit2.h"
示例6：预编译映象不匹配
//-------------------- //--------------------
// UNIT1.CPP // UNIT2.CPP
#define INC_VCLDB_HEADERS #include <vcl.h>
#define INC_VCLEXT_HEADERS #pragma hdrstop
#include <vcl.h>
#pragma hdrstop
当编译器处理惩罚一个预编译映象不匹配的源文件时就会从头再发生一个全新的映象。看上面的示例2。尽量stdio.h在unit1.cpp中已经被编译过了，可是unit2中照旧要被编译的。只有在多个文件中都能用到预编译映象编译器才气淘汰编译的时间。
这就是我所讲到的技能的基本。预编译尽大概多的头文件，并确保在每个源文件中都用到同样的预编译映象。
技能1：
第一个技能只是通过在每个源文件中界说两个条件来增加vcl.h中包括的头文件的数目。打开工程中的每个cpp文件包罗工程文件，象下面看到的那样改变它们的头两行。
#define INC_VCLDB_HEADERS
#define INC_VCLEXT_HEADERS
#include <vcl.h>
#pragma hdrstop
假如你不喜欢这种要领，你可以在Project-Options-Directories/Conditional条件界说栏中填入INC＿VCLDB＿HEADERS 和 INC＋VCLEXT＿HEADERS来到达同样的目标。
或者你也想插入一些windows.h之类的你常用的C RTL头文件，要确保插入到hdrstop pragma之前，并且顺序要沟通。
#p#分页标题#e#
#define INC_VCLDB_HEADERS
#define INC_VCLEXT_HEADERS
#include <vcl.h>
#include <windows.h>
#include <stdio.h>
#pragma hdrstop
技能2：
技能1的结果很好，但它不是很机动。假如你想要在观感编译的头文件列表中再插手一个新的头文件的话，你要修改你工程中的每一个源文件。另外，技能一容易堕落。假如你把包括的顺序弄乱了，你只会更糟而不是更好。
技能二处理惩罚了技能一的一些缺点。要领就是建设一个庞大的头文件来包括你工程顶用到的所有的头文件。这个头文件将包括有VCL的头文件、window SDK的头文件以及RTL头文件。虽然你也可以包括一些建设的窗体的头文件，但稍会你会相识到不该该把一些常修改的文件做预编译处理惩罚（查察留意事项：不要预编译变革的头文件）
下面就样一个文件的示例：
//---------------------------------------------------------
// PCH.H: Common header file
#ifndef PCH_H
#define PCH_H
// include every VCL header that we use
// could include vcl.h instead
#include <Buttons.hpp>
#include <Classes.hpp>
#include <ComCtrls.hpp>
#include <Controls.hpp>
#include <ExtCtrls.hpp>
#include <Forms.hpp>
#include <Graphics.hpp>
#include <ToolWin.hpp>
// include the C RTL headers that we use
#include <string.h>
#include <iostream.h>
#include <stdio.h>
// include headers for the 3rd party controls
// TurboPower System
#include "StBase.hpp"
#include "StVInfo.hpp"
// Our custom controls
#include "DBDatePicker.h"
#include "DBRuleCombo.h"
#include "DBPhonePanel.h"
// Object Repository header files
#include "BaseData.h"
#include "BASEDLG.h"
// project include files
// pre-compile these only if PRECOMPILE_ALL is defined
#ifdef PRECOMPILE_ALL
