无意中看到一个很强的贴,简直一群机关枪阿
来源:互联网 发布:淘宝网商贷提前还款 编辑:程序博客网 时间:2024/05/16 01:31
- VcPhi
- 等 级:
算起来,我用Visual C++也有将近5年的历史了。在这期间,我也曾涉猎过Visual Basic和Delphi,但都是浅尝而止;Visual C++始终是我的主业。可是努力的成果如何呢?我用Delphi作出了十多个有规模的软件,用VB--虽然我用在VB上的时间只有短短的两三个月--也有两个像样的项目;然而,在我付出了最大热情和最多努力的Visual C++上面,却只作出了三个自己看得上眼的软件。
固然,在用Visual C++的时候,MFC帮了我不少的忙。但是,在写下这个题目之时,我就已经打定主意:在这篇文章中,只对MFC提出批评,不说MFC的好话。Visual C++的拥护者且慢发难,听我道出其中原因。我注意到,象候捷先生这样对MFC极其热爱的著者,在其大著《深入浅出MFC》中对MFC的评价也是尽量的做到客观和公允;而大师Charles Petzold和Jeff Prosise,在他们的作品中也只是给予MFC以谨慎的赞美。Charles Petzold还很客气的指出了MFC的局限。然而另外一些编程书籍的作者,特别是某些国内的作者,似乎毫不吝惜把最华丽的语言和最夸张的赞美赋予MFC,从书架上任意翻开一本介绍Visual C++的书籍,看看它的前言和序章,往往充斥着让人目眩的溢美之辞。多少初学者被这些充满暗示和诱导的辞令吸引,以为MFC是完全可视化的,象VB一样容易掌握的东西,当他们深入以后,会不会有上当的感觉呢?我痛恨一切不负责任的夸大和炫耀,特别是只为了增加书籍销量而不惜昧着良心说话的作者,而我的感觉是现在这样的作者和书籍似乎已经泛滥了。本着矫枉必须过正的指导思想,我的目的很明确,就是要批评MFC。对Visual C++和MFC非常熟悉的读者,我无虑您对本文提出批评和指责,因为您对MFC已经有了自己的观点,不会为我所误导;对Visual C++的入门者,我希望您在听够了对Visual C++和MFC的赞美之后,来听听另一种声音,即使它并不完全正确(甚或是充满谬误),至少能让您带着自己的思想来看待您将要学习的东西。
对MFC的批判之一:不支持属性,MFC凭什么同其他语言抗衡?
窃以为在编程语言中引入“Property”的概念是在面向对象的编程思想后最为重大的革新之一。其实,目前市场上绝大部分编程语言,包括VB,Delphi,C++Builder和PowerBuilder等等都支持Property。程序员只要简单的修改对象的属性,就能够完成相当部分的工作,不仅是减少了无谓的劳动,更重要的是减少了出错的机会,并且使得生成更复杂的界面和完成更复杂的工作成为相对容易的工作。我想绝大部分人会同意,如果去掉了Property这个东西,那么象VB和Delphi这样好的RAD,包括Microsoft一直倡导的ActiveX,都会失去了绝大部分的魅力。这个道理,Microsoft应该是在推出Visual Basic 1.0的时候就认识到了。可是自从Visual C++诞生到现在,它似乎丝毫没有使用Property的意思,虽然Visual C++这个名字在很大程序上沾了它的长兄Visual Basic的光,不过它并没有从VB那里学到如何让编程更简单和更轻松的秘诀。
有人可能会说,data member of class不是property吗?不是的,如果你用过C++Builder的话你一定能明白这种分别。MFC从来就不支持Property,而且今后看来也不会了,这意味着用MFC,你还是得干苦力活。(ActiveX?不错,ActiveX支持Property,而且MFC支持ActiveX开发,不过这并不是三段论发挥作用的地方。)
对MFC的批判之二:单调的处理方式使本来应该简单的工作变得复杂
应该没有人反对这样的观点:用Visual C++开发界面,特别是不符合Microsoft所谓“标准”的程序,比VB,Delphi或是C++Builder都要慢得多。(附带说一句,我不知道Microsoft制定Windows Logo标准,并且要求程序员遵守的依据是什么;我自己的程序99%以上都不符合这个标准。)可这是为什么呢?是C++语言在这方面的天生不足?肯定不是。
在我看来,罪魁祸首是MFC中的CDocTemplate,这个类规定了一种非常死板和机械的机制,即一个Document,一个View和一个FrameWnd绑定在一起。遗憾的是,实际情况往往复杂的多。对界面稍微稍微要求高一点的程序大多要求一个Document有多个View,甚至在某些程序中,希望在同一个View中显示多个Document的内容:比如,将两个公司的业绩放在一起作比较。对View和FrameWnd的关系也有类似的情况。然而,DocTemplate的机制使得这样并不高的要求变的相当困难。想实现你的要求吗?可以。你要添加新的View类。你要从默认的IDR_MAINFRAME复制资源到新的类中。你要用AddDocTemplate添加自定义模板。你要用GetFirstDocTemplatePosition和GetNextDocTemplate检索模板列表。你要用GetDocString察看每个模板是否符合你的要求。你要重载CFrameWnd::OnCreateClient以派生新的视图。你要用CView::SetDlgCtrlID和CFrameWnd::SetActiveView以及CFrameWnd::RecalcLayout来在各个视图中切换。你要用未公开的CDocManager管理文档模板。你要...还要吗?反正我是怕了。
对MFC的批判之三:固步自封,不思进取
MFC可以作为固步自封的活教材。别忘了,MFC是和Borland OWL同一时代的产物(还有多少人记得OWL呢?)当然,这不是MFC的错误。不过,如果以个类库的体系自从2.0版本以来就没有丝毫改变,是不是意味着这个类库已经臻于完美了呢?不,即使Microsoft也不敢这么狂妄。但事实是,MFC的体系从MFC2.0以来就没有变动过。每个版本的更新,不过是增加了一些新类,某些类的接口稍作修改,仅此而已。不,不要把ATL作为MFC的改进;ATL从来就不依赖于MFC。
谁都知道在这几年中C++语言有了多么大的改进。包括RTTI,Dynamic Creation,Exception,Standard Template Library等等都成为新的C++标准的一部分。不过,Microsoft好像并不喜欢这些新东西,它的做法是另起炉灶;于是在同以套Visual C++中就出现了两套互不兼容的实现。平心而论,在新的C++标准出台前,Microsoft自己实现这些机制实在是一个相当了不起的创举;但是历史总是在发展的,MFC为什么不从善如流,尽量利用语言中已经实现的功能,而非要固执的用自己的一套老办法?事实上,MFC几乎没有用到新的C++方案中任何有益的元素--尽管这些方案已经对MFC库中很多问题提出了相当完美而且精练的解决方法。
对MFC的批判之四:天然的倾向性
不知道您对AppWizard生成的默认项目有什么感觉。反正我的感觉是:这种工程就是用来开发象Word,Excel这样的程序的。好像MFC天然的就倾向于这样一种程序。但事实上,这种程序少之又少。
在Microsoft看来,好像每个程序都应该有一个File菜单,而且这个菜单下面一定应该有New,Open,Save,Exit这些选项。在我的实际经验来说,我只搞过一个程序符合这样的要求。有多少人真的要搞一个自己的字处理程序或是电子表格呢?对于很多常见的、基于数据库的程序,你需要New,Open和Save吗?如果是基于网络的程序呢?特别是在多媒体程序和游戏程序中,MFC生成的框架与其说是帮助,不如说是累赘。
这倒是符合Microsoft的一贯风格:你要的只是特定的功能,它却一并塞给你一大串不相干的东西,并且在很多时候,这些不相干的东西反而成为麻烦制造者。于是,我不得不在新生成一个项目后,不辞劳苦的去掉AppWizard“慷慨”的赠送品,包括大量无用的菜单和工具条按钮,然后才能开始实际的工作。说实在的,AppWizard在为我减少工作量的同时,也增加了我不少劳动量。
MFC定义了一个Document-View框架,并且把Document定义的相当宽泛,几乎可以代表任何数据。但是在实现上,Document是相当狭窄的;比如Document定义的Serialize固定的与一个CArchive对象联系在一起,而CArchive又固定的与一个CFile联系在一起,这样实际上就限定Document处理的对象只能是磁盘文件。况且,在一个Serialize中处理所有数据的序列化也是一种相当机械而死板的机制:它只能处理小量而且是一次处理完毕的数据,而实际上,程序往往要处理大块的数据,并且不可能一次完成。在这种情况下,CDocument的处理机制反而是个障碍。此外,在很多类型的程序中,CDocument扮演的是一个很尴尬的角色:比如在绝大部分数据库程序中,CDocument完全是个鸡肋,实际的数据处理只能靠CRecordset来完成;再比如说,在最典型的Doc-View程序--就是记事本程序--中,CDocument根本是个无能的东西,因为它存取数据反而要求助于CEditView::SerializeRaw。
Doc-View框架有可能突破这些限制吗?完全可能。不过,你要有心理准备,如果你要这么作,你就必须求助于一大堆的未公开函数和类型,这些东西完全没有文档,依赖于你对MFC“底下的东西”究竟有多么熟悉,以及你是否愿意钻研MFC的源代码--在绝大多数情况下这不是一件愉快的工作。如果你使用这些未公开的东西出了问题,或者你不知道如何使用,对不起,Microsoft不会给你任何支持--谁教你不按照Microsoft的逻辑工作来着!
对MFC的批判之五:什么是封装?
好像这不成为一个问题。但是对MFC而言,封装的定义是不成立的。这句话的意思是说,如果你不想生产玩具的话,如果你需要调试程序的话,如果你的代码需要有比AppWizard更多的东西,那么,MFC对你来说就不是封装的。如果你的程序运行出了错,对不起,问题不在你的代码里面,而在MFC库的某个文件中,Visual C++会为你打开这个文件,至于“为什么会出错?”“这个函数究竟是用来干什么的?”MFC不会给你答案,你自求多福吧。如果你除了MSDN中的公开文档以外,对MFC的源代码从不关心,那么恭喜你,你是个快乐的程序员,但是你永远不能生产出真正有用的程序。
候捷先生在其著作《深入浅出MFC》中也曾提到:或许有人会产生疑问,追寻“黑盒子底下的东西”,岂不有违面向对象编程的初衷?但是没有办法,不去熟悉MFC的源代码,永远只能生产玩具。候先生说的很委婉,尽量不批评MFC。但是,我可以这样说:使用VB,Delphi,C++Builder,Java这些语言的程序员几乎从来不去关心类库的源代码,可是这些语言并不是用来生产玩具的!
20
- ouyh12345
- 等 级:
在frame上,排多个dialog。
- takbj
- 等 级:
学用MFC时间不长,你说的话也正是我对MFC不理解的地方。本以后这些问题会随着对MFC的熟悉而解决,但现在看来……
- delphiguy2
- 等 级:
- manbaum
- 等 级:
这个人的观点偏颇的够可以的。我得驳驳了!
对MFC的批判之一:不支持属性,MFC凭什么同其他语言抗衡?
---------
MFC是语言么?作者连什么是语言,什么是framework都没搞清啊???
对MFC的批判之二:单调的处理方式使本来应该简单的工作变得复杂
---------
这里面是说doc-view模式不好的。mfc并没有强迫你必须使用这个模式,只不过是说,如果你需要用这个模式,那我给你提供实现这个模式的一套简便方式而已。你完全可以另写你自己的模式,MFC并没有限制。
对MFC的批判之三:固步自封,不思进取
----------
提到owl,现在是没人用了。最早我是用bc的,直到vc4以后,才开始用vc。固然,但从面向对象的角度去评判,mfc的封装是比owl差。但是在mfc之前的人,都是用sdk api直接写程序的,而且是用c而不是c++。要适应c++,又要适应新的类库,是需要时间的。mfc对api简单的封装,让广大的程序员迅速上手,有什么不好的???至于改进,就很困难了。由于m$要保持与老版本的兼容,不得已啊。看看从windows3.0到windows95,为了兼容走过的路,很艰难啊。市场规则不允许你说换,立马就换。
对MFC的批判之四:天然的倾向性
----------
同二,还是在说doc-view的弱点,那我的回答也同二一样。
对MFC的批判之五:什么是封装?
----------
封装不封装和给不给源码有关系么?VB是封装么?VB是解释性语言!虽然貌似“编译”出了个exe,其实那是“伪编译”!作者自己的逻辑首先就是错误的。如果给了源码了就不叫封装了,那如此多的开源项目都是非面向对象的开发了???更况且关于黑盒白盒,是萝卜青菜各有所爱的事。
吃饭先!回头继续。
- lddLinan
- 等 级:
MFC不是语言
“单调的处理方式使本来应该简单的工作变得复杂”
没有什么库是全能的
“固步自封,不思进取”
每个Framework都有其设计需求环境的局限性,你要看清楚哪些新的特性需要打破原来的framework
"天然的倾向性 "
人家本来就叫M-FC,很清楚的,你这是废话
“什么是封装?”
如果你认为封装是文件级别的,那么所有开源的库,stl的库等等,你都应该好好批判一下。
“多少初学者被这些充满暗示和诱导的辞令吸引,以为MFC是完全可视化的,象VB一样容易掌握的东西,当他们深入以后,会不会有上当的感觉呢?”
能够理解MFC的framework,才能算作深入MFC
- manbaum
- 等 级:
-------
说的很对。现在有了更多更好的可选择的东东了,回过头来说mfc不好了。呵呵。如果10年前你也有能力这么说,那才是英雄。
- WuOu
- 等 级:
- gogovista
- 等 级:
时代在进步
- vcPlayer
- 等 级:
2、尊重自己的过去才能尊重他人。不要以为掌握了什么自认为是高幻莫测的东东,就大呼小叫的说自己过去被什么东东如何如何给耽误了!否则我就是***第二;疏不知你刚“掌握”的东西就是从它的基础上发展而来的;
3、你是否能用 可 咨 使 用 的任何工具,都能达到项目的最佳要求,这才是你应该去批判的!把自己的前途和视野都束缚在某一种工具上,不是工具的成功,而是使用它的人的悲哀;
……………………………………………………
最后说一点:建议程序员都好好学学辩证唯物主义(不错,俺就是70年代的人。不要说我古板,如果你能透过浮华的表象看到事物的本质,那恭喜你!你天然就是比动辄搞什么“批判”的人高几个层次)。时常都能保持自己独立的思考,才不会成为别人的跟班。
- peng_shihai
- 等 级:
我也想放弃MFC,但是我的C++基础还错。我还想继续在C++方面发展,不知道我该学什么,请各位
高手指教!指教!!!拜托了!!!!
- OMOKIMI
- 等 级:
- wltg2001
- 等 级:
- lzg0001
- 等 级:
- jimoguilai
- 等 级:
好好学,好好学,慢慢的你就会发现其实编程语言的思想都是相通的
- idancing
- 等 级:
我觉得时间证实一切,存在就是有道理的
- ribut9225
- 等 级:
学MFC是比学VCL难
- constname
- 等 级:
- liuxiuk
- 等 级:
想学的很猛
就不怎么容易了 //做什么事不都这样?
- BUbuWander
- 等 级:
- wawaku
- 等 级:
- wengch
- 等 级:
- developCpp
- 等 级:
但是想找一个替代的类库难阿
STL,Boost非常好, 但是界面还要靠MFC呀
不过现在好了
听说Unix/Linux的界面KDE的基础QT类库也被移植到Windows了
网上评价不错, 和VCL一样简单好用
还能跨平台, Windows/Unix/Linux/Mac等
还公开源代码
正在找数据学习中
- ftnkn
- 等 级:
- lekonpeng
- 等 级:
在Microsoft看来,好像每个程序都应该有一个File菜单,而且这个菜单下面一定应该有New,Open,Save,Exit这些选项。 我们公司做的tool基本上是这个架构,只是你没有用到而已。mfc虽差但是还没有你说的这么差,如果你用的不爽,你还可以改写它对不对
- alan001
- 等 级:
- sxcong
- 等 级:
世界上的c++程序员,用MFC的应该不到五分之一吧,你完全可以向其他五分之四的人学习,或者直接用G++好了,开源产品,不花钱的。你的MFC估计也是盗版的,反正又不好用,又是偷人家的东西,干嘛还要用呢
- deterly
- 等 级:
这就像一边用着windows一边在辱骂抱怨windows拙劣,怎么不想想,有人逼你用吗?
觉得不好不用就是了
vc不等于mfc!
- zaodt
- 等 级:
- sjcode
- 等 级:
我目前正在整理这七年来,所用到过的mfc代码.
前面,已经花了一段时间把常用的工具类封装好了.打算再花上一年时间,编写一套ui库.基于mfc的.
- fuchuan1227
- 等 级:
弄好了发小弟一份,么问题吧?呵呵!!
- wltg2001
- 等 级:
====================================
那你累不累呢?
- manbaum
- 等 级:
------------
估计他不累,现在正处于精力旺盛时期,呵呵,等过一个时期,他会回过头考虑复用他人代码的问题。
- hediant
- 等 级:
把MFC简单的看作开发工具是错误的,事实上用MFC实现的大型产品很少,但很多都源于MFC的设计思想,也正因为如此,关注底层的代码不仅不是多余的、不是非面向对象的,甚至可以说是必须的。
MFC最初的设计也是为了快速开发和作为验证编程思想的快速开发利器,现在虽然可以用第四代语言逐渐代替,但是由于受第4代语言在Visual IDE开发工具以及与C/C++语言之间集成等问题的限制,目前,用仍然MFC作为作为验证编程思想和制作原型的主流工具和框架。
其实,编写Windows程序,就其底层来说就像是对一个拥有大型函数库(windows API)的低级脚本的编写,MFC为我们提供了封装这些脚本的面向对象思想和多种设计模式,它在提供快速开发模式的同时又提醒程序员——你们无所不能,因为思想才是无所不能的!
- mxm324
- 等 级:
反过来呢?用MFC..对于设计模式我知道得很少..也很浅显..但是MFC却给了一种模式..觉得对于一个非牛人的程序员来说..开始接触MFC..并不是让你去骂他有多难.多不好用..更多的时候应该通过MFC的一个结构..去了解编程语言如C++自身的一些特性..和去了解在程序中运用设计模式的重要性..以前在学校的时候..我觉得设计模式就是狗P..现在才上班两个月..发现从MFC里面学到的东西挺多了..你可以去熟悉整个MFC框架..windows的机制..诚然:MFC缺陷很多..是个垃圾..但不可否认..这些垃圾是一些比你强十倍..或者100倍的人写出来的东西...他们对于语言的驾驭能力肯定比你我都强...
如果你学习MFC.只是单纯的去学习怎么调用api.怎么去玩酷炫的界面..那么..你还是停手的好..因为据我所知..其它语言或者sdk都提供了这样的内容..而且更会让你 "得心应手 "..但我最后只能告诉你..当你真正接到一个项目的时候..你有的只是无助..不知道怎么去开始..写出来的代码比外面垃圾堆里面的垃圾更难看..程序的结构如纸一样..候老大说过一句话:勿在浮沙筑高台...
也许有天..有了MFC的替代品...也许有天..有了新的语言..但是..不变的是我们的思考方式
- aceouter
- 等 级:
- misssir
- 等 级:
- superarhow
- 等 级:
- ringphone
- 等 级:
---------
MFC是C++类库,C++本身就不支持属性。
C++ Builder能支持属性那是编译器支持,C++ Builder所用的类库是VCL,PASCAL语言,本身就是个怪胎。
- paerxiushi
- 等 级:
对于一个SQL导入命令而言:
1.使用bcp指令就有50多个参数可供选择.
2.使用Bulk Insert语句,只有17个参数可供选择
3.而使用C#类库的SqlBulkCopy,只有个位数的属性可供选择.
所以说封装性越好的东西,灵活性就越差.不是说那门语言不好,而是那门语言做什么事不方便而已.这也就是为什么C#程序员还要使用API函数做程序的原因,因为他们知道net framework实在太傻瓜了.
- ypos
- 等 级:
- icesnowjank
- 等 级:
- zhangnanonnet
- 等 级:
- booming
- 等 级:
- simon031187
- 等 级:
- edgeperson
- 等 级:
不喜欢用向导.
PS:俺是新手,经历旺盛期````理解万岁`````
- ke2007lin
- 等 级:
继续关注
- drowdrow
- 等 级:
- xrenwu
- 等 级:
- sunmz_wjxy
- 等 级:
比起ATL和WTL,MFC显得代码太冗余
- nj_dobetter
- 等 级:
作者说的很在理。
- shenxiaohe
- 等 级:
- jinghao666666
- 等 级:
================================
对,吃不着葡萄说葡萄酸。
- stivenjia
- 等 级:
根据您的需求选择适合的构架。
- zhoujianhei
- 等 级:
- paer_1
- 等 级:
第一条,确定C++很多类只支持属性,但是它制作的ActiveX控件却支持属性,而且它可以作成COM+组件,可以被其他语言调用。它可以在CS,BS,网页上显示。
第二条,这正是MFC的优势所在,它的文档机制使得数据的操作和显示分开来处理,就如同数据库系统的前台界面和后台逻辑是一个样的。这里面体现了类的职责分工,设计一个正确的类是每个程序员应该修炼的东西。一个文档应用程序不但可以操作注册表,配置文件,文档模板,文档对象、前始界面和命令行,足以看得出其功能的强大。文档与视图之间的操作,体现了数据结构和设计模式应用。每个类里面的方法都是由设计者经过精心设计。而且没有一个方法显得冗余。
第三条,不要说MFC固步自封,你看C++语言这门东西从八十年代以来一直流行到现在,也有30年的历史,换成别的,早就淘汰了。这足以说明C++功能强大,还有你不是说MFC很长时间没更新,我告诉你,VC从VS7.0版本以来就加入很多类型的检测,弄得初学者挺难上手的。但是这么做,整个程序就更可靠了。像C++这门语言本身已经很稳定了,不需要大量的升级,而且过多的更改也未必是件好事。你看一下现在的.net 3.0,以现在的配置才勉强能够运行,一般的电脑根本拖不动。什么工具呀,根本用不到。更糟的是,微软居然用这个框架来做下一代操作系统Vista,这么肥的操作系统从它的诞生就意味着他的灭亡。所以微软索性推出精简版操作系统Windows7了。
第四条,我不敢否认,我只想说一句话,因为有了MFC的类库,你的大脑里才会这么多类型,你才会有这么多的编程想法。如果没有MFC,很多人是很难上手,你觉得不好用,那是因为你做懂了纯C东西。换成是新手的话,还巴不得用MFC呢。至少它让我知道C++可以做哪些事情。不要用以为学会了MFC,就彻头彻尾地否定他。
第五条,你以为封装就是不要看到源代码吗?大错特错,正是因为可以看到源代码,才能让你知道错在哪里。源代码可以让我们迅速地建立起软件的设计思想。程序之所以出错,是因为你的思想有错误,不是电脑有问题。你只需要按照它的要求设计即可。假设你开发了一个DLL,你想要在其它程序要使用类似功能,却不知道如何实现,难道你还要再写一遍代码吗?直接Copy源码得了。而且就拿现在的C#来说,实际开发还经常需要使用反编译工具得到DLL的源码,然后复制。由此可见开放源码的重要性。
- paer_1
- 等 级:
所以说每门语言的诞生并不是让你们说哪个好,哪个坏的问题,而是让你们知道如何取自己主改语言的优势去弥补别的语言短处。Dephi语言和JAVE语言是好用,但它们能开发测绘仪和网游吗?不行吧。为了充分发挥语言的优势,大型企业才会招收各个语言的程序员,让他们聚在一起,开发集成度,复用度最高的软件。而联系各门语言的桥梁就是COM,开发COM的主打语言就是C++。这样每种语言的开发员都有用武之地,企业才变得有竞争力。不要一味地认为别的语言使用方便就认为别的语言强大,你要是真的认为开发越方便越好的话,去用PB做程序好,三个月就可以搞定一个软件,你只要复制软件源码,并适当修改即可。但是像这样的程序员,没有开发系统软件的经验。
不是说哪门语言做的软件多,哪门语言就强大,关键在于看它是否能专注某一类软件的开发,能否长久站稳脚根。现在的开发工具很多,语言也层出不穷,但是最重要的是一个人的设计思想,那才是最根深蒂固的。无论开发环境有多么先进,它都代替不了你对软件的设计思想。开发环境的先进性,导致了各种业务软件爆炸性增长,至今为止,还没有什么新语言说是专门开发系统软件的。楼主呀,你应该感谢自己学的是C++,要是换成别的语言,说不定早就改行了。由于新的语言不断增长,导致从事开发软件可适应的人群越来越杂,做软件的人多了,竞争也更加激烈,导致程序员的收入提不上去,逐渐蓝领化了。那么现在的程序员将如何发展呢,要么从事软件架构的,但不是所有人都可以做软件架构的,那么就跑业务吧。如果你不懂业务,也不懂架构怎么办,那没办法了,只好转行了,做非软件行业。那些业务软件的人在他很早的年领阶段就不从事开发了。楼主呀,你要感谢自己学的是C++,让你的开发时间长了好几倍。那你就可以一门心思钻研技术了。
- naiveC
- 等 级:
- tunnel115
- 等 级:
- chengwanzkq
- 等 级:
直接基于对话框的程序,————呵呵,主窗口对话框。
其他的如菜单,工具栏是自己动态创建的。抛弃Frame/View/Doc之间的耦合带来的难以理解。我觉得MFC还是很出色的。最起码,我觉得用MFC写出的比用标准库写出的程序可读性强得多。
- Joneydry
- 等 级:
- qq51931375
- 等 级:
- zhujunzhujun
- 等 级:
其实呢,VC本可以更好的,现在搞个什么VC.NET不是很爽,要是VC.net中可以做出完全可以做出脱离framework的东东就更好了.
- 无意中看到一个很强的贴,简直一群机关枪阿
- 无意中看到的好书
- 无意中看到的一个很有意思的面试题,来做做~
- 无意中看到一个项目,和我们现在做的很相似
- 无意中看到的一句话,寒!
- 无意中看到的小故事。
- 无意中看到的Shader文章,感觉很适用
- 无意中看到
- 那是我无意中看到的一幕
- 无意中看到一篇不一样的励志文章
- 无意中看到一篇讲洋酒的文章,感觉很长见识,转过来,分享一下
- 无意中看到一个关于程序员面试的文章,拿来共勉。发觉差距太大,需要学习的东西太多。
- 无意中看到,有一些感受。。。
- 无意中看到的关于计算机的发展讨论
- 可伸缩性系统的最佳实践(无意中看到)
- 无意中见到一个不错的图标网站
- 记录一下下,无意中看到........
- Resharper简直太强了。
- SQL2005中的复制问题的处理(仅用于事务复制)
- English:什么是表语
- 我也在CSDN上有博客了,
- test
- 《JavaScript引擎技术》-SD2大会中的PPT
- 无意中看到一个很强的贴,简直一群机关枪阿
- 中小企业服务器托管经验完全手册
- 理想与未来
- 程序员考试心得体会
- 游戏配置序列化
- 需求的层次
- 是QA还是AQ?
- Fineplus 1.0(QQ完美助手) 正式版
- 基于Visual C++6.0工具下的声音文件操作