网上有很多各种编译器的优劣比较的东西,我写这些东西并不是想支持或否定某些东西,因为我始终认为在编程的领域中,我只是一个初学者,并没有资格来评判什么(况且我也不想去评判),我只是想讲述一下个人学习道路上的感受。
学编程的一个必备的条件是你要有一个实践的平台--一个相应的编译器,没有这个条件,一切都是空谈。选择编译器之前,首先选择的是语言(这个我想不必更多的解释了),这里我假设你选择了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!
学编程的一个必备的条件是你要有一个实践的平台--一个相应的编译器,没有这个条件,一切都是空谈。选择编译器之前,首先选择的是语言(这个我想不必更多的解释了),这里我假设你选择了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!