C++编程杂谈之一：编译器
网上有许多各类编译器的黑白较量的对象，我写这些对象并不是想支持或否认某些对象，因为我始终认为在编程的规模中，我只是一个初学者，并没有资格来评判什么（何况我也不想去评判），我只是想报告一下小我私家进修阶梯上的感觉。
学编程的一个必备的条件是你要有一个实践的平台–一个相应的编译器，没有这个条件，一切都是空谈。选择编译器之前，首先选择的是语言（这个我想不必更多的表明白），这里我假设你选择了C或C++。
此刻最风行的编译器恐怕应该是微软的VC了，在继承之前，我想再提一下一个重点：VC是一个编译器，只是一个用来把C++的代码生成为可执行文件的东西罢了（虽然我说的有一些简化，可是认识这一点很重要，固然你可以在许多处所看到雷同的话，但我照旧要提，我但愿每一个进修编程的人最好从一开始就知道它，而不是走了许多弯路今后再来醒悟）。别的一种强大的编译器就是Borland C++ Builder（后头我都将以BCB来取代）。
假如你在利用VC，我想问一下，你为什么用它？我想许多人基础无法答复这个问题，大多无法答复的原因很明明：1）传闻的，VC是最好的；2）微软的产物；3）只知道这个。虽然更有甚者是一开始就把VC作为一门语言来学，呵呵，我相信必然有这样的人的！每当谈及这些问题的时候，我会以为许多时候，软件行业中技能并不是优秀软件的全部，VC必然是最好的么？VC为什么会这么乐成？我不得不服气微软的贸易计策。关于VC是如何乐成的，我强烈推荐一篇文章–《C/C++圣战》，作者李维，《措施员》杂志2001.10月。
一个编译器毕竟带给我们什么？在早期，编译器其实就是一个简朴的文本编辑器+库（头）文件+编译措施，许多早期的措施员会利用一些其他的编辑器来书写本身的措施，然后再利用编译器来编译。此刻我们利用的编译器凡是称为集成开拓情况（IDE），这一范例的开拓情况为我们提供了许多对象：利便的开拓方法、完善的辅佐系统、富厚的库和一些特有的特性。
在某个特定的平台下编程你需要体贴的主要有两件工作：1.是否支持你所利用的语言；2.平台特性（WINDOWS下platform sdk为我们提供了一切）。在WINDOWS平台下，我们可以利用C++来编程，剩下的就是平台特性了。WINDOWS为我们提供了一系列富厚的API函数，并且这些函数在差异的WINDOWS版本上会略有差异。早期的WIDNOWS编译器就是在纯真的C/C++编译器中对平台特性提供支持，并没有提供更多的对象，假如你只规划利用WINDOWS API的话，编译器的选择大概只是编译优化水平的选择罢了（也许你该选择BCB，听说要比VC优化的好一些，我没有真实的数据来比拟，但BORLAND公司的编译器优化一向被认为是优秀的）。真正发生变革的是类库封装的开始。微软提供了MFC类库，BORLAND提供了OWL类库。所谓类库就是提供了对WINDOWS API的一种封装，相信每个写过WINDOWS API措施的人都有一个别会，一个最简朴的WINDOWS窗口措施都需要几十行代码，这足以令初学者望而却步，对比之下DOS下的经典例程"hello world"却只需要短短的一行代码（所以DOS时代才令我吊唁–简朴，明白。呵呵）。类库的呈现正是为了办理这个问题，WINDOWS类库主要是对WINDOWS下的API函数举办封装，来到达这样的目标：1）简化我们编程进程中的反复的简朴事情（只建设窗口、成立动静环这样的单调事情）；2）使我们的事情更切合面向工具的气势气魄。如一个MFC中的窗口：
CWnd MyWindow;
MyWindow.Create(…);//这里省略了参数
我们只需要建设一个窗口工具，通过工具的Create要领来建设窗口就可以了，完全不必再去体贴底层的一些对象，整个进程就象工场的一个出产进程–这也正是面向工具的精力地址（假如你此刻不能体会这一点，不消着急，今后逐步的自然会大白的）。
听起来都是顿悟的例子。莫非进修COM/OLE出格需要宗教信仰吗？我想是因为这些技能出格需要高度抽象思考，使得霍然开朗後的喜悦庞大到令人以为是一种「溘然的神迹来临」。其实你我都大白不外，常识点的打破，是靠常识面的累积。
许多时候，当你转头去想以前的不大白问题的时候，你是否有这样的感受？我相信谜底是必定的。我想问题的要害就在上面一段话的末了：常识点的打破，是靠常识面的累积 对我来讲，当我打仗了BCB之后的一段时间，我溘然就大白了，它和VC仅仅是提供了一个封装了差异类库的编译器罢了，真正要害的问题是C++呀！也正是在这今后，我才真正开始入门，而这都是我进修编程一年多今后的工作了。假如没有谁人偶尔的时机，我打仗过一次BCB，也许到此刻我还无法分清楚那些是VC提供的、那些是尺度C++提供的。与C++对比，MFC和OWL变得微不敷道了（我没有小看它们的意思）。
#p#分页标题#e#
我但愿所有的人都不要反复我走过的进修之路，我的路是曲折的，至少在进修的进程中我挥霍了许多时间（我曾经幼稚的认为此刻的编程只是举办成果的扩充罢了，如WINDOWS SDK等，完全忽略了面向工具的思想存在）。我一直认为VC是一个优秀的编译器，可是当你构建一个MFC措施的时候，许多书籍先容的入门方法显得相对松散，给你的感受是在利用一个复杂的WINDOWS函数库而不是一个类库，很多教科书忽略了MFC中面向工具观念的增强，而仅仅是一些成果上的实现，而在BCB中，面向工具的思想相对要强化一些。
我写这些并不是想说明什么样的编译器好和什么样的编译器欠好，最终的选择权大概不在你我的手中，许多时候是平台或其他因素的限制而导致你必需利用某种编译器。我只是想说明一些思想，因为我无法把我想说明的这些问题提炼出来，所以松散的写了许多，最终我想说的就是不要因为一些不须要的原因去拒绝–Never！
以上内容仅代表小我私家概念，如有不妥，接待接头。
VC和BCB回收了各自差异的方法（MFC和OWL）来封装，各人回收的手段各有所长，很难说哪个更好，独一让MFC占优的应该是操纵系统的优势了。对比之下，我小我私家认为起码在措施生成的环节上，BCB要好一些（其实BCB我小我私家也是欣赏过一下，总共时间不外2-3天，只是做一次相识罢了），在VC中，假如你为一个通用控件如CListCtrl关联一个变量，写过措施的人应该知道，编译器会作为一个类成员变量生成，而在BCB中，这个变量是以类成员指针的方法存在的，有什么区别呢？大量的局部变量会造成仓库的溢出，这也是为什么你无法建设一个char largestr[100000000]的原因了。假如你在VC的措施中利用了许多这样的变量的话，天知道会怎么样（固然仓库中的变量存取更有效率）。
在一段时间以前，我也具有许多很是糟糕而幼稚的想法，直到某一天，我大白了许多。其实很多学计较机的人城市有沟通的感觉，以下的一段摘自候捷先生的散文：
南宗与北宗，顿悟与渐悟
佛法有顿悟，学问可没有。假如有人说，我溘然在某一天对Java开悟了，对OO开悟了，对MFC开悟了…，我想那是他决心（为了炫耀）或非决心（因为遗忘）地忽略了他所谓的「悟」那一天之前的所有尽力。是的，那叫渐悟，不是顿悟。
Inside OLE 一书作者 Kraig Brockschmidt 在他的序内里有这段话：
1993年一月的某个周日下午，当我正做着与OLE全然无关的工作时，我溘然得到了所谓的 OLE 涅磐状态。所有关於OLE的支支节节溘然全都归定位。在六个月的恍惚心智之後，我溘然看清楚了OLE。
Essential COM一书作者Don Box在他的序内里亦有一段雷同的话：
幸运的是有一天（1998年八月八日），溘然像神迹一般，COM对我变得再大白不外，我终於相识了COM的念头。如何把这个programming model应用在天天碰着的程式设计问题中，也因此显得再大白不外。
