C++编程杂谈之一:编译器[VC/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变得微不足道了（我没有藐视它们的意思）.

我但愿全部的人都不要反复我走过的学习之路,我的路是崎岖的,至少在学习的历程中我浪费了很多时间（我曾经幼稚的认为目前的编程只是举行功效的扩大罢了,如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利用在每天碰到的程式计划问题中,也因此显得再懂得不过.