552
社区成员
发帖
与我相关
我的任务
分享看看我们的BCB论坛，一页中就有七个讨论 BCB 和 Delphi 的帖子，究竟是怎么啦？？？！！
大家看看吧！谁能告诉我为什么这样？是因为来了一群新的 BCB Fans吗？还是……
?我是该用delphi还是c++ builder？?? 0 9 57 1-27 00:01
再发一次吧。昨天发晚了，人少.比较BCB和DELPHI我差点哭了，原来是这样，我以前的看法错了。BCB，你的路还长.BCB真比DELPHI慢得多，你们认为呢，有谁一起比过呢？来说说吧
算了，对BCB太失望了，还是换Delphi吧，编译速度和代码提示速度简直是叫人去喝咖啡！
？C++Builder跟Delphi比有什么好的？
请大家谈谈Delphi与BCB...........
？delphi和c++开发软件那一个好？ 20 8 55 1-26 23:08
？C++Builder究竟哪比Delphi好？（关系到C++Builder的前途)
……………………
?我是该用delphi还是c++ builder？?? 0 9 57 1-27 00:01
再发一次吧。昨天发晚了，人少.比较BCB和DELPHI我差点哭了，原来是这样，我以前的看法错了。BCB，你的路还长.BCB真比DELPHI慢得多，你们认为呢，有谁一起比过呢？来说说吧
算了，对BCB太失望了，还是换Delphi吧，编译速度和代码提示速度简直是叫人去喝咖啡！
？C++Builder跟Delphi比有什么好的？
请大家谈谈Delphi与BCB...........
？delphi和c++开发软件那一个好？ 20 8 55 1-26 23:08
？C++Builder究竟哪比Delphi好？（关系到C++Builder的前途)
……………………
...全文
请发表友善的回复…
发表回复
CyberUFO 2002-01-28
- 打赏
- 举报
可能大家没有仔细看，我发这个帖子并非是想参与这个讨论 ～～～～～
我只是昨天午夜时刻登陆进来，发现一页中就有如此多的同种性质的帖子，
于是罗列了一些 帖子的 题目而已～～
我只是昨天午夜时刻登陆进来，发现一页中就有如此多的同种性质的帖子，
于是罗列了一些 帖子的 题目而已～～
IT-司马青衫 2002-01-27
- 打赏
- 举报
通过预编译头文件的方法来提高c++builder的编译速度 贴文时间
2001-1-6 14:58:43 文章类型:
翻译
kingofwang 翻译 出处: http://www.borland.com
通过预编译头文件的方法来提高c++builder的编译速度
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（）之前。
对于编译器来说，函数的原型很重要。当你运行程序时，编译器都要插入恰当的代码来调用程序。编译器必需知道要有多少个参数传给函数。也要知道函数的参数应该在栈里还是在寄存器里。总而言这，编译器必需知道怎么来产生正确的代码来调用这个函数，这就要求编译器必需知道预先声明或定义了的被调用的函数。
为使函数或类的原型简单化，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;
}
//-------------------------------------------------------
好，现在再来编译这个工程。如果在编译之前你关掉了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。
缺省的预编译头文件设置确实减少了编译工程的时间。你可以通过打开和关闭观预编译头文件选项时完全编译一个大工程所要用的时间来证明这一点。本节的目的就是通过改善预编译头文件的方法来进一步减少编译时间。这里我要讲到两个技术。
在讨论这两个技术之前呢，有必要了解一下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之前，而且顺序要相同。
#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
#include "About
2001-1-6 14:58:43 文章类型:
翻译
kingofwang 翻译 出处: http://www.borland.com
通过预编译头文件的方法来提高c++builder的编译速度
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（）之前。
对于编译器来说，函数的原型很重要。当你运行程序时，编译器都要插入恰当的代码来调用程序。编译器必需知道要有多少个参数传给函数。也要知道函数的参数应该在栈里还是在寄存器里。总而言这，编译器必需知道怎么来产生正确的代码来调用这个函数，这就要求编译器必需知道预先声明或定义了的被调用的函数。
为使函数或类的原型简单化，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;
}
//-------------------------------------------------------
好，现在再来编译这个工程。如果在编译之前你关掉了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。
缺省的预编译头文件设置确实减少了编译工程的时间。你可以通过打开和关闭观预编译头文件选项时完全编译一个大工程所要用的时间来证明这一点。本节的目的就是通过改善预编译头文件的方法来进一步减少编译时间。这里我要讲到两个技术。
在讨论这两个技术之前呢，有必要了解一下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之前，而且顺序要相同。
#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
#include "About
IT-司马青衫 2002-01-27
- 打赏
- 举报
1.把C++当成一门新的语言学习（和C没啥关系！真的。）；
2.看《Thinking In C++》，不要看《C++变成死相》；
3.看《The C++ Programming Language》和《Inside The C++ Object Model》,不要因为他们很难而我们自己是初学者所以就不看；
4.不要被VC、BCB、BC、MC、TC等词汇所迷惑——他们都是集成开发环境，而我们要学的是一门语言；
5.不要放过任何一个看上去很简单的小编程问题——他们往往并不那么简单，或者可以引伸出很多知识点；
6.会用Visual C++，并不说明你会C++；
7.学class并不难，template、STL、generic programming也不过如此——难的是长期坚持实践和不遗余力的博览群书；
8.如果不是天才的话，想学编程就不要想玩游戏——你以为你做到了，其实你的C++水平并没有和你通关的能力一起变高——其实可以时刻记住：学C++是为了编游戏的；
9.看Visual C++的书，是学不了C++语言的；
10.浮躁的人容易说：XX语言不行了，应该学YY；——是你自己不行了吧！？
11.浮躁的人容易问：我到底该学什么；——别问，学就对了；
12.浮躁的人容易问：XX有钱途吗；——建议你去抢银行；
13.浮躁的人容易说：我要中文版！我英文不行！——不行？学呀！
14.浮躁的人容易问：XX和YY哪个好；——告诉你吧，都好——只要你学就行；
15.浮躁的人分两种：a)只观望而不学的人；b)只学而不坚持的人；
16.把时髦的技术挂在嘴边，还不如把过时的技术记在心里；
17.C++不仅仅是支持面向对象的程序设计语言；
18.学习编程最好的方法之一就是阅读源代码；
19.在任何时刻都不要认为自己手中的书已经足够了；
20.请阅读《The Standard C++ Bible》(中文版：标准C++宝典)，掌握C++标准；
21.看得懂的书，请仔细看；看不懂的书，请硬着头皮看；
22.别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍；
23.请看《Effective C++》和《More Effective C++》以及《Exceptional C++》；
24.不要停留在集成开发环境的摇篮上，要学会控制集成开发环境，还要学会用命令行方式处理程序；
25.和别人一起讨论有意义的C++知识点，而不是争吵XX行不行或者YY与ZZ哪个好；
26.请看《程序设计实践》，并严格的按照其要求去做；
27.不要因为C和C++中有一些语法和关键字看上去相同，就认为它们的意义和作用完全一样；
28.C++绝不是所谓的C的“扩充”——如果C++一开始就起名叫Z语言，你一定不会把C和Z语言联系得那么紧密；
29.请不要认为学过XX语言再改学C++会有什么问题——你只不过又在学一门全新的语言而已；
30.读完了《Inside The C++ Object Model》以后再来认定自己是不是已经学会了C++；
31.学习编程的秘诀是：编程，编程，再编程；
32.请留意下列书籍：《C++面向对象高效编程（C++ Effective Object-Oriented Software Construction）》《面向对象软件构造(Object-Oriented Software Construction)》《设计模式（Design Patterns）》《The Art of Computer Programming》；
33.记住：面向对象技术不只是C++专有的；
34.请把书上的程序例子亲手输入到电脑上实践，即使配套光盘中有源代码；
35.把在书中看到的有意义的例子扩充；
36.请重视C++中的异常处理技术，并将其切实的运用到自己的程序中；
37.经常回顾自己以前写过的程序，并尝试重写，把自己学到的新知识运用进去；
38.不要漏掉书中任何一个练习题——请全部做完并记录下解题思路；
39.C++语言和C++的集成开发环境要同时学习和掌握；
40.既然决定了学C++,就请坚持学下去，因为学习程序设计语言的目的是掌握程序设计技术，而程序设计技术是跨语言的；
41.就让C++语言的各种平台和开发环境去激烈的竞争吧，我们要以学习C++语言本身为主；
42.当你写C++程序写到一半却发现自己用的方法很拙劣时，请不要马上停手；请尽快将余下的部分粗略的完成以保证这个设计的完整性，然后分析自己的错误并重新设计和编写（参见43）；
43.别心急，设计C++的class确实不容易；自己程序中的class和自己的class设计水平是在不断的编程实践中完善和发展的；
44.决不要因为程序“很小”就不遵循某些你不熟练的规则——好习惯是培养出来的，而不是一次记住的；
45.每学到一个C++难点的时候，尝试着对别人讲解这个知识点并让他理解——你能讲清楚才说明你真的理解了；
46.记录下在和别人交流时发现的自己忽视或不理解的知识点；
47.请不断的对自己写的程序提出更高的要求,哪怕你的程序版本号会变成Version 100.XX；
48.保存好你写过的所有的程序——那是你最好的积累之一；
49.请不要做浮躁的人；
50.请热爱C++!
众多系统分析员的经典评论：
The best comments listed below:
http://chinaprogramer.com/programtech/veritools.htm
从一、 跨平台特性
二、组件技术支持
三、数据库支持级别
四、系统底层开发支持
五、多媒体及图形图像开发支持
六、网络或Web开发支持
七、开发模式
八、面向对象特性
九、开发效率
十、代码执行效率
十一、帮助系统
十二、易学程度
十三、使用人数
十四、厂商财力
十五、发展潜力
十六、基础语言广泛性
结论：
VB：是新人开发与系统无关的综合应用程序的首选；容易使用和厂商财力很强是其仅有的两点优势
PB：是开发大型MIS及各类数据库跨平台应用的首选；从数据库前端工具来讲甚至远远超过了Oracle的Develop系列等专门的工具；从通用语言角度来讲功能也与VB等不相上下；多媒体和网络功能与其他工具相比较弱
C++ Builder/Dephi：是唯一一套能够同时适用于开发数据库应用、网络及Web应用、分布式应用、可重用组件、系统软件、驱动程序、多媒体及游戏等所有软件的高效率开发环境；VCL源码基于Object Pascal是C++ Builder唯一的缺憾，基础语言不够通用和开发系统软件功能不足是Dephi仅有的两点不足
VC：从功能上讲除了跨平台应用外什么都可开发；从开发效率角度讲只局限于开发windows系统应用、可重用组件及驱动程序
JAVA：适用于开发除了系统软件、驱动程序、高性能实时系统、大规模图像处理以外所有的应用
评出综合分：
VB：46 ;PB：53; C++ Builder/Dephi：67/61; VC：55 ;JAVA：59
2.看《Thinking In C++》，不要看《C++变成死相》；
3.看《The C++ Programming Language》和《Inside The C++ Object Model》,不要因为他们很难而我们自己是初学者所以就不看；
4.不要被VC、BCB、BC、MC、TC等词汇所迷惑——他们都是集成开发环境，而我们要学的是一门语言；
5.不要放过任何一个看上去很简单的小编程问题——他们往往并不那么简单，或者可以引伸出很多知识点；
6.会用Visual C++，并不说明你会C++；
7.学class并不难，template、STL、generic programming也不过如此——难的是长期坚持实践和不遗余力的博览群书；
8.如果不是天才的话，想学编程就不要想玩游戏——你以为你做到了，其实你的C++水平并没有和你通关的能力一起变高——其实可以时刻记住：学C++是为了编游戏的；
9.看Visual C++的书，是学不了C++语言的；
10.浮躁的人容易说：XX语言不行了，应该学YY；——是你自己不行了吧！？
11.浮躁的人容易问：我到底该学什么；——别问，学就对了；
12.浮躁的人容易问：XX有钱途吗；——建议你去抢银行；
13.浮躁的人容易说：我要中文版！我英文不行！——不行？学呀！
14.浮躁的人容易问：XX和YY哪个好；——告诉你吧，都好——只要你学就行；
15.浮躁的人分两种：a)只观望而不学的人；b)只学而不坚持的人；
16.把时髦的技术挂在嘴边，还不如把过时的技术记在心里；
17.C++不仅仅是支持面向对象的程序设计语言；
18.学习编程最好的方法之一就是阅读源代码；
19.在任何时刻都不要认为自己手中的书已经足够了；
20.请阅读《The Standard C++ Bible》(中文版：标准C++宝典)，掌握C++标准；
21.看得懂的书，请仔细看；看不懂的书，请硬着头皮看；
22.别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍；
23.请看《Effective C++》和《More Effective C++》以及《Exceptional C++》；
24.不要停留在集成开发环境的摇篮上，要学会控制集成开发环境，还要学会用命令行方式处理程序；
25.和别人一起讨论有意义的C++知识点，而不是争吵XX行不行或者YY与ZZ哪个好；
26.请看《程序设计实践》，并严格的按照其要求去做；
27.不要因为C和C++中有一些语法和关键字看上去相同，就认为它们的意义和作用完全一样；
28.C++绝不是所谓的C的“扩充”——如果C++一开始就起名叫Z语言，你一定不会把C和Z语言联系得那么紧密；
29.请不要认为学过XX语言再改学C++会有什么问题——你只不过又在学一门全新的语言而已；
30.读完了《Inside The C++ Object Model》以后再来认定自己是不是已经学会了C++；
31.学习编程的秘诀是：编程，编程，再编程；
32.请留意下列书籍：《C++面向对象高效编程（C++ Effective Object-Oriented Software Construction）》《面向对象软件构造(Object-Oriented Software Construction)》《设计模式（Design Patterns）》《The Art of Computer Programming》；
33.记住：面向对象技术不只是C++专有的；
34.请把书上的程序例子亲手输入到电脑上实践，即使配套光盘中有源代码；
35.把在书中看到的有意义的例子扩充；
36.请重视C++中的异常处理技术，并将其切实的运用到自己的程序中；
37.经常回顾自己以前写过的程序，并尝试重写，把自己学到的新知识运用进去；
38.不要漏掉书中任何一个练习题——请全部做完并记录下解题思路；
39.C++语言和C++的集成开发环境要同时学习和掌握；
40.既然决定了学C++,就请坚持学下去，因为学习程序设计语言的目的是掌握程序设计技术，而程序设计技术是跨语言的；
41.就让C++语言的各种平台和开发环境去激烈的竞争吧，我们要以学习C++语言本身为主；
42.当你写C++程序写到一半却发现自己用的方法很拙劣时，请不要马上停手；请尽快将余下的部分粗略的完成以保证这个设计的完整性，然后分析自己的错误并重新设计和编写（参见43）；
43.别心急，设计C++的class确实不容易；自己程序中的class和自己的class设计水平是在不断的编程实践中完善和发展的；
44.决不要因为程序“很小”就不遵循某些你不熟练的规则——好习惯是培养出来的，而不是一次记住的；
45.每学到一个C++难点的时候，尝试着对别人讲解这个知识点并让他理解——你能讲清楚才说明你真的理解了；
46.记录下在和别人交流时发现的自己忽视或不理解的知识点；
47.请不断的对自己写的程序提出更高的要求,哪怕你的程序版本号会变成Version 100.XX；
48.保存好你写过的所有的程序——那是你最好的积累之一；
49.请不要做浮躁的人；
50.请热爱C++!
众多系统分析员的经典评论：
The best comments listed below:
http://chinaprogramer.com/programtech/veritools.htm
从一、 跨平台特性
二、组件技术支持
三、数据库支持级别
四、系统底层开发支持
五、多媒体及图形图像开发支持
六、网络或Web开发支持
七、开发模式
八、面向对象特性
九、开发效率
十、代码执行效率
十一、帮助系统
十二、易学程度
十三、使用人数
十四、厂商财力
十五、发展潜力
十六、基础语言广泛性
结论：
VB：是新人开发与系统无关的综合应用程序的首选；容易使用和厂商财力很强是其仅有的两点优势
PB：是开发大型MIS及各类数据库跨平台应用的首选；从数据库前端工具来讲甚至远远超过了Oracle的Develop系列等专门的工具；从通用语言角度来讲功能也与VB等不相上下；多媒体和网络功能与其他工具相比较弱
C++ Builder/Dephi：是唯一一套能够同时适用于开发数据库应用、网络及Web应用、分布式应用、可重用组件、系统软件、驱动程序、多媒体及游戏等所有软件的高效率开发环境；VCL源码基于Object Pascal是C++ Builder唯一的缺憾，基础语言不够通用和开发系统软件功能不足是Dephi仅有的两点不足
VC：从功能上讲除了跨平台应用外什么都可开发；从开发效率角度讲只局限于开发windows系统应用、可重用组件及驱动程序
JAVA：适用于开发除了系统软件、驱动程序、高性能实时系统、大规模图像处理以外所有的应用
评出综合分：
VB：46 ;PB：53; C++ Builder/Dephi：67/61; VC：55 ;JAVA：59
richincsdn2 2002-01-27
- 打赏
- 举报
别哭别哭，哈哈哈哈哈啊哈哈哈哈
