主题:为什么要学习(并使用)C++
为什么要学习(并使用)C++
显然,如果找不出要学习C++的理由,那么谈什么“正确的学习方法”等于是废话。
首先重复一句Bjarne的话:“我们的系统已经是极度复杂的了,为了避开C++的复杂性而干脆不用C++(Linus的做法),无异于因噎废食。”在所有可用C和C++的领域,C++都是比C更好的语言。当我说“更好的”时候,我说的是C++拥有比C更安全的类型检查、更好的抽象机制、更优秀的库。当然,凡事都有例外,如果你做的项目1)不大。2)编码中用不到什么抽象机制,[url=http://www.hklouis.com]ブランド バッグ[/url]甚至ADT(抽象数据类型,例如std::complex这种不含多态和继承的)也用不到,RAII也用不到,异常也用不到。3)你连基础库(如,简化资源管理的智能指针、智能容器)都用不着。那么也许你用C的确没问题;所以如果你的情况如此,不用和我争论,因为我无法反驳你。我们这里说的领域大致是Bjarne在“C++应用列表”里面列出来的那些地方。
底线是:如果把C++中的诸多不必要的复杂性去掉,留下那些本质的,重要的语言特性,简化语言模型,消除历史包袱。即便是C++的反对者也许也很难找到理由说“我还是不用C++”。在我看来,一个真正从实践意义上理性反对使用C++的人只有一个理由:C++的复杂性带来的混乱抵消乃至超过了C++的抽象机制和库(在他的特定项目中)带来的好处。
值得注意的是,这里需要避免一个陷阱,就是一旦人们认定了“C++不好”,那么这个理由就会“长出自己的脚来”,即,就算我们拿掉C++的复杂性,他们可能也会坚持还是不用C++,并为之找一堆理由。我假定你不是这样的人。不过,也许最可能的是他会说:“问题是我们今天用的C++并非如此(简洁),你的假设不成立。”是的,我的假设不成立。但虽然我们无法消除复杂性,我们实际上是可以容易地避开复杂性,避短扬长的。这也是本文的要点,容我后面再详述。
当然,到现在你可能还是会说。我还是不用C++,因为我可以用D;或者如果你本来做的项目就不需要C++,你则可能会说,我用Python。首先,如果你的项目能用Java/Python乃至Ruby做,那么用C++是自讨苦吃。因为能用那些语言代表你的项目在效率上本身要求就不高,那么用一门效率上讨不到太大好处,复杂性上却绰绰有余的语言,有什么价值呢?其次,如果你的项目效率是很重要的,你可能会说可以用D。然而现实是D在工业界尤其是国内被运用得非常少,几乎没有。而C++却有大量的既有代码,已经使用C++去做他们的产品的公司,在很长一段时间之内几乎是不可能用别的语言重写代码的,正如Joel所说,决定重写一个非平凡的代码基==自杀。所以,我们至少要注意以下两个明显的事实:
事实1:C++在工业界仍有稳定的核心市场。
这个事实大概不需要多加阐述,很多大公司的核心技术还是要靠C++来支撑的(见Bjarne主页上的C++应用列表)。所谓事实,就是未必是大家最愿意承认的情况,但又不得不承认。C++积累了庞大的代码基,这个代码基不是一朝一夕能够推翻的。D从语言角度来说的确优于C++,但最关键的就是还没有深入工业界(也许根本原因是没有钱支持,但这不是我们讨论的重点)。而C呢,根据Bjarne本人的说法,他的观察是主流工业界的趋势一直是“从C到C++”的,而不是反过来,至少在欧美是如此。在国内我们则可以通过CSDN上的招聘情况得到一个大致类似的信息。
事实2:C++程序员往往能享受到有竞争力的薪酬。
是的,这不是一篇不食人间烟火的技术文章。[url=http://www.jpgucci.com]ブランド コピー[/url]这个事实基于的逻辑很简单:物以稀为贵。Andrei Alexandrescu这次来中国SD2.0大会的时候,在接受采访时也说过:“最赚钱的软件(如MS Office)是C++写的”。孟岩也在blog上提到这么个事实,我想他作为CSDN的技术总编,业界观察肯定比我清晰深刻。所以我这里就不多废话了。
当然,以上逻辑并不就意味着在怂恿你去学C++,一切还要看你的兴趣。所以如果你志不在C++身处的那些应用领域,那这篇文章并非为你而写。
“C++的复杂性是根本原因”——一个有漏洞的推理
一旦我们认识了C++在一些领域是有需求的(值得学习和掌握的)这个问题之后,就可以接下来讨论“怎样正确学习和掌握C++”这个核心问题了。
其实,对于这个问题,Bjarne已经宣传了十年。早在99年的时候Bjarne就写了“Learning C++ as A New Language”,并在好几篇技术访谈(这里,这里,这里,还有这里)里面提到如何正确对待和使用C++中支持的多种抽象机制的问题。Andrew Koenig也写了一本现代C++教程《Accelerated C++》(这本书后面还会提到)。然而这么多年来,C++社群的状况改善了吗?就我所知,就算有改善,也是很小的。学习者还是盲目钻语言细节,只见树木不见森林;网上还是弥漫着各种各样的“技术”文章和不靠谱的“学习C++的XX个建议”;一些业界的有身份的专家还是在一本接一本的出语言孔乙己的书(写一些普通程序员八辈子用不着的技巧和碰不着的角落);而业界真正使用C++的公司在面试的时候还总是问一些边边角角的细节问题,而不是考察编程的基本素养(不,掌握所有的语言细节也不能让你成为一个合格的程序员)。这个面试理念是错误的,估计其背后的推理应该是“如果这个家伙不知道这个细节,那么估计他对语言也熟悉不到哪儿去;而如果他知道,那么虽然他可能并不是好的程序员,但我们还是能够就后一个问题进一步测试的”,这个理念的问题在于,对语言熟悉到一定程度(什么程度后面会具体建议)就已经可以很好的编程了(剩下的只需查查文档);而很多公司在测试“对语言熟悉程度”的时候走得明显太远了(比如,问临时对象生命期和析构顺序当然是无可厚非的,但问如何避免一个类被拷贝或者如何避免其构建在堆上?);当然,有些语言知识是必须要提前掌握的,具体有哪些后面会提到,面试的时候并非不能问语言细节,关键是“问哪些”。
显然,如果找不出要学习C++的理由,那么谈什么“正确的学习方法”等于是废话。
首先重复一句Bjarne的话:“我们的系统已经是极度复杂的了,为了避开C++的复杂性而干脆不用C++(Linus的做法),无异于因噎废食。”在所有可用C和C++的领域,C++都是比C更好的语言。当我说“更好的”时候,我说的是C++拥有比C更安全的类型检查、更好的抽象机制、更优秀的库。当然,凡事都有例外,如果你做的项目1)不大。2)编码中用不到什么抽象机制,[url=http://www.hklouis.com]ブランド バッグ[/url]甚至ADT(抽象数据类型,例如std::complex这种不含多态和继承的)也用不到,RAII也用不到,异常也用不到。3)你连基础库(如,简化资源管理的智能指针、智能容器)都用不着。那么也许你用C的确没问题;所以如果你的情况如此,不用和我争论,因为我无法反驳你。我们这里说的领域大致是Bjarne在“C++应用列表”里面列出来的那些地方。
底线是:如果把C++中的诸多不必要的复杂性去掉,留下那些本质的,重要的语言特性,简化语言模型,消除历史包袱。即便是C++的反对者也许也很难找到理由说“我还是不用C++”。在我看来,一个真正从实践意义上理性反对使用C++的人只有一个理由:C++的复杂性带来的混乱抵消乃至超过了C++的抽象机制和库(在他的特定项目中)带来的好处。
值得注意的是,这里需要避免一个陷阱,就是一旦人们认定了“C++不好”,那么这个理由就会“长出自己的脚来”,即,就算我们拿掉C++的复杂性,他们可能也会坚持还是不用C++,并为之找一堆理由。我假定你不是这样的人。不过,也许最可能的是他会说:“问题是我们今天用的C++并非如此(简洁),你的假设不成立。”是的,我的假设不成立。但虽然我们无法消除复杂性,我们实际上是可以容易地避开复杂性,避短扬长的。这也是本文的要点,容我后面再详述。
当然,到现在你可能还是会说。我还是不用C++,因为我可以用D;或者如果你本来做的项目就不需要C++,你则可能会说,我用Python。首先,如果你的项目能用Java/Python乃至Ruby做,那么用C++是自讨苦吃。因为能用那些语言代表你的项目在效率上本身要求就不高,那么用一门效率上讨不到太大好处,复杂性上却绰绰有余的语言,有什么价值呢?其次,如果你的项目效率是很重要的,你可能会说可以用D。然而现实是D在工业界尤其是国内被运用得非常少,几乎没有。而C++却有大量的既有代码,已经使用C++去做他们的产品的公司,在很长一段时间之内几乎是不可能用别的语言重写代码的,正如Joel所说,决定重写一个非平凡的代码基==自杀。所以,我们至少要注意以下两个明显的事实:
事实1:C++在工业界仍有稳定的核心市场。
这个事实大概不需要多加阐述,很多大公司的核心技术还是要靠C++来支撑的(见Bjarne主页上的C++应用列表)。所谓事实,就是未必是大家最愿意承认的情况,但又不得不承认。C++积累了庞大的代码基,这个代码基不是一朝一夕能够推翻的。D从语言角度来说的确优于C++,但最关键的就是还没有深入工业界(也许根本原因是没有钱支持,但这不是我们讨论的重点)。而C呢,根据Bjarne本人的说法,他的观察是主流工业界的趋势一直是“从C到C++”的,而不是反过来,至少在欧美是如此。在国内我们则可以通过CSDN上的招聘情况得到一个大致类似的信息。
事实2:C++程序员往往能享受到有竞争力的薪酬。
是的,这不是一篇不食人间烟火的技术文章。[url=http://www.jpgucci.com]ブランド コピー[/url]这个事实基于的逻辑很简单:物以稀为贵。Andrei Alexandrescu这次来中国SD2.0大会的时候,在接受采访时也说过:“最赚钱的软件(如MS Office)是C++写的”。孟岩也在blog上提到这么个事实,我想他作为CSDN的技术总编,业界观察肯定比我清晰深刻。所以我这里就不多废话了。
当然,以上逻辑并不就意味着在怂恿你去学C++,一切还要看你的兴趣。所以如果你志不在C++身处的那些应用领域,那这篇文章并非为你而写。
“C++的复杂性是根本原因”——一个有漏洞的推理
一旦我们认识了C++在一些领域是有需求的(值得学习和掌握的)这个问题之后,就可以接下来讨论“怎样正确学习和掌握C++”这个核心问题了。
其实,对于这个问题,Bjarne已经宣传了十年。早在99年的时候Bjarne就写了“Learning C++ as A New Language”,并在好几篇技术访谈(这里,这里,这里,还有这里)里面提到如何正确对待和使用C++中支持的多种抽象机制的问题。Andrew Koenig也写了一本现代C++教程《Accelerated C++》(这本书后面还会提到)。然而这么多年来,C++社群的状况改善了吗?就我所知,就算有改善,也是很小的。学习者还是盲目钻语言细节,只见树木不见森林;网上还是弥漫着各种各样的“技术”文章和不靠谱的“学习C++的XX个建议”;一些业界的有身份的专家还是在一本接一本的出语言孔乙己的书(写一些普通程序员八辈子用不着的技巧和碰不着的角落);而业界真正使用C++的公司在面试的时候还总是问一些边边角角的细节问题,而不是考察编程的基本素养(不,掌握所有的语言细节也不能让你成为一个合格的程序员)。这个面试理念是错误的,估计其背后的推理应该是“如果这个家伙不知道这个细节,那么估计他对语言也熟悉不到哪儿去;而如果他知道,那么虽然他可能并不是好的程序员,但我们还是能够就后一个问题进一步测试的”,这个理念的问题在于,对语言熟悉到一定程度(什么程度后面会具体建议)就已经可以很好的编程了(剩下的只需查查文档);而很多公司在测试“对语言熟悉程度”的时候走得明显太远了(比如,问临时对象生命期和析构顺序当然是无可厚非的,但问如何避免一个类被拷贝或者如何避免其构建在堆上?);当然,有些语言知识是必须要提前掌握的,具体有哪些后面会提到,面试的时候并非不能问语言细节,关键是“问哪些”。