入门学习C++的一点讨论

  1. 云栖社区>
  2. 博客>
  3. 正文

入门学习C++的一点讨论

技术小牛人 2017-11-22 14:39:00 浏览769
展开阅读全文

坛子里在讨论入门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 ,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
技术小牛人
+ 关注