https://jackxiang.com/index.php zh-cn https://jackxiang.com/post/2044/ jack <xdy108@126.com> Sat, 10 Oct 2009 13:20:50 +0000 https://jackxiang.com/post/2044/   曾经连续若干年，无论是学校图书馆，还是新华书店，还是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语言了
只要思维好，只要基本功好，掌握任何一种计算机语言都是能接受的，甚至跟他们业务不怎么相关的语言 ]]> https://jackxiang.com/post/2044/#blogcomment63958 hi <user@domain.com> Mon, 29 Sep 2014 15:17:24 +0000 https://jackxiang.com/post/2044/#blogcomment63958 https://jackxiang.com/post/2044/#blogcomment63968 caca <ss@163.com> Wed, 29 Jul 2015 13:21:16 +0000 https://jackxiang.com/post/2044/#blogcomment63968