研究生，请你拒绝C++的爱
昨天晚上，考研考的无聊了便冲到实验室去写了一点构思已久的代码，在实验室里面听见一个老板说里面有个女生看见我的一个师兄学C++便也要去学。我真的是觉得这个女生勇气可嘉。
细细想来，夸张点说我都有点悲从中来。那个女生应该是做遥感方向的，[屏蔽]到C++这条绝路上让我颇有些觉得悲凉，更主要的是她是自愿跳C++这个大坑的，这甚至让我有些想荆轲同志去做Suicide Bomber时“风呼啦啦啊易河冻死人”的感受。当然，我承认我的这份感觉是掺杂了95%以上的故弄玄虚的水分的。只是我很想问那个学姐，C++有那么重要么？
我所在的学校是一个非常一般的以工科为主的高校，有特色学科，但是不是什么特色学校。按照我的感觉，现在的工科专业对于计算机这个Tool来说，完全是一种极度功利化的态度，这种态度让我感觉很有些不爽。实质上在现有的工科专业中，计算机大约和数学是差不多的，都属于工具性的学科，只不过数学更要基础一点而已，大家似乎都对数学带有着很敬畏的态度，而对计算机则是有些鄙夷。不合不分，不亲不离，工科专业和计算机之间的关系很是尴尬，就有些像xx novel，是个男人总希望去窥探那么一把然而又耻于让人知道。于是这种鄙夷+需要便构成了工科专业对计算机有些畸形的态度。正像我的老板一边对我说，你学那么多计算机有什么用，一边又让我帮助那些不太会编程的师兄师姐们解决一些问题。
但是事情真的是这个样子的么？大家都喜欢中庸的文化，所有的老师都建议我这样对计算机有特殊偏好的人对计算机的追求要“适可而止”，要精深专业而粗通“The Art of Computer Programming”。然后给我举出一大堆的理由，告诉我单纯的编程好的人有多么多么的[屏蔽]，他们面临专业问题的时候多么多么的无奈。我亲爱的老师们啊，在您劝导我不要走上一个极端的时候，为什么您要走上另外一个极端？
这个极端便是“极端的中庸”。不可否认，现代科学，尤其是工程科学是建立在大量的数学规则、海量计算和一些看起来合理或者不那么合理的推测和限制之上的。科学是讲究绝对理性的，而这个理性的基础却是感性（公理系统），而工程问题上，感性这一点表现的更为明显，有很多的问题实质上是半理性半感性所构成的，例如一些理想化的经济学模型，感性这个东西是有很多讲究的。和谐，美，合理化是理性化的感性所永远追求的主题。对不起，扯远了。也就是说，计算机在这里充当的角色通常有2种，进行海量计算，或者是使用理性去分析感性的模型。然而计算机本身也是个感性的东西。随着工程问题的日益庞大，相关的计算机软件也越做越大。当软件或者软件参与的计算复杂到一定程度的时候，便需要有理性化的感性去组织我们的工作使之容易为我们所用，往大了说就是要在工程中构造一种和谐的美。如果没有这种美，那么工程本身就可能会被魔鬼拖向深渊。
很可惜，有的时候人对美的感觉并不一定是天生的，后天的训练往往对于美感起到超乎想象的作用。训练本身不一定能让任何人都对审美达到一个不可逾越的高峰，但是至少它可以让大多数人都知道什么是美的，什么是丑的，这样才能树立正确的方向。
软件也是如此，没有相当的训练，写出来的一堆 Bad Smell 浓烈的代码任谁都是不敢用的。然而我们的传统观念恰恰在培养这些到处遗留 Bad Smell Code的人。如同鸡肋，食之无肉，弃之有味。
换过来来说，如果一个编程水平扎实然而专业基础太差的人负责整个专业软件的开发，这个软件的可靠度，易用性，功能完善度，用户友好度都有待考量。
我们该怎么办？这样的怪胎诞生自受过高等教育的人的手里，究竟是谁之过？
根本在于，我们忽略了“和谐”这样一个关键的词。和谐，而不是平均，这点在[屏蔽]上，在美学上都已经是有了定论的，美的极致不是0.5，而是0.618。怎样去寻找那0.618？
先来说说，我们现在有些什么样的人才。
简单来说，工科和计算机的结合不外乎以下五种。
第一种是纯专业化的，除了专业，别的都不懂。现在除了一些做纯学术的人外这样的人已经不多了，但是不可否认的是，即使他们不懂计算机，他们仍然是专业领域里面的探路者。道路艰险，虽然他手无缚鸡之力，但是他们的助手，同事，学生都会帮助他劈开荆棘，而如果失去了能看见那来自允诺之地的光的prophet，所有的人都会迷惘的。
第二种是专业为主计算机为辅的。这些人专业功底扎实，很扎实，非常扎实。虽然他们不知道专业的路怎么走，但是他们能清理掉脚边的灌木杂草，在茂密的丛林里探寻出一条路，并且能告诉后人这条道的正确与否。但是他们往往执迷于自己的路上，越走越远，直到有一天他们发现了真正的荆棘林之后，发现自己无法走通，于是悲惨的死在那里，只留下一个凄凉的墓碑。
第三种是专业为辅计算机为主。这些人不知道路怎么走，也不太清楚对于错，但是他们都知道那个摆在遥远未知的乌托邦，并愿意为之而奋斗。对工具熟练运用的他们是拓荒的中坚力量，如果不是他们披荆斩棘，所有人都走不出茂密的丛林。
第四种是专业结合计算机科学。注意，我这里说的是计算机科学。这些人是那些迷路在丛林之中的最好的本地向导。他们和第三种或者第二种人一样，不知道真正的方向，甚至连对错都不清楚，但是一旦遇到无法强行撼动的障碍时，他们便会带领团队绕开那些阻碍他们的泥泞
第五种是计算机的专业人才。对于先知看到的路，他们一无所知，不知所以。在某条特别的专业小径上，他们只能低着头，跟在前四种人后面，做些苦力的活计，却不能有半点想法，因为他们无法提出正确的想法。这些人实际上是一些悲情的人们，因为如果他们留在自己的家乡，或者出去寻找一些自己能做的活计，他们一样能活得很滋润。但是他们也是值得敬仰的，如果没有他们，单凭前四类那数量稀少的人，也是成不了什么事的。他们是专业领域值得然而没有得到尊敬的垫脚石。
你属于哪一种人？
不能不承认，这个世界上就是有全才。数学、物理界这种人出的最多，牛顿，高斯，莱布尼兹。偏文方面还有那个巨无霸的Da Vinci。单纯论数学界而言，自庞加莱以后，就再没出现过全才了。我的一个学数学的朋友在谈到庞加莱的时候那是心神往之，佩服得不得了。

但是我们总不能巴望着自己是全才吧，是全才，那就一定是天才，是天才，就不会待我们学校了。大家以后都不是什么圣人、天才，大家都是要混饭吃的，所以，醒醒吧。
我们的老师很知道这一点，所以他们总会好心的劝我们舍弃一部分，以免落个极度平庸的下场。这一点来说，老师们都是很明智的。但是很多的时候，原则上能把握的东西到了实际中就一定正确选择么？选择本身是一种放弃，是智慧，也是智慧的悲剧。难道有的时候我们没有觉得，自己放弃的东西太多，或者自己放弃的东西太少，以至于我们在离目标只有毫厘之差的时候饿死或者累死？这个度是这样的难以捉摸，使得我们往往会做出过于乐观或者过于保守的判断。
工科的人通常会做着悲观的估计，保守的行动，却又期待着乐观的结果。
今年我们专业硕士学位的GIS方向引进了一个据说开发做得非常好的人，南大的博士。然后说别的学院也抢着要他。从我们系主任眉飞色舞的情况来看，他是很中意这个人的。据说这个人能[屏蔽]开发一套接近于商业软件品质的作品。当然是不是有些吹牛的成分无从考证，也不重要，关键是，这个人的编程水平，包括软件工程素养都是不错的。再加上我们一个硕士学位却因为计算机水平很好而被破格留校的老师的例子来看，其实大家需要的是那些专业好，计算机更好的人。但是为什么所有老师都只会告诫我们，要学好专业课，而又让那些基本上不怎么会计算机的人去做一些难度比较高的程序呢？
因为他们忽视了第二种人和第三种人的差距。他们所做的一切，都是让第二种人越俎代庖去完成第三类人完成的任务。只所以忽视这种差异，恐怕是因为根深蒂固的工具无用论的思想。结果大部分试图跨过看来不起眼的礼器的人，都被绊了一跤，少数成功“代庖”的人便成为这种培养模式的丰功伟绩的贞节碑。但是实际上这种成功具备代表性吗？一点也不。而那些被绊倒的人很无辜的就被抹杀了。那些成功跨过去完成任务的幸运儿还回过头来向那些刚刚站到祭台上的可怜虫们招手，而那些可怜的人儿连脚下的路都不去看上一眼，冲动的扑过去，轰隆一下，摔得很惨。
所以说，正确认识计算机技术及计算机科学在工学界的地位、作用和他们的参与方式，才能使我们更好的对待、使用它。所有的科学、技术都是公正的灵魂，尊重了它，你就会得到相应的报酬。当然我知道我在我所在的专业只是一介平民，甚至连平民都不如，所以这话尽管我认为是正确的，但是说得就没有什么底气。
一个硕士研究生，究竟要对计算机掌握到什么样的程度？
工学硕士，是需要在自己专业有所造诣的人才能被授予这个学位的，很自然的，专业要被放到第一位。OK，这跟老师们的说法是一样的。但是，不可能有两个第一，所以计算机，尤其指编程能力，就一定要放到第二位。（当然，有想法的除外，硕士，甚至是博士都可以专业第二计算机第一，但是这样要付出更加艰辛的努力以克服跨专业带来的压力）从一开始，就不要指望他/她的编程能力能怎么样，核心放在解决问题，而不是给自己制造编程方面问题上。这一点其实大家都很容易看清，但是，即使看清了，仍然会做出一些不理智的事情，例如一个只会用用matlab脚本完成一些最简单计算的人非要去写一定规模的代码。但是实质上规模稍微一大，就会容易出漏子，岁月皆蹉跎。这一点以前我还可以说是很多人是形势逼迫。但就像学生都在一边控诉应试教育，一边拼了老命的抓分，老师稍微有些“素质教育”都要被质疑动机是一样，有些人已经习惯于一面控诉老师对编程的要求，一面将自己赶鸭子上架给自己活罪受。不是所有人都能在编程学习的炼狱中熬成正果的。所以学多少，自己的心里面一定要有个数，我个人的观点是，能解决问题（如果你的计算机烂到连自己的最基本的问题都搞不定，那还是别想着什么“适可而止”这种自欺欺人的话，好好学学才是正道），又不给自己带来新问题就好，不同专业不同领域，不同追求的要求都不一样，所以这个东西一定是因人因事而异的。
而那些希望在程序上有所突破，成为专业辅助计算机为主的人，在强化计算机的同时，不能放弃自己的专业素养，尤其是一些好不容易培养出来的专业感觉。这些感觉，一旦丧失，没有了环境的浸淫，想再培养起来就比较困难了。
扯了这么多，再次回到开始，C++有那么重要么？
是或者不是，这个答案并不重要，而我也不能正确地给出答案。如果真要说我只能刷刷[屏蔽]猾，告诉大家“因人而异”。
重要的是，我们用什么样的思路，用什么样的态度来衡量、评价、解决这个问题。
下面一段又是个老生常谈，随便到哪个搜索引擎上都能搜到一堆的话题：C++是怎么来的，它为什么而设计的，实际上人们又拿它来做什么，它有什么优缺点。我接触编程6年，其中C++占到4年，而且是我用的最好，也是最喜欢的语言。每次说到历史这个话题我总是有一大堆罗嗦的话要说。但是实际上我对C++的感觉到的最大的特点，却是书多，相关的书非常多，经典的著作相比较其它语言而言也算得上是最丰产的了。书多不外乎三种原因，一是流行面广，而是流行时间长，三是难度大。C++就那一点点编译器规则，一本ISO C++的手册搭配其发明者Bjarne Stroustrup的《The C++ Programming Language》就把语言机制讲的很清楚了，为什么它又有那么多的书来阐述一些所谓的Advanced Topics呢？因为灵活。C++极度灵活，这种灵活并不是动态语言的那种灵活，而是在于它承载了太多的需要，导致它变得极度灵活化，灵活的负面意思就是太多，太复杂，使得人们太容易混淆与各种语言机制的Chaos中。似乎南师大的荣耀教授在采访BS的时候还是BS在什么地方说过，如果C++要像现在的老师们这样教他自己都不会去学。
然后BS就举了一个Hello World的例子来说明他所认为的启蒙C++与一般授课使用的C++差别在什么地方，并以此说明C++其实并不复杂。好吧，我们就承认纯正的C++并不难学。但是不能忘了，我们的C++的对与错不是由我们决定的，而是编译器。工程上用的C++编译器绝对不会说不支持单纯的，蹩脚的C-Style（不是说CStyle蹩脚，而是说C中蹩脚的部分），不会不让你使用指针访问内存（指非必要的访问，例如动态数组），甚至不会拒绝你使用一些类似于Hacker的代码来完成一些极具技巧性和挑战性的工作。好吧，既然C++都支持，那么便不能拒绝你写出有此类特性的代码。更加致命的事情是，它的很多高阶机制，都是建立在底层机制基础上。最明显的例子就是Boost和STL。一旦编译出错，那么它的提示可能出在任何层面上，为了解决这些问题便又需要去学习那些较为底层的知识。C++的大坑就是这样一点一点挖出来的。
C++可供选择的东西太多。所以BS就出了一本书，叫《The Design and Evolution of C++》，专gate讨论了每种机制在C++当中被采纳的背景、他们当时的考虑、这些机制的适用范围。虽然说这本书属于“入gate教材”的行列，但是实际上我更加倾向于将这本书看成是在你品尝了C++大餐后的甜点。也就是说，尽管看起来有道理，但是作为预备知识同样不适合，于是你只能一边牢记大量的语言机制，一边应用，一边体验，一边读那些专著来纠正你的错误并填补你的不足，不可能有机会让你只走你需要走的路，大量的知识构成了一个扁平的知识框架，为了达到相对自由运用的水平，你需要学习的知识、需要获得的体验、需要弥补的弱点太多了。
如果说，只有C++可选的话，那么也就没什么办法了，大家只能去学那个能让人死去活来的东西。但是实际上我们并不如我们自己认为的那样无奈。大量的语言，总有比C++更加适合一般学生的。灵活的脚本语言Python/VBSP/JSP/Perl/Ruby/Lisp，半动态的（我是这么叫的。。。）Java/C#/VB/VB.NET/CLI，高效的 Ada/Fortran，桌面开发用功能强大的Delphi（人家的语言叫Object Pascal，但是也就那么一个编译器，所以无所谓了），这其中的绝大部分语言学习难度都要低于C++。
一般来说，有不少学校对于除了与电子和信息相关的专业都选择的是VB(以下说的VB均不指.NET)/VFP作为计算机二级的突破口。而这点教学，往往就成为了一个工科研究生仅有的编程基础。VFP这种被淘汰的使用范围狭隘的环境不讨论，VB作为RAD来说着实是个不错的选择。但是为应付计算机二级所教授的课程来看，并不能教会除了语法外的什么，况且所使用的VB6严格来说是Message Driven兼Object Based的一个开发环境，这都不利于学生从程序结构的高度（不是数据结构）去思考所撰写的代码。在短暂的学习以后我们会误认为界面框架就是软件的构架，于是我们便可以看见在毕业设计时候，那数百行可怜的代码都拥挤于Command1Click这样的字里行间。Object Based的语言既不能教会我们用过程的方式开发，也不能支持面向对象的程序设计方法。这些都是VB对进阶学习的最大障碍。
但是毕竟我们熟悉了VB的语法，知道了程序设计语言是怎么一回事。这已经花费了没有接触过编程的同学的相当长的时间，如果说我们还要去牵扯入C++那可怕的内存海洋中，还要被C++那恐怖的前后++所威胁，但是实际上我们不需要它也能过得很好，我们是不是有些冤大头了？
实际上，对于研究生阶段，最重要的就是要让我们学到的那一点点东西在尽可能少学别的东西的情况下发挥最大的价值。
前面我把VB一通好臭，我想VB都会不理我了。那么我们就另结新欢吧。找谁呢？
VB的弱点已经有点数了（很有数的话你我就不会在这儿瞎混了，早被M$请去了），那么便要去找一gate结构性比VB好，概念又不比VB艰深太多的语言（不是说它不能艰深，而是说，不理解那些艰深的东西我们一样能用的挺欢，最主要的是用起来要舒服，什么乱七八糟的内存管理问题，让编译器和RTL/VM去替你擦屁股吧）。JAVA/C#/Delphi/VB.net都算是不错的选择。虽然从我的角度来说，很不喜欢，非常不喜欢，特别不喜欢微软，但是我仍然将C#作为我的第一建议。
因为C#的开发环境好，速度也还算不错，桌面开发、企业级开发都很方便，微软的支持也很到家，但是对面向对象的支持有些强迫性了，可能初期会有些难度。
JAVA跨平台，工业基础好，从嵌入式到大型的分布式系统都能拿来做，但除了和C#一样的不利因素外，开发环境和程序库要比C#难用一些。
Delphi对对象和过程的程序设计方法都能支持良好，语言干净利索，检测严格，能培养出一个人好的编程习惯，但是它以后用途偏窄。
VB.NET就不用说（人家都叫VB了），跟VB比较接近，语法跨越小，但是太小了会有学习惰性，会低估语义和程序设计方法上的差异，弄点不伦不类的东西出来。
C++在程序控制上的能力，基本上都有了，而在在企业级开发方面，C++的弱势也得到了新语言不错的弥补。C++的另一个优势，效率方面呢？MATLAB。这个工具生来就是为了计算。作为研究生的工程运算来说，无论效率上还是功能上来说，通常都是够用的，而且也非常方便，避免了自行编程所面对的极为复杂的算法选择、编写、调试的问题（工程计算程序的调试难度是很大的）。再加上VBA/VBSP。为什么要带上VBA/VBSP？其实很多你需要完成的功能，往往都在软件中可以通过调用某些组件来完成。除了脱机编写完整的应用程序以外，对于大部分的问题的解来说，都可以直接使用系统所提供的环境方便的完成。使用这个环境所采用的语言，就是软件的脚本宏，而现有很多的软件所采用的宏语言都是VBA/VBSP。它的语法、架构、程序的设计都与VB非常接近，用来快速的构造原形或为编写实验提供帮助的程序来说，都能比较好的完成任务。
好了，在一gate通用语言+VBSP+MATLAB的帮助下（VBSP基本上是白送的，MATLAB经常是必须掌握的，如果你不需要掌握MATLAB，那么你的工作很可能也用不到C++的高效率），你还需要C++么？
如果你的答案是肯定的，那么我只能相信这个世界真的有爱情存在。我钦佩你的执著。那么请允许我告诉你我走过的路。
《The C++ Primer》/《The C++ Primer Plus》 不是一本书，但是都是入gate的。别为它的厚度吓倒，能看多少算多少，不难的。
《The C++ Programming Language》   手册。随身必备，供查阅。
Platform SDK     MSDN是个不错的选择，讲解相近，查阅方便。
《Thinking in C++》     从C++开始，接触OOP的深入解析
《Effective C++》《More Effective C++》
《Exceptional C++》《More Exceptional C++》 技巧、技术和技艺，编写C++程序必须注意的若干事项。
基本上到这里就差不多了，后面的就是诸如泛型、并发、元编程、模版、设计模式一类的话题了，不同的话题都有不同的问题背景和应用范围，这些往往对于大部分语言来说都是相同或者类似的。恭喜你，你们的爱情长跑到站了。
从此以后，研究生和C++过着磕磕碰碰却幸福的生活。

好长啊~~

没有看完.

忍着牙疼看完，有一定的指导作用，谢过

感觉楼主说的很有道理！

感觉全篇废话。
我觉得需要则学，不需要则不学。（又一句废话。）
真正的高手是使用最适合的工具来解决问题，而不是最流行的。
语言毕竟只是一种语言。。

C++是难，但是没人让你成为一个C++高手啊。。
我最近天天在用C++写程序，但是我不会C++。
真正要做到精通C++，必须了解底层机制，不然基本上是无法调试的。因为如文中所说，问题可能出在任何一层上。
但是我们真的需要精通吗。。？
C++有高度的灵活性，就是说它可以容忍任何的使用方法。你可以选择你喜欢的生活方式，而不是最复杂的。

另外作者最后列出的那些书。。。那是基本…………
至少还需要Inside C++ Object Model。。…………

有收获！

这种类似地文章好好多

看个人了，都是工具嘛

看个人了，都是工具嘛

有点帮助，在此谢过！

无语……