云代码会员 - 云代码空间
——
|
网上有很多各种编译器的优劣比较的东西，我写这些东西并不是想支持或否定某些东西，因为我始终认为在编程的领域中，我只是一个初学者，并没有资格来评判什么（况且我也不想去评判），我只是想讲述一下个人学习道路上的感受。 学编程的一个必备的条件是你要有一个实践的平台--一个相应的编译器，没有这个条件，一切都是空谈。选择编译器之前，首先选择的是语言（这个我想不必更多的解释了），这里我假设你选择了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方法来创建窗口就可以了，完全不必再去关心底层的一些东西，整个过程就象工厂的一个生产过程--这也正是面向对象的精神所在（如果你现在不能体会这一点，不用着急，以后慢慢的自然会明白的）。 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应用在每天遇到的程式设计问题中，也因此显得再明白不过。 听起来都是顿悟的例子。难道学习COM/OLE特别需要宗教信仰吗？我想是因为这些技术特别需要高度抽象思考，使得霍然开朗後的喜悦巨大到令人觉得是一种「突然的神迹降临」。其实你我都明白不过，知识点的突破，是靠知识面的累积。 很多时候，当你回头去想以前的不明白问题的时候，你是否有这样的感觉？我相信答案是肯定的。我想问题的关键就在上面一段话的结尾：知识点的突破，是靠知识面的累积 对我来讲，当我接触了BCB之后的一段时间，我突然就明白了，它和VC仅仅是提供了一个封装了不同类库的编译器而已，真正关键的问题是C++呀！也正是在这以后，我才真正开始入门，而这都是我学习编程一年多以后的事情了。如果没有那个偶然的机会，我接触过一次BCB，也许到现在我还无法分清楚那些是VC提供的、那些是标准C++提供的。与C++相比，MFC和OWL变得微不足道了（我没有小看它们的意思）。 我希望所有的人都不要重复我走过的学习之路，我的路是曲折的，至少在学习的过程中我浪费了很多时间（我曾经幼稚的认为现在的编程只是进行功能的扩充而已，如WINDOWS SDK等，完全忽略了面向对象的思想存在）。我一直认为VC是一个优秀的编译器，但是当你构建一个MFC程序的时候，很多书籍介绍的入门方式显得相对松散，给你的感觉是在使用一个庞大的WINDOWS函数库而不是一个类库，许多教科书忽略了MFC中面向对象概念的加强，而仅仅是一些功能上的实现，而在BCB中，面向对象的思想相对要强化一些。 我写这些并不是想说明什么样的编译器好和什么样的编译器不好，最终的选择权可能不在你我的手中，很多时候是平台或其他因素的限制而导致你必须使用某种编译器。我只是想说明一些思想，因为我无法把我想说明的这些问题提炼出来，所以松散的写了很多，最终我想说的就是不要因为一些不必要的原因去拒绝--Never！ 以上内容仅代表个人观点，如有不当，欢迎讨论。 |