坛子里在讨论入门C++用IDE好还是命令行好，这里谈点我的看法。
一家之言，欢迎拍砖。
单就学习C++语言而言，建议初学者还是不要用IDE。原因很简单，IDE牵引性太强了。
比如VC吧，上来就建立工程，然后就是一大堆向导选项，最后一出来就是搭建好的一个框架，然后，编。。。。
我当年学习VC，第一次下来，当场晕厥，我编啥哦？！！！
一个程序，总要有个入口，出口，用VC的MFC框架，初学者连入口都找不到，我连初始化代码在哪运行都搞不懂，怎么编？
这种情况持续了两三年，最后，看了侯老师的深入浅出，才算彻底搞懂了MFC的框架结构，但侯老师也是通过把MFC拆了，一点点展示给读者看，我才看懂的。
后来发现，VC和MFC是一套工程系统，它设计的前提是一个工程设计人员，在很熟练VC的情况下，可以迅速用它搭建应用程序平台，但对于初学者，很不友好。
反过来，我从VC转到gcc，反而容易，很简单，都是main开始，一看就明白，然后，C和C++该写啥就写啥，反正专心实现自己的功能，实现玩，做个makefile，编译就ok。
顺便说一句，makefile我只学了两个小时就会了，比MFC的两年多，节约了一点时间。呵呵。
事实上，我真正开始写的第一个windows工程，其实都还是WinMain的，当时确实搞不懂MFC的框架体系，而且，误导非常严重，老是把不相干的东西弄到一起，要么一起学会，要么都不会。
大家可能还记得我发的帖子《我学习MFC的一些疑惑》，其实这些都是当年我自己晕头的地方，直到很多年以后，我通过WinMain和gcc，彻底弄懂了线程、窗口等不同的运行机制，才发现被MFC忽悠了。这些东西根本没有关系。原来玩Socket，不需要一定用类，原来玩线程，也不需要用类，原来玩窗口，还是不需要用类，我晕。。。。
命令行方式，看似简陋，但是它能让程序员专心于自己的事物，不用学完C++之后，为了学习使用VC，还要学一大堆Windows系统相关的开发，这些东东，和系统绑定性太强，其实通用性不高的，gcc就用不到窗口开发的内容。Linux的XWindows有人家自己的标准。
这可能也是微软的绑定策略，其实微软并不喜欢有太多跨平台的C++程序员，因为这对于他卖Windows系统没有帮助，所以微软所有的开发类文档，必然先提Windows，再提C++标准，好像只有Windows平台才能开发C++软件一样，其实是典型的商业误导和欺骗，大家别被忽悠了。
顺便说一句，很多时候，C++实现工程项目，和Windows一点关系都没有，也只有UI相关的部分才会用到Windows界面开发，在工程中，我们团队里最多只有1~2个人负责UI，其他的人，写的都是内部功能代码，用printf调试，没MFC什么事儿。
说到printf，不得不说，VC有点球莫名堂，所有的Windows程序，没有控制台，printf被屏蔽了，很多初学者当场又晕了，要知道，大家的第一个程序都是printf("hello world!\n");
这里大家可能要说了，肖老师不是C++程序员，printf是C的，C++要用cout，OK，OK，就cout，Windows程序一样没戏，还是输不出来。
程序员连个基本的输出手段都没有，要想打印一句话到窗口上，我粗略算过，WinMain大概需要86句话启动一个窗口，MFC就不敢算了，太多了，巨无霸的一个框架。
至于吗？给人的感觉，我们本来想喝杯矿泉水，结果被微软强行灌了一口二锅头。
微软这个习惯很不好，他以不惜得罪所有程序员的代价，来强行推广它的windows程序开发，其实是很不厚道的行为。
嗯，再说调试，VC的IDE调试还是很方便的，可以跨线程单步跟踪，不过，实际工程中，稍微涉及到一点复杂的计算，和性能沾点边的，单步跟踪基本都无效。为啥，我这边才走一步，那边别的线程已经几百个报文和操作过去了，单步跟踪和实际运行，看到的根本就是两码事，所以高性能程序debug，一般都是用printf大法，把信息打出来分析。呵呵，问题又出来了：printf哪去了？
有IDE的VC，其实已经不能算一个C++的学习和开发环境，而是一个专门为微软开发Windows程序的开发工具而已。
呵呵，这也是微软的爱好，喜欢弓虽女干标准。C++被改成VC，html被改成IE html，http被改成http 4 IIS，java不能动，就搞个.net平台来抗衡。
这当然没有错，商人嘛，赚钱为第一要务，不过，我们程序员还要吃饭呢，如果哪天微软倒了，那些只会开发4 Win应用的兄弟们找谁吃饭去？
就好比Borland死掉了，所有的Dephi和C++Builder的高手们心里异常失落一样。
学技术，尽量学习通用标准，不要太偏向某个公司了，不要把自己的脑袋绑到别人的裤腰带上，这是我这么多年的开发经验。
我一直研究跨平台编程，就是有这个担心，如果哪天微软死了，我好歹还有Linux，如果哪天PC机死了，我好歹还可以玩嵌入式，呵呵，死道友不死贫道，只要我不死就好了。
所以，我觉得，初学者，学习，最好学习最标准的东东，最好不要依赖谁，养成独立自主的开发习惯，万事，有成熟的算法，代码，就用，没有，就自己做，这样的程序员，生命力是最强悍的。
这里再多说一点点，很多人学Java，学PHP，其实都可以，不过，我建议最好还是学习一点C和C++。为啥，C和C++深入，能帮你理解很多脚本语言不能理解的东东，你可以亲手控制线程的生死，可以亲眼看到时间片的切换，内存的分配，而且，这些都是你可以掌控的。
我其实以前很喜欢使用VB的，简单嘛，画来画去，一个程序就画出来了，所有的关键算法，都是控件完成的，我只管组织。做个小东西来的快。
但后来，我就问自己一个问题，如果有一天，我做个项目，但是，我找不到那个控件怎么办？我吓出一身冷汗，结果是我也不会做，只有被老板炒掉。后来我就发现，不担心被炒掉的，其实是做控件的人，是那些玩C和C++的人，所以，我就和自己说，要学C++。
其实想必做Java和PHP的朋友应该有这种感觉，自己的程序的优劣，受制于人，一个PHP写的web服务器，apache能有多大效率，自己的服务器极限就只有多大效率，一点办法也没有。而我们做C和C++的程序员，则经常喜欢替换掉apache内部一个什么模块，把它的效率提升一点看看。
不是说Java和PHP不好，这些语言能经历市场的证明，表示有其强悍的生命力的，尤其是Java虽然是Sun一家的，但其本身的标准已经脱离了这家公司的控制，实现了跨平台通用，这就注定了Java将会是一门伟大的语言。目前它的市场比C和C++都大。
不过我这里仅仅是建议一下，其他语言的程序员，在有空的时候，建议看一点C和C++，尤其是你们不太熟悉的指针、内存，底层等算法，有了这些知识，你们写其他语言，也会彪悍许多的。
呵呵，说了这么多，好像有点跑题了。
不过，我想我这里能够给大家传递一个信息，不管什么语言，尽量学习标准的，基础的东东，不要去依赖太多别人的成果，那么自己的问题解决能力就会越来越强。另外，基础和标准学好了，其实用C++开发还是用JAVA、PHP开发，其实写出来的程序，应该差别不大。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以后的世界，是并行计算的世界。
而并行计算的精髓，则是与语言无关的。
所有支持线程操作的语言，都可以视为并行计算语言，与是不是脚本语言没有太多关系的。
不过呢，通过C++学习并行计算会方便一点点，因为C++比较低层，相应程序员要处理的东西多一点，会多学点东西的。
呵呵，建议大家通过C++学习并行计算。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
初学C++时，可以用IDE，这不是我自相矛盾，毕竟，有个IDE帮助自己自动完善代码，管理工程，还是很方便的，你说的这个轻量IDE我没有用过，不好评价，不过，UE也有类似IDE的功能，我见人用过，甚至，就用VC也可以啦，上来就建立控制台工程好了。
只要先别碰MFC，等学几个月C++后，有了基础，再正式学习MFC比较好。
makefile一定要学一点，那个你能精确控制每个cpp文件的编译，比VC的IDE里面一个F7，多很多信息，可以学到很多细节的东东。
其实学Windows开发，如果用我说的这个方法，很多人就会不由自主去沿着C/C++、Win32API、MFC这个路线走下去，看见没，MFC会放到最后，因为以main方式学习，一般都会直接按纯C的方式走下去，最后再走C++，这样有一个好处，学习者是先学习了api，心里会把MFC看成api的一个C++解释而已，对api的重视程度比较高。这样会比较好一点，不至于被误导认为，Windows编程，离开MFC不转。
这样做有什么好处呢？其实C这个东东，有个天然的优势，就是它编译出来的obj、dll被行业认为是接口标准，各种语言，VB、Java、PHP、C#。。。都能直接调用这类dll，它的.h文件，可以很轻松地翻译成其他语言的表达，其他语言就可以很轻松地在.dll或者.lib中找到符号表，进而调用。
所以，C语言可以说是最纯正的api语言，是计算机语言编程里面的英语，各种语言，一旦使用C接口规约，就差不多可以认为支持跨语言开发了。
C++可不是，MS为C++也准备了dll的接口规约，实际上，要是调用起来，那叫一个费劲。其他语言，一般都晕菜。
我看过台湾高手写的基本VB的深入开发，可以实现非常彪悍的功能，仔细看进去，晕，全在调用api，这个时侯的VB，仅仅是一个shell而已，其开发的深度和力度，已经和VC基本一样了，所以我当时就理解了，Windows开发，说到底就是Win32API开发，和上层业务使用的语言，一点关系都没有，并且，全部是C接口。
嗯，还有个旁证，如果C++实现的模块那么好用，MS没有必要再开发一个COM接口的，为啥，C++的接口规约，别的编译器理解起来，确实太难了，只有再封装一层，大家都来远程调用。这个远程调用就太简单了，只要这门语言支持socket之类的网络传输机制，甚至只要Windows系统支持，把几个数据传到远端计算，再回传结果，就太容易了，但看见没，这和语言的标准性已经没有太多关系了。其实，这种情况下，不要说C++，是个语言，只要能支持远程调用，都可以实现。
嗯，说到这里，也说说COM接口，太重了，程序的call子行为，在程序运行中是一个高频发生的行为，这中间加入一层远程接口，考虑一大堆传输事务，太重了，COM接口的性能不是很高的。大家一般也不敢把频率太高的计算，利用COM接口传来传去，不信，你把++计算符做个COM调用，在自己的程序里面全部使用这个COM调用试试看，看程序的效率是不是蜗牛了。
不过，COM接口的思想不错，其实已经很类似服务器集群中的分布式原则了，即所有的计算，经过业务归类后，都可以视为一个远程调用，利用一套接口标准，大家协同计算，目前我们做服务器集群，有句口号：“服务无处不在”，其实说的就是这个道理，一个计算种类，完全可以用COM接口，或者其他什么手段，做到远端的服务器上去计算，这对于服务器集群的动态负载均衡和分布式优化非常有帮助。
嗯，不过服务器目前用Linux比较多，COM的方式，能支持的服务器就不多了，因此，COM虽然实现了分布式计算接口，但在这个领域，反而变成了弱势群体，不招人待见。因此，实际使用的时候，大家有COM的思路，但又都回避COM。
没办法啊，毕竟Linux是免费的，微软当年用免费IE干掉了Netscape，现在轮到他尝苦果了，Linux虽然用户使用还不友好，但是凭着免费，已经成为服务器市场事实上的老大。老外很诚信，不用盗版的，不过，他们也喜欢免费。
而反正，分布式计算，又不止COM一个方法。跑个apache，做一段php，其实已经可以分布式计算了，太容易了。
比如：我们在某个服务器192.168.1.20上做一个加法计算服务addcall.php，客户端发出一条URL，
http://192.168.1.20/addcall.php?first_num=1,second_num=2
这个时侯，服务器已经获得足够的信息，可以做1+2=3了，再利用html协议回传结果就好了。
看见没，其实跨平台、跨语言协同开发，就是这么简单。
1+2=3确实没必要做成服务，太浪费了，不过，如果是在100w用户中查询一个什么条目，形成一个list回传，你说这个功能，在一个客户机上运行快，还是一个8CPU、8G内存的服务器上运行快？这个时候的协同计算，是不是很有意义？
把高loading的计算，放到高性能服务器集群上实现，客户端担任信息的输入和输出者，专心做UI，大家看看，这是不是云计算？
嗯，部分计算呢，和用户的UI比较密集，还是放到客户端计算比较好，只有关于核心数据的一部分计算，放到服务器集群，大家再看看，这是不是微软的“云 - 端”计算模型？
呵呵，明白了吧，其实很多深奥的概念，大的吓死人的概念，分拆下来，其实就这么简单。思路都是通的啦。
完蛋了，说着说着又跑题了，呼呼，好累！
本文转自 tonyxiaohome 51CTO博客，原文链接：http://blog.51cto.com/tonyxiaohome/198748 ，如需转载请自行联系原作者
