把C++当脚本语言写!.doc

把C++当脚本语言写！ 　　提到脚本，脑海里马上闪过一大堆：Python，Perl，Ruby，PHP，JS，VBS，LUA。。。 不过你有没听说过，用经典的C++做脚本语言吗？先不多说，上个图。（先别纠结那个function，那仅仅是个宏而已，待会你就明白了） 　　 　　 　　 　　或许你在想这一定是疯了，用世界上最复杂的语言做脚本，写的人累不说，脚本引擎先累坏了。各种复杂的模板库，要边解释边运行，得有多强大的虚拟机才撑得住。 　　好吧，那么我们退一步，不强求解释执行，回归到原始的编译后执行。———— 不过那还算脚本吗？ 　　 　　事实上如今高性能的脚本都是先编译后运行的，大名鼎鼎的JavaScript V8引擎，号称速度最快的LUA-Jit，以及众所周知的ActionScript。。。预先编译不仅能大幅提高运行速度，更重要的是能够提前发现脚本中显式的错误。 　　 　　但脚本中所谓的编译，和传统语言的编译，还是很大区别的。脚本的编译，不过是代码上的深度优化，很快就可以完成。相比复杂了多的C++来说，似乎是望尘莫及的。提到C++的编译速度，大家的映象莫过于在VC里按下F5之后，看着输出框内一条一条的“Compiling...”缓缓出现。有时仅仅测试一个微小的修改，也要等上好几秒的时间。缓慢的编译速度备受煎熬，以至于简单的程序往往选择VB或C#这样可以快速调试的语言。 　　 　　对于庞大的MFC程序来说，缓慢的编译是理所当然的。但简单的小程序出现过长的编译时间，那一定是头文件引用的不合理了。事实上，使用预处理头文件的小程序，编译仅仅是一瞬间的，之后的各种停顿往往是IDE引起的。 　　 　　那么我们就来测试下，不用IDE，仅用纯命令编译个C++小程序。我们使用VC6.0的编译器：CL.exe 　　为了确保纯净的编译环境，我们把CL.exe必须依赖的文件复制到新建的文件夹里。对于VC6的版本，只要有如下5个文件，就可以完成.cpp到.exe的编译了。 　　打开cmd，设置好环境变量，对应到VC6的头目录和库目录 SET LIB=C:\Program Files (x86)\Microsoft Visual Studio\VC98\Lib 　　就可以调用命令编译了： 　　一眨眼的工夫，编译和链接完成，生成了test.exe，一切正常。而这还是在没有使用预编译头的情况下编译的。 　　 　　由此可见，即使语言本身很复杂，但只要用它写的代码不复杂，编译还是非常快的。 　　仔细想想也应如此。以如今的硬件配置，运行98年的编译器，编译一个才几行代码的程序，自然是一瞬间的。 　　命令行编译简单的C++程序是如此的快速，利用这个优势，继续我们的脚本探索。。。 　　 　　如果要写一个生成100个随机序列号的小程序，你会使用哪类语言？ 　　相比传统语言要先创建一个工程项目，我们直接在桌面新建个文本文件就可以写脚本了。 　　虽然用文本编辑器写代码没任何优势，但对于简单的程序足矣。之后程序交给其他人使用时，脚本优势就淋漓尽致的体现出来了：当他们自己想简单修改一些逻辑规则时，只需用记事本打开就可以，而记事本每台电脑上都有。 　　相反，传统语言写的程序，即使有源代码，用户想简单的修改下也无法生效，还需安装并配置好相应的开发环境才行，这对不熟悉的人来说颇费周折。 　　 　　所以脚本必须足够简单 —— 简单到用户只管修改和运行就可以，其他步骤都交给脚本宿主自动完成。 　　 　　如果想用C++写脚本，那么代码的编译和链接当然必须是全自动的，这并不复杂。 　　但仅仅依靠CL.exe等几个命令还是不够的，因为在其他的电脑上并没有相应的开发环境 —— Include和Lib文件夹，因此就无法通过编译和链接了。 　　而这些头文件库文件，一共多达上千个，全都带上则有近百兆！显然，我们的脚本只用到几个基本功能就可以了，那些复杂的windows头文件就没必要了。 　　 　　事实上，程序的头文件只是函数和结构的定义，仅仅用来给编译器分析而已，最终并不生成实际的指令。所以，我们把常用的头文件，事先生成一个.pch预编译头文件就可以。以后编译时，将他对应到某个头文件就可以了，例如stdafx.h。这样就无需使用任何头文件了。即使stdafx.h也不在，编译仍然能通过，因为这一切都打包在.pch里面了。并且大量的头文件经过事先的分析，编译时就无需再编译它们了，速度大幅提升。 　　 　　至于Lib文件，里面都是库函数的内容。除非整个程序不使用任何C运行时库，那么我们可以不带上任何lib，但那样只能写最基本的代码了。对于一般的简单脚本程序，只需几个必要的lib即可：KERNEL32.LIB，LIBCMT.LIB，LIBCPMT.LIB，OLDNAMES.LIB。总共才1M多。