1.4 C编译器之争

相信很多的程序员会对编译之后的代码质量进行评估，尤其是在对效率敏感的场合。很多时候，我也在想，那段代码到底生成了多少行汇编指令，会消耗多少个机器时钟？NI在不遗余力地解决测试测量的关键问题时，却经常忽略工程师的需求通常是多方面的，有时是设计师、有时是程序员、有时是美工师。

作为程序员，我时常会关心LabWindows/CVI的编译器，因为一个开发工具的编译器就如一个人的心脏一样，任何一个人都不希望心脏出现问题或者使用心脏起搏器。就像我其实也十分讨厌LabWindows/CVI的外部编译器，但是却不得不用一样，外部编译器亦如起搏器，通电即可用，缺点是不得不带上一根导线，像一个长长的尾巴，没办法甩掉。

LabWindows/CVI的LCC编译器自从1998年David R. Hanson推出最后一个版本后就没有了下文，而另外的下文或称解决办法其实就是使用外部编译器。编译器这个最核心的东西非主业，并且对于NI来说也是有些难度的，因此不如把Microsoft、Borland或Intel的编译器直接拿过来，为我之用。NI的精明之处就在于其集成开发环境中有优秀的调试器，至于执行效率，优化代码，需要花上大量金钱，而又起不到预期效果的东西，不妨雪藏，这也许就是今天我们不能用LabWindows/CVI自身编译器进行代码优化的主因吧。

讲到这里，不禁让我想起了上个世纪的C/C++编译器大战。彼时，Microsoft的Visual C++ 1.0获得了巨大的成功，而Borland也凭借Borland C/C++ 3.1在编译市场上偏安一隅，这也可能是Borland最辉煌的C/C++编译器，此后，便在Visual C++的夹击下一蹶不振，直到最后一个版本5.5（此后的C++ Builder），自此从市场上消失。此外， Symantec C/C++、Watcom C/C++也因为对MFC版本支持的问题很快瓦解。

土崩瓦解的不仅仅是Borland，还有它的编译器，这一点可以从LabWindows/CVI的外部编译器支持上略见一斑，曾经编译器市场的巨人在LabWindows/CVI的外部编译器选项中只剩下了bcc32. exe，而且，从某一版本开始已经彻底放弃了Borland C++。没有更新的Borland自然会被大家所抛弃，最后也摆脱不了拆分、拍卖、被并购的命运，这个曾经排名世界第三的软件公司，在经历了十几年的坎坷后，消失了。说到这里，也不得不提起Delphi之父Anders Hejlsberg。这位Anders老兄后来去了Microsoft，开发出了Visual Java以及现在流行的C#。Anders是为数不多精通编译器的人，比起我们学了好多年编译原理也知其然而不知其所以然的人来说，不知要高上多少，哎，人啊，确实不同，服了！

LabWindows/CVI已经足够具有自己的特色了，是一款受人尊敬又备受争议并且十分另类的产品。受人尊敬是指它一直沿用ANSI C代码风格，工整、呆板又不失灵活，备受争议是指几次都听人说NI要放松甚至放弃对LabWindows/CVI的支持，另类的回调方式是Windows高级程序员很难很快适应的。LabWindows/CVI改变了我们的编程习惯，将面向工程的特色发挥到了极致，从语法和风格上来说，在十几年前，只要打开它那特色的面板，相信所有的测试测量工程师都会为之眼前一亮。

比如，以前费尽心思才能在Visual Basic中搞出来的温度计控件，在LabWindows/CVI中只要拖曳一下控件，设置几个参数就可以轻松实现了。它的回调函数足以让许多人感到新奇与新鲜——原来程序是可以这样设计的，而费尽心思却找不到回调原型定义的出处，熟悉即使是精通C/C++的人也可能会很少用到回调函数。虽然Windows API中有大量的回调函数，但毕竟，我们只关注功能设计而非语言本身，因此，不是每一个程序员都会去碰它的。LabWindows/CVI工程师不但要碰它，而且是每天需要与它打交道的，是不是很有意思，很新鲜，很刺激！