(转)理性看待VC/MFC的没落

1. VC实际上没有想象中那么流行,有被夸大的成分。国外我不了解,只谈国内。
  曾经连续若干年,无论是学校图书馆,还是新华书店,还是XX培训班,VC绝对是主力。
  很多大学在开设C/C++课程时,要么还停留在TurboC时代,要么就是一律VC++,鲜有
  其它开发环境。图书馆和书店,铺天盖地都是VC++,都是24小时精通,都是速成,都是
  深入浅出,都是内幕云云。几乎看不到其它开发工具的影子。这给我们一种错误的讯息,
  VC很强大,整个社会都在用VC。当我第一次看到Linux的时候,甚至有些恐惧,竟然还有
  这么不一样的windows。当我头一回用GCC和Vim的时候,惊慌失措。我想,很多人应该跟
  我境遇差不多,身边充满VC的影子,多到让人窒息。其实,脚本语言也挺流行的,只不过
  大环境让我们直到工作后才体会得到。

2. VC真的在没落。
  桌面软件的开发,曾经是VC独步天下,C#刚出来的时候,被不少人当作笑柄,要装一个巨大
  无比.net才能使用。直到现在,使用C#开发桌面软件仍然是少数,至少我电脑里只有一个索
  爱手机的管理软件。这种情况将要得到改写,因为Vista开始,.net已经默认集成到操作系统
  中了,就跟以前的MFCxx.dll和MSVCRT.dll一样。用过C#的人都知道,C#很方便,无论是对OO
  思想的支持程度,还是做GUI的RAD,都非常方便。再看VC,MFC渐渐淡去,这么多年也几乎没
  多少进步,微软对之支持力度也是远远不如.net, WTL是好东西,可是没有官方支持。即使是
  VC.net,也比不上C#,毕竟C#是为了.net而生的。

3. VC在很多方面开发效率不高。
  并不是说VC在退步,而是他进步缓慢。在很多领域,取代VC的工具渐渐崭露头角,Python的快速
  开发能力相当惊人,Java也有非常丰富的库支持,本来用VC做的一些小项目,拿他们来做,节省
  了大量的开发时间。微软的VC类库,倒是很多年没大动静了。特别是涉及到互联网功能的地方,
  VC被很多工具超越。

其实,与其说VC/MFC在没落,倒不如说是微软对产品的定位更加正确和清晰了。
在Windows驱动开发领域,在性能非常重要的地方,在游戏开发上,VC还是会继续发挥作用的。
只是,他不再被当作全能选手培养了,他有自己专注的地方。

尽管如此,我估计,VC在国内教育界还是会火热下去,中国国情不同嘛
DOS, QBasic, TurboC等等 哪一个不是在国外衰退后,还狠狠到中国来流行了几年

现在很多没有历史遗留问题的项目,已经开始用C#,Java,QT,Python,Ruby,Php之类了
当然,桌面个人软件,VC估计还是要继续一段时间,毕竟Windows7不是那么快就能取代XP的

这些年来,没有那么快被淘汰的,却是被人诟病的所谓大学里的没有用的基础理论

就我个人经历而言,算法和设计始终贯穿我所有的项目,它们是不可替代的东西
即使有替代,也只可能是A算法代替B算法,或者A设计代替B设计

最近看招聘信息,VC的踪影已经越来越少

MS对它的支持力度的确远不如C#。举个例子:发送需要服务器认证邮件在VC中是需要有相当的经验的程序员才能搞定的事情,我前不久就花了牛劲搞定了MFC发送服务器认证邮件的程序,可是我回头在C#中一看,嘿,有现成的控件可用,不仅简单,开发出来还更管用。所以我确实觉得MS在抛弃VC。既然C#中都有了,干吗不做一个VC的呢?VC程序员受歧视啊,惨遭抛弃啊,所以我确实感到自己深受MS所害,如今已过不惑之年,也只能在WIN下面玩玩了,想转LInux是不大可能了,哎!!!

我个人有这样一种感觉
从汇编语言充当主流开发工具
到C语言被人接受并广泛采用
到C++的广泛使用
到Java的大面积应用
到脚本语言的大行其道

软件开发中的一些思路正在转变
开发效率在大部分时候都显得比运行效率更重要
更低硬件消耗带来的利益 很容易被更高的人力成本消除

曾经 我们非常强调性能
甚至为了优化流水线和分支预测写出晦涩的代码
现在大概只能在OS源码级别,才能见到那些东西
做普通应用软件的时候,你会努力提高cpu cache命中率吗?

然而 现在为了提高可读性和降低维护成本
甚至可能会使用增加硬件消耗的方式完成任务
好几种重构方式会降低运行性能

如上面有人所讲,“社会分工”正在越来越清晰,软件业的生产工具越来越牛掰
合适的工具做合适的事情,正确的方法解决正确的问题,这是最理想的

顺便调查一下
现在还有多少人 为了减少软件体积或是增加性能
选择 纯粹汇编 + INVOKE Win32API?

工的确细了,但是每个分工单元,开发的准确性和精度却越来越粗糙,C#和Java开发出的应用系统,由于在开发理念上的一些偏差,仅仅算是可以运行的程序,并且堂而皇之的说是一切转向服务,其实意思就是,程序能用就行,大不了我给你后面改,维护,提供服务。

当然C#和java从技术角度来说,是可以开发出商用级别的系统,在细微的处理上也能做到很高层次的控制。但是需要的经验,人力,以及开发成本,各种测试,算下来,代价不低于以前用C/C++开发的系统。

C和C++在开发中的精准控制,还是很有效地,商用系统往往需要更稳定,能持续自动化的运营。而不是说程序能运行就完事了。

分工是软件工程和管理的说法,在技术开发的细微领域中,过多的加入人的管理工程色彩,就是去了软件带来的生产效率的提高。

相对来说,在异构复杂的运营系统中,C/C++开发团队往往有着比较特殊的地位,独立,封闭,甚至不可轻易的变动。相对于其他开源,C#,java团队,C++的开发流程不是用来为了迎合所谓的工程管理。其核心还是稳定,性能。精准控制。大多数商用系统都不是单一的开发语言平台。不仅有通用语言,甚至还包括了自开发的design平台,runtime平台,甚至还会有ide。从来不会为了语言而实现需求,而是为了实现需求整合而使用语言。

本末不可倒置

对楼主的言论不得不提出质疑!根本不是没落的问题,而且时代进步造成的必然结果。

就VC而言,表面上看,微软不再重视。这只是一种假象。貌似看起来现在C#已经各种各样的其他脚本语言异常火爆,可反过来看,这些高级东西(包含各种WEb应用)不都是用C/c++来实现的吗?(重申一下,VC是一个开发工具IED,C/C++是开发语言)。没有这些底层的东西,何以能现在简单的实现和应用。

只能说随着时代的进步。社会分工越来越分化,原先的程序员既要兼顾底层基础,又要兼顾高层应用。现在发展的趋势是,越来越多的集成环境被开发出来(这些都是c/C++)的成果。可以很简单的实现上层应用,进而出现了现在的分工。很多实际应用不再需要C/C++了。

但是这些复杂的集成环境不要人来开发吗?同样需要不停的更新,与时俱进。要得依然是成熟老练的C/C++程序员。

是国情限制的,因为中国90%的都是小公司,打工式经济,仅万分之三的企业拥有自主知识产权,小公司做事自然求快,快速出来才能快速换到钱,rad工具,C#等自然流行起来了。大的公司,vc永远都不会过时
一个开发工具,没落了又如何?只要我的c++不没落就行了。
方向不一样吧!
各有利弊的。
我用VB一年,DELPHI半年,C#.Net三年(做Windows开发)VC也只是熟悉而已。
觉得哦!
C#.Net跟VB差不多,简单容易上手,但是比VB功能强大的多。
C#.Net跟DELPHI比,还是有些类似的地方,可能就是两个工具都只能开发操作系统上的开发吧!
C#.Net跟VC比吧!对于Windows开发我觉得各有利弊而已。只是VC在移植方面做的比较好吧!
再有就是怎么说呢
只能说哪个工具提供的类的多少而已!
你要是厉害用NET也可以呀
你只能用基础类型
别的任何类都不用
还不是跟C语言一样!
就拿嵌入式开发来说吧!
他也只适合于单片机而已,一个芯片就那么大,你不可能定义个类型比较大的吧!
我自己的理解!
开发工具的不同是方向的不同
可是语言都是一样的

整理一下前面几个回帖的观点

1.  C/C++可以提供更精准的控制.
控制什么呢? 是直接操作硬件还是调用系统API?
我觉得软件到现在这种程度,大部分精力应该是花在处理业务逻辑上,而不是跟业务没有关系的技术细节。
一个写浏览器的程序员,犯不着自己实现一遍TCP/IP,更不用关心网卡电平信号是如何变化着的。
什么是精准呢?  用其它语言开发出来的东西,不方便实现精准吗?
我觉得没有一个软件是允许不精准存在的,如果程序不能精确的照意图运行,它就是错误

2. C/C++更稳定更健壮.
C/C++的编译器比其它语言的编译器更加稳定?  还是说同样逻辑的代码,编译出来的二进制更稳定?
虽说编译器和CRT对稳定性健壮性有一定影响,但更多的时候,依赖的不是编译器也不是CRT,而是人和机器
人可以写出更健壮的代码,机器可以存在一定冗余,非常重要的关键性应用,没几个不带灾备的吧?

3. 其它编译器都是C/C++写的,所以C/C++不会没落。
实际上并不是所有编译器都是C/C++写的,例子很多,就不赘述了
任何主流语言都可以写编译器,只要支持字符串处理就可以
以前编译器都是汇编语言写的,以后C/C++也会被新事物取代
编译器和操作系统,这是没有其它语言可以太多竞争的地方,它也是C/C++所擅长的
但是这种基础设施在整个软件环境中,能占多大比例呢?

4. VC/MFC更加底层,可以随心所欲。
是的,确实相对底层一些,控制力也更大一些,但是软件开发的重心已经不是底层了
而是跟底层最好没有关系,完全针对业务相关的东西进行开发
即使拿做界面来说,能调用系统API的语言环境并不只有VC,delphi也可以调用API
Freepascal也能调用API,MFC终究还是要调用API的,都是调用API,哪里来的更底层
的控制呢?

5. VC/MFC更加灵活.
如果这个灵活是指封装的弹性,那么很遗憾,MFC虽然流行,它的封装却不是很突出,至少在2009这个时间
GTK,WxWidgets,QT,甚至几年前的OWL,VCL,或者说现在比较强悍的WTL,都不属于MFC吧


顺便指出一个概念性问题
我提出的观点是VC/MFC的没落,而不是C/C++的没落,两者不能混为一谈
如果微软给VC整合了跟QT一样丰富和强大的库,我也就不会说它没落了

从我自身角度看,学校和社会很多年来,都在孜孜不倦的向我灌输VC天下无敌的思想
以至于当我接触到Linux,GTK,QT之类东西之后,我居然有一种莫名的恐惧感
一直坚信的神物,不得不重新审视,请它走下神坛来

ps:  
我刚工作时,一切都想用C/C++来做,后来没能如愿,全部都是php+python+java+bash
即使偶尔用到C/C++,也只是封装一些很底层的东西,并不用其实现业务逻辑
VC则是完全没动用过,先后两家公司,我们的东西都是Linux/UNIX上的,开发环境也不在本地
需要ssh登陆上去做开发,只能Vim和Emacs二选一,不过Vim编辑起来是要比VC舒服些

业余时间写点东西,我还是会使用C/C++,那是我最熟悉也最喜欢的工具

内存泄漏问题在没有GC的环境里更严峻,这本身也说明了工具的某些不足
负载均衡,多机热备,快速切换等等,跟具体的语言没什么关系
与内核相关的时候,C++的特性被完全剥离,C语言就足够了
正因为实时性和可靠性的要求  底层的实现要求非常稳定和健壮
使用C++来做这个事情 会带来相当的复杂性和不必要的开销
所以流行的操作系统没有用C++实现的 全是C+汇编

你说的那些底层的东西,也是在system call以上,线程池,内存池等等都是封装了一组系统调用
为了项目修改通用的OS内核,使用自己的调度器,使用自己的资源管理方式,往往是得不偿失的
从呼叫系统调用看 C++跟其它语言比 除了声明和参数类型外 并没有多少方便之处
资源管理这类相对底层的东西,除非是在做驱动或者做OS内核,业务为核心的系统中,比重应该是很小的
即使用到了,也是C比较多,threadpool, libevent,memory pool等等,都是C语言封装的
几乎所有的libxxx,提供的都是C接口

况且,那些都是C/C++,跟VC/MFC扯不上什么关系
为什么VC要跟MFC一起说呢,因为这两个东西结合最紧密
抛开VC谈MFC是空谈  抛开MFC谈VC 倒不如说cl编译器或者C++

随着Linux和嵌入式平台的发展
很多时候,我们都要求有跨平台的能力
这种需求之下,VC/MFC直接被无视了
连QQ都出Linux客户端了,迅雷Linux版也快了

题目倒不如改成没落的MFC,这样就更加准确,避免误解了
我也说说mfc吧,当然mfc不等于vc,不过你都说了,书店,培训讲vc的基本是mfc
mfc的特点是和windows共享了部分类库,并跟os同步,提供了os的风格。对于mfc而言,继承封装,消息机制都还是不错的,不需要用户特别管理,只能说mfc包装的这一套现在的确是不流行了
还有mfc使用了文档-视图的结构,作为ms的ide,内嵌mfc,可以缩短用户学习的周期,对简单的应用不需要
构造基本代码。容易上手,这也是当初流行的原因。
说mfc存在问题,是肯定的。类库复杂,程序结构不太清晰,深入开发困难大。
这其实是降低入门的一个负作用。但是下功夫吃头mfc,改用其他平台基本不存在什么难度。所以如果是短期上手的话VC肯定是不行的,不过如果深入学习写代码,尤其和windows相关的,vc/mfc肯定不会没落(个人观点)
另外就是算法和数据结构和开发语言和框架没有任何关系,再有就是现在高校里据我所知没有VC/mfc相关的课程了,基本上都是有门软件工程之类的课程,作个类似于管理系统,大部分人用的确实是java
哎.现在主要是web流行.我在开发win32应用程序的时候.也想用c#.的确是快.但是.....它的源码问题却让人头痛.让用混淆器吗?我试过.用了之后总有些莫名的问题.用delphi?哎.语法严重不适应..用c++ builder?中文资料真是极少极少.外文资料都很少.c++程序员根本不买帐.除了vc还真找不到其它方式.可能是因为它封装的薄的原因吧.想定制某个东西很方便.很快知道咋做.我在Delphi下.半天找不着头.因为全封装了.

PS:我在写共享软件.但真的找不出比vc更好的.如果D语言有个强大的ide.我可能会学学它并用之.(D非delphi)

谁都想牵着别人的鼻子走,作为语言/开发工具的提供者,当然希望程序员都永远不要脱离自己的开发平台,对于商业公司来说,这些做法都是相同的。

程序员是一种“倒”金字塔结构,从底向上的人数成数量级增加,但每一层都不可或缺。最上层的人数可能占据了80%甚至更多,但这能说明什么呢?说明下面的层次可以去掉?用这个统计数据就能证明VC/MFC会没落?所有程序员都有依赖的基础,但每层的基础是不同的,你敢说.NET库代码是直接用机器指令编写的吗?

使用.NET以及所有当前最流行最时尚的RAD工具的程序员无疑处于倒金字塔的最上层。我不怀疑这些人的比例越来越高,也相信VC的比例越来越低,但我认为这不是VC的没落,恰恰相反,这是VC程序员的机遇。当越来越多的.NETer、JAVAer为了3、5千月薪争得头破血流的时候,VCer可以坐地起价,1万、1.5万、2万?越往后一定越高。为什么?就因为VC的比例越来越低,VC的门槛越来越高。

其实从我的私心来讲,我根本不希望微软像全力支持.NET一样来对待VC,不希望开发一大堆的应用库供VC使用(注意区别一个概念:VC的MFC/ATL/WTL是开发框架库,.NET的库是应用库,两者有本质区别),给VC留一点神秘感、留一点难度、留一点门槛不好吗?至少让程序员还有点思考的空间,不会脑袋生锈。我还蛮“喜欢”.NET的,因为我总喜欢把.NET的某些应用功能用VC来实现,有时也会因为VC数行代码实现的功能被.NET封装成几十个对象来完成而逗得心里直乐:原来微软是这样折腾.NET程序员的……

从技术角度来说,RAD类型的开发语言或工具通常只能使用于应用场合,虽然大家都声称自己的语言有能力做任何事,但能做归能做,是否合适做才是最重要的。Google的应用都是基于WEB和脚本语言的,它力推的云计算也一样,但打死我也不相信它的基础搜索引擎服务也是用这些工具开发的,即使它有成千上万台服务器、即使它的每台服务器都配置了最高档的硬件、最大的硬盘、最多的内存,我相信它一定还在继续为节省内存资源、提高搜索性能而煞费苦心。

再回头看,为什么会有浏览器大战?为什么浏览器厂家为了一个性能更高的脚本引擎的推广不遗余力?因为这是所谓网络操作系统、云计算必不可少的工具,他们希望99%的程序员利用1%的人开发的平台来开发应用,Google的应用实验室不例外,微软的.NET更不例外(其实VC也一样,但因为C++本身的独立特性,VC没有那么强的绑架能力,离开VC还能搞GCC)。

针对网上铺天盖地的语言工具排名,说是骗局也好,谎言也罢,还是最开始说的,他们的目的只有一个,希望由自己来掌握住程序员。在这点上,微软的.NET无疑是最心狠手辣的,沾上的程序员一个都跑不掉。

搜索引擎,操作系统,浏览器等等,是需要高性能,需要不断优化
然而,google的搜索引擎运行在Linux主机上,跟VC扯不上什么关系
操作系统是C和汇编 ,UNIX类系统则是gcc派的,跟VC没任何关系,跟MFC更加没关系

打个比方,如果一个地产商曾经垄断了全国楼市,而现在只在一两个小城市里有能力垄断,算不算是没落呢?

VC的门槛高吗?  
徘徊在语言和工具层次的人群来说,门槛是高了些,那些人用什么工具都一样,不容易得到高薪水的职位
3年工作经验的人,做php/python开发的,也有很多年薪>15万的,VC也有很多年薪连5万都拿不到的
真正的区别应该是内在,即那些与语言和工具无关的部分,语言和工具的掌握,比起内在要简单多了
程序员金字塔的结构中,排在什么位置,并不是看用的什么工具,而是算法,设计,系统原理等等基本功

举一个VC比.net简单的反例并不能证明VC就更方便
我随便举个例子,将一个整数的字节序改变一下
汇编程序员只要 bswap 一条指令就完成了
高级语言恐怕没那么容易,甚至有些人不知道该怎么做
platform independent是软件开发的趋势之一
从机器指令到汇编,到C/C++,到Java,到脚本,每一次需要了解的底层都更少
越接近人类活动,就越跟底层无关,工具自身的发展,是接近人类,而不是让人类去适应

C++程序员并不比Delphi程序员优越,也不会比VB程序员优越,也不会比html程序员优越
越来越多的公司认识到了这一点,所以现在招聘的时候,好点的公司已经不要求掌握XX语言了
只要思维好,只要基本功好,掌握任何一种计算机语言都是能接受的,甚至跟他们业务不怎么相关的语言
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页