编译指令的代价是什么

❶ 高层语言与底层语言的区别

一般来讲高级语言和低级语言有一下特点：
高级语言：实现效率高，执行效率低，对硬件的可控性弱，目标代码大，可维护性好，可移植性好
低级语言：实现效率低，执行效率高，对硬件的可控性强，目标代码小，可维护性差，可移植性差

我们都知道CPU运行的是二进制指令，所有的语言编写的程序最终都要翻译成二进制代码，但是为什么实现会有以上众多差异呢？下面以c语言为高级语言代表，汇编语言为低级语言代表来解释一下。
越低级的语言，形式上越接近机器指令，汇编语言就是与机器指令一一对应的。而越高级的语言，一条语句对应的指令数越多，其中原因就是高级语言对底层操作进行了抽象和封装，使编写程序的过程更符合人类的思维习惯，并且极大了简化了人力劳动。也就是说你用高级语言写一句，会被转换成许多底层操作，大部分的工作交给了负责转换的机器（即编译器），从而人力得到了解放。因为机器就是用来为人类提供便利的，所以说高级语言的出现是计算机发展的必然结果。
下面重点解释为何低级语言的执行效率更高：
1.低级语言可以通过控制硬件访问来优化效率
越低级的语言月接近底层，即控制硬件访问的能力越强，对硬件资源的利用效率越高。比如说汇编语言能够访问寄存器，而C语言就做不到。通过对寄存器等硬件的访问，我们可以将程序的运行效率优化到最大，而像C这样的高级语言用的最多的是堆栈这样的内存结构，访问速度自然不如寄存器了。
2.高级语言程序存在工作冗余，有效率损失。
各种语言需要通过编译器翻译成机器码，不管编译多么智能和强大，都是会产生冗余。这里的冗余不是指指令的多少，而是有没有做没有必要的事情。 产生冗余的多少关键要看语言跟机器指令之间的耦合度。耦合度越大，编译器翻译过程越简单，产生的冗余越少。对应汇编来书，由于与机器码一一对应，所以翻译后基本没有冗余。而高级语言由于进行了抽象和封装，所以与机器指令间的耦合度较低，因此整个翻译过程较复杂，因此在高级语言在具体化的过程中不可避免会产生较多的冗余。据说C语言有10%的效率损失。
3.效率高不高，还取决于程序员水平。
一个差的程序员用汇编写程序，可能存在很多没有用的操作，而程序高手用c语言写，可以将程序优化到最大。最终的结果可能是汇编的程序跑不过C语言程序。

总之，完成一项工作的工作量是不变的，机器做的 多了，人就做的就少了，同时人对程序的很多细节的控制性也减弱了。各种语言都是在这个平衡点附近纠结。从C/C++的注重机器运算效率的优化，到C#/JAVA注重开发效率的优化。人操作起来更加方便了，更高效了，代价就是，机器要处理的东西更多，运算效率被进一步压缩。但是这个压缩在许可范围内，那么这也是一种进步。

❷ 突破封锁！国产芯片终于有了自己的指令集

在半导体芯片领域， 指令系统是一切软硬件生态的起点 。

以大家最熟悉的ARM和X86为例，它们就分别隶属于RISC精简指令集和CISC复杂指令集。

随着物联网、5G、AI新兴领域的兴起，RISC-V和MIPS两大精简指令集架构也频繁出现在我们的视野内。

所谓芯片，其实都是由半导体堆出来的硬件电路，晶体管越多往往代表性能和功能越强。但无论是超级计算机还是智能手环， 它们搭载的处理器都只能识别二进制数据 。

想让这些芯片正常运行，处理复杂的应用场景，首先就要教会它们学会类似九九乘法表的“算法口诀”和“数学公式”， 而这些算法口御桥早诀/公式其实就是所谓的“指令集” 。

换句话说， 指令集的功能和效率（算法口诀/公式的类型），在很大程度上就决定了各类芯片的成就和算力的上限 。

虽然海思麒麟、龙芯、兆芯、海光、紫光、澎湃等国产芯片都在各自领域取得了不俗的成绩，但无论是它们，还是其他采用X86、ARM、MIPS、RISC-V、Alpha和Power，选择封闭、授权还是开源的国产芯片项目，其底层的指令集根基都掌握在别人手里。

因此， 只有从指令系统的根源上实现自主，才能打破软件生态发展受制于人的枷锁 。

好消息是，日前龙芯中科就正式发布了自主指令系统架构“Loongson Architecture”，简称为“龙芯架构”或者“LoongArch”。它包括基础架构部分，以及向量扩展LSX、高级向量扩展LASX、虚拟化LVZ、二进制翻译LBT等扩展部分，总共接近2000条指令。同时不包含龙芯此前使用的MIPS指令系统， 并具有完全自主、技术先进、兼容生态三个方面的特点 。

目前，采用LoongArch的龙芯3A5000处理器芯片已经流片成功，完整操作系统也已稳定运行，它能对多种国际主流指令系统的高效二进制翻译链，并成功演示了运行基于其它主流指令系统的复杂应用程序。

LoongArch对MIPS指令的翻译效率是100%性能，对ARM指令翻译的效率是90%性能，对x86的翻译效率是80%性能。

此外，龙芯中科还在联合产业链伙伴在适当的时间建立开放指令系统联盟，在联盟成员内免费共享LoongArch及有关龙芯IP核。

所谓IP核，我们可以理解为ARM旗下的Cortex-A78和Cortex-A55等，后置都是基于ARMv8指令集打造的核心IP架构，并授权给了高通、三星、联发科等芯片商开发SoC移动平台。

目前，ARM刚刚发布了ARMv9指令集，如果不出意外将在下半年发布的Cortex-A79和Cortex-X2架构就将采用这套指令集。

近10年来32位手机处理器都是基于ARMv7指令集打造，在A75之前的处理器则是基于ARMv8-A设计，随后都是ARMv8.2-A一统江湖

ARM指令集可以细分为Cortex-A（ARMv-A）、Cortex-R（ARMv-R）和Cortex-M（ARMv-M），分别适用于不同类型的芯片

比如车载芯片使用的就是Cortex-R（ARMv-R）核心IP

总之， 设计出一个纯国产的自主指令集只是万里长征的第一步 ，关键是后续要做出懂这个指令集的CPU（已经有了龙芯3A5000），再往后还需要镇雀让和人类交互的“翻译家”——编译器懂这个指令集。也就是需要不断完善软硬件生态，让我们熟悉的系统、办公、 娱乐 和 游戏 程序都能运行在这套指令集打造的芯片之上。如果做不到这一步，国产指令集和相关芯片也只是空中楼阁而已、

作为国人，我们真心希望LoongArch这种国产指令集可以取得成功，今后无论手机、电脑、车载还是其消冲他半导体芯片都能以使用国产指令集为荣，并走向世界。

扩展小知识

那么，指令集又是如何影响芯片执行效率的？

我们以RISC和CISC，让它们分别执行“清洁地面”的命令为例，看看其背后的指令逻辑差异。

逻辑上，“清洁地面”的大概思路是先拿起扫帚，扫地；拿起簸箕，用扫帚把垃圾扫进簸箕；放下扫帚和簸箕，润湿墩布；再用墩布擦地，直至清洁地面完成。

对CISC复杂指令集而言，很容易理解“清洁地面”这套逻辑，下达“清洁地面”命令后，就能按照规则和顺序，一步步自动完成。

对于RISC精简指令集而言，它一下子可理解不了如此复杂的逻辑，必须将复杂的逻辑顺序拆分，然后按照一项项简单的命令去完成复杂的操作。

比如，想让RISC精简指令集完成“清洁地面”命令，就必须依次下达“拿起扫帚”、“扫地”、“拿起簸箕”、“把垃圾扫进簸箕”、“放下扫帚和簸箕”、“润湿墩布”、“墩地”……

看起来CISC复杂指令集方便又强大？没错，如果要同时清洁无数房间地面，你只要对着不同的房屋说“清洁地面”、“清洁地面”、“清洁地面”……即可。

而对RISC精简指令集，你需要对着每个房间都重复一整套复杂的命令，如果下达指令的人嘴巴不够快（带宽不够大），那清洁地面的效率自然受到影响，难以和CISC复杂指令集抗衡。

但是， 现实生活中，并非所有房间的地面都需要一整套的清洁流程，比如你只需要墩地一个步骤。

对RISC精简指令集而言，你只需对着需要清洁的房间说“墩地”、“墩地”、“墩地”即可。而由于CISC复杂指令集没有单独的“墩地”动作，操作起来就要麻烦许多，完成相同的墩地操作会消耗更多资源，翻译过来就是发热更高更费电。

这就是RISC和CISC的本质区别。 说不上谁好谁坏，只能说它们所擅长的领域各不相同。

以ARM架构为代表的RISC精简指令集，最适合针对常用的命令进行优化，赋予它更简洁和高效的执行环境，对不常用的功能则通过各种精简指令组合起来完成。

RISC是将复杂度交给了编译器，牺牲了程序大小和指令带宽，从而换取了简单和低功耗的硬件实现。

对以X86架构为代表的CISC复杂指令集，则适合更加复杂的应用环境。

CISC是以增加处理器本身复杂度作为代价，以牺牲功耗为代价去换取更高的性能。不过，X86架构则可通过对新型指令集的支持（如SSE4.1、AVX-512等），在一定程度上提高指定任务的执行效率和降低功耗。

现在芯片领域是RISC攻，CISC守的格局。以苹果M1为代表的ARM架构RISC指令集芯片正在染指传统的X86 PC市场，而且大概率会取得成功。虽然以英特尔为代表的X86阵营曾多次试图反击Android生态（如早期的Atom芯片），但最终却都以失败告终。ARM最新发布的ARMv9指令集，就给了ARM芯片入侵X86 PC大本营更多弹药，也许用不了多久Windows ARM版PC也将成为一个更加重要的PC品类。

❸ ARM X86 CISC RISC

参考 ARM X86 区别

RISC的英文全称是“reced instruction set computer”，即“精简指令集计算机”；
CISC的英文全称为“Complex Instruction Set Computer”，即“复杂指令系统计算机”。
X86是复杂指令集（CISC）的代表，而ARM(Advanced RISC Machine——高级RISC机)则是精简指令集（RISC）的代表。
关于X86架构和ARM架构这两者谁将统一市场的争执一直都有，但是也有人说这两者根本不具备可比性，X86无法做到ARM的功耗，而ARM也无法做到X86的性能。

我们要明白CPU是一个执行部件，它之所以能执行，也是因为人们在里面制作了执行各种功能的硬件电路，然后再用一定的逻辑让它按照一定的顺序工作，这样就能完成人们给它的任务。也就是说，如果把CPU看作一个人，首先它要有正常的工作能力（既执行能力），然后又有足够的逻辑能力（能明白做事的顺序），最后还要听的懂别人的话（既指令集），才能正常工作。而这些集中在一起就构成了所谓的“架构”，它可以理解为一套“工具”、“方法”和“规范”的集合。不同的架构之间，工具可能不同，方法可能不同，规范也可能不同，这也造成了它们之间的不兼容——你给一个意大利泥瓦匠看一份中文写成的烹饪指南，他当然不知道应该干什么了。

从CPU发明到现在，有非常多种架构，从我们熟悉的X86，ARM，到不太熟悉的MIPS，IA64，它们之间的差距都非常大。但是如果从最基本的逻辑角度来分类的话，它们可以被分为两大类，即所谓的“复杂指令集”与“精简指令集”系统，也就是经常看到的“CISC”与“RISC”。属于这两种类中的各种架构之间最大的区别，在于它们的设计者考虑问题方式的不同。

我们可以继续举个例子，比如说我们要命令一个人吃饭，那么我们应该怎么命令呢？我们可以直接对他下达“吃饭”的命令，也可以命令他“先拿勺子，然后舀起一勺饭，然后张嘴，然后送到嘴里，最后咽下去”。从这里可以看到，对于命令别人做事这样一件事情，不同的人有不同的理解，有人认为，如果我首先给接受命令的人以足够的训练，让他掌握各种复杂技能（即在硬件中实现对应的复杂功能），那么以后就可以用非常简单的命令让他去做很复杂的事情——比如只要说一句“吃饭”，他就会吃饭。但是也有人认为这样会让事情变的太复杂，毕竟接受命令的人要做的事情很复杂，如果你这时候想让他吃菜怎么办？难道继续训练他吃菜的方法？我们为什么不可以把事情分为许多非常基本的步骤，这样只需要接受命令的人懂得很少的基本技能，就可以完成同样的工作，无非是下达命令的人稍微累一点——比如现在我要他吃菜，只需要把刚刚吃饭命令里的“舀起一勺饭”改成“舀起一勺菜”，问题就解决了，多么简单。

这就是“复杂指令集”和“精简指令集”的逻辑区别。可能有人说，明显是精简指令集好啊，但是我们不好去判断它们之间到底谁好谁坏，因为目前他们两种指令集都在蓬勃发展，而且都很成功——X86是复杂指令集（CISC）的代表，而ARM则是精简指令集（RISC）的代表，甚至ARM的名字就直接表明了它的技术：Advanced RISC Machine——高级RISC机。

到了这里你就应该明白为什么RISC和CISC之间不好直接比较性能了，因为它们之间的设计思路差异太大。这样的思路导致了CISC和RISC分道扬镳——前者更加专注于高性能但同时高功耗的实现，而后者则专注于小尺寸低功耗领域。实际上也有很多事情CISC更加合适，而另外一些事情则是RISC更加合适，比如在执行高密度的运算任务的时候CISC就更具备优势，而在执行简单重复劳动的时候RISC就能占到上风，比如假设我们是在举办吃饭大赛，那么CISC只需要不停的喊“吃饭吃饭吃饭”就行了，而RISC则要一遍一遍重复吃饭流程，负责喊话的人如果嘴巴不够快（即内存带宽不够大），那么RISC就很难吃的过CISC。但是如果我们只是要两个人把饭舀出来，那么CISC就麻烦得多，因为CISC里没有这么简单的舀饭动作，而RISC就只需要不停喊“舀饭舀饭舀饭”就OK。

这就是CISC和RISC之间的区别。但是在实际情况中问题要比这复杂许许多多，因为各个阵营的设计者都想要提升自家架构的性能。这里面最普遍的就是所谓的“发射”概念。什么叫发射？发射就是同时可以执行多少指令的意思，例如双发射就意味着CPU可以同时拾取两条指令，三发射则自然就是三条了。现代高级处理器已经很少有单发射的实现，例如Cortex A8和A9都是双发射的RISC，而Cortex A15则是三发射。ATOM是双发射CISC，Core系列甚至做到了四发射——这个方面大家倒是不相上下，但是不要忘了CISC的指令更加复杂，也就意味着指令更加强大，还是吃饭的例子，CISC只需要1个指令，而RISC需要5个，那么在内存带宽相同的情况下，CISC能达到的性能是要超过RISC的（就吃饭而言是5倍），而实际中CISC的Core i处理器内存带宽已经超过了100GB/s，而ARM还在为10GB/s而苦苦奋斗，一个更加吃带宽的架构，带宽却只有别人的十分之一，性能自然会受到非常大的制约。为什么说ARM和X86不好比，这也是很重要的一个原因，因为不同的应用对带宽需求是不同的。一旦遇到带宽瓶颈，哪怕ARM处理器已经达到了很高的运算性能，实际上根本发挥不出来，自然也就会落败了。

说到这儿大家应该也已经明白CISC和RISC的区别和特色了。简而言之，CISC实际上是以增加处理器本身复杂度作为代价，去换取更高的性能，而RISC则是将复杂度交给了编译器，牺牲了程序大小和指令带宽，换取了简单和低功耗的硬件实现。但如果事情就这样发展下去，为了提升性能，CISC的处理器将越来越大，而RISC需要的内存带宽则会突破天际，这都是受到技术限制的。所以进十多年来，关于CISC和RISC的区分已经慢慢的在模糊，例如自P6体系（即Pentium Pro）以来，作为CISC代表的X86架构引入了微码概念，与此对应的，处理器内部也增加了所谓的译码器，负责将传统的CISC指令“拆包”为更加短小的微码（uOPs）。一条CISC指令进来以后，会被译码器拆分为数量不等的微码，然后送入处理器的执行管线——这实际上可以理解为RISC内核+CISC解码器。而RISC也引入了指令集这个就逻辑角度而言非常不精简的东西，来增加运算性能。正常而言，一条X86指令会被拆解为2～4个uOPs，平均来看就是3个，因此同样的指令密度下，目前X86的实际指令执行能力应该大约是ARM的3倍左右。不过不要忘了这是基于“同样指令密度”下的一个假设，实际上X86可以达到的指令密度是十倍甚至百倍于ARM的。

最后一个需要考虑的地方就是指令集。这个东西的引入，是为了加速处理器在某些特定应用上性能而设计的，已经有了几十年的历史了。而实际上在目前的应用环境内，起到决定作用的很多时候是指令集而不是CPU核心。X86架构的强大，很多时候也源于指令集的强大，比如我们知道的ATOM，虽然它的X86核心非常羸弱，但是由于它支持SSE3，在很多时候性能甚至可以超过核心性能远远强大于它的Pentium M，这就是指令集的威力。目前X86指令集已经从MMX，发展到了SSE，AVX，而ARM依然还只有简单而基础的NEON。它们之间不成比例的差距造成了实际应用中成百上千倍的性能落差，例如即便是现今最强大的ARM内核依然还在为软解1080p H.264而奋斗，但一颗普通的中端Core i处理器却可以用接近十倍播放速度的速度去压缩1080p H.264视频。至少在这点上，说PC处理器的性能百倍于ARM是无可辩驳的，而实际中这样的例子比比皆是。这也是为什么我在之前说平均下来ARM只有X86几十分之一的性能的原因。

打了这么多字，其实就是为了说明一点，虽然现在ARM很强大，但它距离X86还是非常遥远，并没有因为这几年的进步而缩短，实际上反而在被更快的拉大。毕竟它们设计的出发点不一样，因此根本不具备多少可比性，X86无法做到ARM的功耗，而ARM也无法做到X86的性能。这也是为什么ATOM一直以来都不成功的原因所在——Intel试图用自己的短处去和别人的长处对抗，结果自然是不太好的，要不是Intel拥有这个星球上最先进的半导体工艺，ATOM根本都不可能出现。而ARM如果尝试去和X86拼性能，那结果自然也好不到哪儿去，原因刚刚也解释过了。不过这也不意味着ARM以后就只能占据低端，毕竟任何架构都有其优点，一旦有应用针对其进行优化，那么就可以扬长避短。X86的繁荣也正是因为整个世界的资源都针对它进行了优化所致。只要能为ARM找到合适的应用与适合的领域，未来ARM也未必不可以进入更高的层次。

❹ 根据你的经验谈谈写php程序需要注意哪些问题

1、如果能将类的方法定义成static，就尽量定义成static，它的速度会提升将近4倍。
2、$row[’id’] 的速度是$row[id]的7倍。
3、echo 比 print 快，并且使用echo的多重参数（译注：指用逗号而不是句点）代替字符串连接，比如echo $str1,$str2。
4、在执行for循环之前确定最大循环数，不要每循环一次都计算最大值，最好运用foreach代替。
5、注销那些不用的变量尤其是大数组，以便释放内存。
6、尽量避免使用__get，__set，__autoload。
7、require_once()代价昂贵。
8、include文件时尽量使用绝对路径，因为它避免了PHP去include_path里查找文件的速度，解析操作系统路径所需的时间会更少。
9、如果你想知道脚本开始执行（译注：即服务器端收到客户端请求）的时刻，使用$_SERVER[‘REQUEST_TIME’]要好于time()。
10、函数代替正则表达式完成相同功能。
11、str_replace函数比preg_replace函数快，但strtr函数的效率是str_replace函数的四倍。
12、如果一个字符串替换函数，可接受数组或字符作为参数，并且参数长度不太长，那么可以考虑额外写一段替换代码，使得每次传递参数是一个字符，而不是只写一行代码接受数组作为查询和替换的参数。
13、使用选择分支语句（译注：即switch case）好于使用多个if，else if语句。
14、用@屏蔽错误消息的做法非常低效，极其低效。
15、打开apache的mod_deflate模块，可以提高网页的浏览速度。
16、数据库连接当使用完毕时应关掉，不要用长连接。
17、错误消息代价昂贵。
18、在方法中递增局部变量，速度是最快的。几乎与在函数中调用局部变量的速度相当。
19、递增一个全局变量要比递增一个局部变量慢2倍。
20、递增一个对象属性（如：$this->prop++）要比递增一个局部变量慢3倍。
21、递增一个未预定义的局部变量要比递增一个预定义的局部变量慢9至10倍。
22、仅定义一个局部变量而没在函数中调用它，同样会减慢速度（其程度相当于递增一个局部变量）。PHP大概会检查看是否存在全局变量。
23、方法调用看来与类中定义的方法的数量无关，因为我（在测试方法之前和之后都）添加了10个方法，但性能上没有变化。
24、派生类中的方法运行起来要快于在基类中定义的同样的方法。
25、调用带有一个参数的空函数，其花费的时间相当于执行7至8次的局部变量递增操作。类似的方法调用所花费的时间接近于15次的局部变量递增操作。
26、Apache解析一个PHP脚本的时间要比解析一个静态HTML页面慢2至10倍。尽量多用静态HTML页面，少用脚本。
27、除非脚本可以缓存，否则每次调用时都会重新编译一次。引入一套PHP缓存机制通常可以提升25%至100%的性能，以免除编译开销。
28、尽量做缓存，可使用memcached。memcached是一款高性能的内存对象缓存系统，可用来加速动态Web应用程序，减轻数据库负载。对运算码 (OP code)的缓存很有用，使得脚本不必为每个请求做重新编译。
29、当操作字符串并需要检验其长度是否满足某种要求时，你想当然地会使用strlen()函数。此函数执行起来相当快，因为它不做任何计算，只返回在zval 结构（C的内置数据结构，用于存储PHP变量）中存储的已知字符串长度。但是，由于strlen()是函数，多多少少会有些慢，因为函数调用会经过诸多步骤，如字母小写化（译注：指函数名小写化，PHP不区分函数名大小写）、哈希查找，会跟随被调用的函数一起执行。在某些情况下，你可以使用isset() 技巧加速执行你的代码。
（举例如下）
if (strlen($foo) < 5) { echo “Foo is too short”$$ }
（与下面的技巧做比较）
if (!isset($foo{5})) { echo “Foo is too short”$$ }
调用isset()恰巧比strlen()快，因为与后者不同的是，isset()作为一种语言结构，意味着它的执行不需要函数查找和字母小写化。也就是说，实际上在检验字符串长度的顶层代码中你没有花太多开销。
34、当执行变量$i的递增或递减时，$i++会比++$i慢一些。这种差异是PHP特有的，并不适用于其他语言，所以请不要修改你的C或Java代码并指望它们能立即变快，没用的。++$i更快是因为它只需要3条指令(opcodes)，$i++则需要4条指令。后置递增实际上会产生一个临时变量，这个临时变量随后被递增。而前置递增直接在原值上递增。这是最优化处理的一种，正如Zend的PHP优化器所作的那样。牢记这个优化处理不失为一个好主意，因为并不是所有的指令优化器都会做同样的优化处理，并且存在大量没有装配指令优化器的互联网服务提供商（ISPs）和服务器。
35、并不是事必面向对象(OOP)，面向对象往往开销很大，每个方法和对象调用都会消耗很多内存。
36、并非要用类实现所有的数据结构，数组也很有用。
37、不要把方法细分得过多，仔细想想你真正打算重用的是哪些代码？
38、当你需要时，你总能把代码分解成方法。
39、尽量采用大量的PHP内置函数。
40、如果在代码中存在大量耗时的函数，你可以考虑用C扩展的方式实现它们。
41、评估检验(profile)你的代码。检验器会告诉你，代码的哪些部分消耗了多少时间。Xdebug调试器包含了检验程序，评估检验总体上可以显示出代码的瓶颈。
42、mod_zip可作为Apache模块，用来即时压缩你的数据，并可让数据传输量降低80%。
43、在可以用file_get_contents替代file、fopen、feof、fgets等系列方法的情况下，尽量用file_get_contents，因为他的效率高得多！但是要注意file_get_contents在打开一个URL文件时候的PHP版本问题；
44、尽量的少进行文件操作，虽然PHP的文件操作效率也不低的；
45、优化Select SQL语句，在可能的情况下尽量少的进行Insert、Update操作(在update上，我被恶批过)；
46、尽可能的使用PHP内部函数（但是我却为了找个PHP里面不存在的函数，浪费了本可以写出一个自定义函数的时间，经验问题啊！）；
47、循环内部不要声明变量，尤其是大变量：对象(这好像不只是PHP里面要注意的问题吧？)；
48、多维数组尽量不要循环嵌套赋值；
49、在可以用PHP内部字符串操作函数的情况下，不要用正则表达式；
50、foreach效率更高，尽量用foreach代替while和for循环；
51、用单引号替代双引号引用字符串；
52、“用i+=1代替i=i+1。符合c/c++的习惯，效率还高”；
53、对global变量，应该用完就unset()掉；

具体参考 http://jingyan..com/article/a948d651432cb30a2dcd2ef8.html

❺ 关于C语言预处理命令

C程序的源代码中可包括各种编译指令，这些指令称为预处理命令。虽然它们实际上不是C语言的一部分，但却扩展了C程序设计的环境。本节将介绍如何应用预处理程序和注释简化程序开发过程，并提高程序的可读性。ANSI标准定义的C语言预处理程序包括下列命令：
#define，#error，＃include，#if，#else，#elif，#endif，#ifdef，#ifndef，#undef，#line，#pragma等。非常明显，所有预处理命令均以符号#开头，下面分别加以介绍。

一 #define
命令#define定义了一个标识符及一个串。在源程序中每次遇到该标识符时，均以定义的串代换它。ANSI标准将标识符定义为宏名，将替换过程称为宏替换。命令的一般形式为：
#define identifier string
注意：
1该语句没有分号。在标识符和串之间可以有任意个空格，串一旦开始，仅由一新行结束。
2宏名定义后，即可成为其它宏名定义中的一部分。
3 宏替换仅仅是以文本串代替宏标识符，前提是宏标识符必须独立的识别出来，否则不进行替换。例如：
#define XYZ this is a tes
使用宏printf("XYZ")；//该段不打印"this is a test"而打印"XYZ"。因为预编译器识别出的是"XYZ"
4如果串长于一行，可以在该行末尾用一反斜杠' \'续行。
#defineLONG_STRING"this is a very long\
string that is used as an example"
5 C语言程序普遍使用大写字母定义标识符。
6 用宏代换代替实在的函数的一大好处是宏替换增加了代码的速度，因为不存在函数调用的开销。但增加速度也有代价：由于重复编码而增加了程序长度。

二 #error
命令#error强迫编译程序停止编译，主要用于程序调试。
#error指令使预处理器发出一条错误消息，该消息包含指令中的文本.这条指令的目的就是在程序崩溃之前能够给出一定的信息。
三 #include
命令＃i nclude使编译程序将另一源文件嵌入带有＃include的源文件，被读入的源文件必须用双引号或尖括号括起来。例如：
＃include"stdio.h"或者＃include<stdio.h>
这两行代码均使用C编译程序读入并编译用于处理磁盘文件库的子程序。
将文件嵌入＃i nclude命令中的文件内是可行的，这种方式称为嵌套的嵌入文件，嵌套层次依赖于具体实现。
如果显式路径名为文件标识符的一部分，则仅在那些子目录中搜索被嵌入文件。否则，如果文件名用双引号括起来，则首先检索当前工作目录。如果未发现文件，则在命令行中说明的所有目录中搜索。如果仍未发现文件，则搜索实现时定义的标准目录。
如果没有显式路径名且文件名被尖括号括起来，则首先在编译命令行中的目录内检索。如果文件没找到，则检索标准目录，不检索当前工作目录。
四 条件编译命令
有几个命令可对程序源代码的各部分有选择地进行编译，该过程称为条件编译。商业软件公司广泛应用条件编译来提供和维护某一程序的许多顾客版本。
#if、#else，#elif及#endif
#if的一般含义是如果#if后面的常量表达式为true，则编译它与#endif之间的代码，否则跳过这些代码。命令#endif标识一个#if块的结束。
#if constant-expression
statement sequence
#endif
Eg:
#define MAX 91
#include <iostream>
using namespace std;
int main()
{
#if MAX > 99
cout<<"MAX is bigger than 99"<<endl;
#elif MAX > 90
cout<<"MAX is bigger than 90"<<endl;
#else
cout<<"MAX is smaller than 90"<<endl;
#endif
return 0;
}
跟在#if后面的表达式在编译时求值，因此它必须仅含常量及已定义过的标识符，不可使用变量。表达式不许含有操作符sizeof（sizeof也是编译时求值）。

#else命令的功能有点象C语言中的else；#else建立另一选择（在#if失败的情况下）。注意，#else属于#if块。

#elif命令意义与ELSE IF 相同，它形成一个if else-if阶梯状语句，可进行多种编译选择。#elif 后跟一个常量表达式。如果表达式为true，则编译其后的代码块，不对其它#elif表达式进行测试。否则，顺序测试下一块。

#if expression
statement sequence
#elif expression1
statement sequence
#endif

在嵌套的条件编译中#endif、#else或#elif与最近#if或#elif匹配。
# ifdef 和# ifndef

条件编译的另一种方法是用#ifdef与#ifndef命令，它们分别表示"如果有定义"及"如果无定义"。# ifdef的一般形式是：

# ifdef macroname
statement sequence
#endif

#ifdef与#ifndef可以用于#if、#else，#elif语句中，但必须与一个#endif。

#define MAX 91
#include <iostream>
using namespace std;

int main()
{
#ifdef MAX
cout<<"hello,MAX!"<<endl;
#else
cout<<"where is MAX?"<<endl;
#endif
#ifndef LEO
cout<<"LEO is not defined"<<endl;
#endif
return 0;
}
命令#undef 取消其后那个前面已定义过有宏名定义。一般形式为：
#undef macroname
命令#line改变__LINE__与__FILE__的内容，它们是在编译程序中预先定义的标识符。命令的基本形式如下：
#line number["filename"]
其中的数字为任何正整数，可选的文件名为任意有效文件标识符。行号为源程序中当前行号，文件名为源文件的名字。命令#line主要用于调试及其它特殊应用。注意：在#line后面的数字标识从下一行开始的数字标识。
#line 100 "jia"
cout<<"#line change line and filename!"<<endl; //line 100
cout<<__LINE__<<endl; //101
cout<<__FILE__<<endl; //jia
五 #pragma
命令#pragma 为实现时定义的命令，它允许向编译程序传送各种指令。
#pragma的作用是设定编译器的状态或者是指示编译器完成一些特定的动作。#pragma指令对每个编译器给出了一个方法,在保持与C和C++语言完全兼容的情况下,给出主机或操作系统专有的特征。依据定义,编译指示是机器或操作系统专有的,且对于每个编译器都是不同的。
其格式一般为: #Pragma Para
1 message 参数。
Message 参数能够在编译信息输出窗口中输出相应的信息，这对于源代码信息的控制是非常重要的。其使用方法为：
#pragma message(“消息文本”)
当编译器遇到这条指令时就在编译输出窗口中将消息文本打印出来。
当在程序中定义了许多宏来控制源代码版本的时候，自己有可能都会忘记有没有正确的设置这些宏，此时可以用这条指令在编译的时候就进行检查。假设希望判断自己有没有在源代码的什么地方定义了_X86这个宏可以用下面的方法
#ifdef _X86
#pragma message(“_X86 macro activated!”)
#endif
当定义了_X86这个宏以后，应用程序在编译时就会在编译输出窗口里显示“_
X86 macro activated!”。就不会因为不记得自己定义的一些特定的宏而抓耳挠腮了。

2 code_seg 参数。
格式如：
#pragma code_seg( ["section-name"[,"section-class"] ] )
它能够设置程序中函数代码存放的代码段，当开发驱动程序的时候就会使用到它。

3 #pragma once (比较常用）
只要在头文件的最开始加入这条指令就能够保证头文件被编译一次。这条指令实际上在VC6中就已经有了，但是考虑到兼容性并没有太多的使用它。

4 #pragma hdrstop
表示预编译头文件到此为止，后面的头文件不进行预编译。BCB可以预编译头文件以加快链接的速度，但如果所有头文件都进行预编译又可能占太多磁盘空间，所以使用这个选项排除一些头文件。
有时单元之间有依赖关系，比如单元A依赖单元B，所以单元B要先于单元A编译。你可以用#pragma startup指定编译优先级，如果使用了#pragma package(smart_init) ，BCB就会根据优先级的大小先后编译。

5 #pragma resource "*.dfm"
表示把*.dfm文件中的资源加入工程。*.dfm中包括窗体外观的定义。

6 #pragma warning( disable : 4507 34; once : 4385; error : 164 )
等价于：
#pragma warning(disable:4507 34) /* 不显示4507和34号警告信息。如果编译时总是出现4507号警告和34号警告, 而认为肯定不会有错误，可以使用这条指令。*/
#pragma warning(once:4385) // 4385号警告信息仅报告一次
#pragma warning(error:164) // 把164号警告信息作为一个错误。
同时这个pragma warning 也支持如下格式：
#pragma warning( push [ ,n ] )
#pragma warning( pop )
这里n代表一个警告等级(1---4)。
#pragma warning( push )保存所有警告信息的现有的警告状态。
#pragma warning( push, n)保存所有警告信息的现有的警告状态，并且把全局警告等级设定为n。
#pragma warning( pop )向栈中弹出最后一个警告信息，在入栈和出栈之间所作的一切改动取消。例如：
#pragma warning( push )
#pragma warning( disable : 4705 )
#pragma warning( disable : 4706 )
#pragma warning( disable : 4707 )
//.......
#pragma warning( pop )
在这段代码的最后，重新保存所有的警告信息(包括4705，4706和4707)。

7 pragma comment(...)
该指令将一个注释记录放入一个对象文件或可执行文件中。
常用的lib关键字，可以帮连入一个库文件。

8 progma pack（n）
指定结构体对齐方式。#pragma pack(n)来设定变量以n字节对齐方式。
n 字节对齐就是说变量存放的起始地址的偏移量有两种情况：
第一、如果n大于等于该变量所占用的字节数，那么偏移量必须满足默认的对齐方式，
第二、如果n小于该变量的类型所占用的字节数，那么偏移量为n的倍数，不用满足默认的对齐方式。
结构的总大小也有个约束条件，分下面两种情况：如果n大于所有成员变量类型所占用的字节数，那么结构的总大小必须为占用空间最大的变量占用的空间数的倍数； 否则必须为n的倍数。
下面举例说明其用法。
#pragma pack(push) //保存对齐状态
#pragma pack(4)//设定为4字节对齐
struct test
{
char m1;
double m4;
int m3;
};
#pragma pack(pop)//恢复对齐状态
为测试该功能，可以使用sizeof（）测试结构体的长度！