看了《C++ PRIMER》 ,和侯捷的《WINDOWS 编程》,把里面的源程序全都试验过了(有几个过不了,没找出原因)。再看别的书,都有MFC的影子,甚至全部是为MFC讲解(甚至是大家一致推崇的《vc++技术内幕第四版 (潘爱民)》也是面向MFC的,还有微软的图书也是),但我看了些MFC的源代码,觉得MFC好乱,没有头绪,把WINDOWS的消息和基本视窗都封装了,很不直观。问问各位大虾,能不能不用MFC而直接用VC函数加上WINDOWS消息处理来写程序啊?我觉得这样的程序效率更高更可靠,看起来也更直观。
解决方案 »
- javascript给Activex控件传数据
- 我写的通过匿名管道作为程序的输入输出运行一个程序并获取程序的运行时间和内存的程序,有几个地方有问题,大家帮忙看看哪里的问题
- directshow 音视频格式转化,转化过程中可不可以修改比特率、声道 数
- 有没有哪位听说过JND(Just Noticeable Difference)
- DOS
- 如何获得当前活动的窗口
- 组件注册的时候出现这个问题:0x80020009
- 请问如何在文件指针已经定位的位置插入一行,而不影响它以下的数据??
- 怎样在视类里得到工具条上ComboBox里选中的值呀?
- 如何将WIN9X设置为无限FTP服务器呢?欢迎讨论黑软件原理.
- 关于access数据库的问题,高手请进
- 用new 创建了堆对象, 请问数组名是什么?
不过俺还是挺喜欢MFC的。
还有,侯捷的那本《WINDOWS编程》基本涵盖了WINDOWS的所有视窗类别,但不是很完善,看完后还是对WINDOWS的全部消息机制缺乏全面了解,下一步是不是该看VC的函数库和WINDOWS的消息过程啊(WINDOWS总共是不是只有140种消息)?我看很多书都是讲MFC类库的,VC的函数库哪里有?我是蔡鸟,请指点.
VC为我们提供的类库主要就是MFC。
使用MFC并不等于非要使用VC的应用程序向导,你也完全可以从空项目开始自己组织所有的代码。没什么不方便的。
而一旦决定使用VC的应用程序向导,那就说明你的程序需要的功能跟某种模式的通用应用程序模板(如单文档、多文档或基于对话框的程序,特别是具备文档/视图结构的程序)相符合,这时,我倒觉得最好不要去特别关心向导自动生成的那些代码。如果你对那些代码不放心,那还是说明你的程序的所需的模式不适合应用程序向导中的任何一种,因为你已经非常关注那些模式的内部实现,甚至企图修改他们。虽然许多人认为MFC并不是很优秀,但还是能提供不少方便的,满足一般的应用程序开发绰绰有余了。
如简单易用的CString类,操纵字符串就像揉面一样简单;
操作文件的CFile、CStdioFile,对于一般的文件读写,比CRT中的文件指针方式和Windows API中的CreateFile等API用起来都要方便些;
操作数据库的CDatabase和CRecordset类,也比直接使用ODBC API方便了许多,简直就像用VB一样;
封装完好的各种窗体、控件类——GUI可是实践面向对象的极佳场合;
还用基本的容器模板:CArray、CList、CMap(极其派生类),在VC编程中都非常有用;说到底,MFC也只是一套工具,用与不用纯粹是个悉听尊便的问题。但如果它能为我们提供的遍历,我们不去用,那是不是太迂腐?
还有些人与楼主正相反,他们什么问题都企图通过MFC或标准库来解决,一旦解决不了就发愁,甚至做不下去了,那也不对,MFC并不是万能的,任何库都不可能是万能的。当它不适合我们的某项具体需求时,我们还可以用其它第三方的组件或者类库啊;再要不行,我们自己来封装自己所需要的类、模板等不是也挺好的吗?总之,一切为了解决问题,不要轻易地讨厌什么,更不要完全依赖于什么。
建议读读侯先生的《深入浅出MFC》。最后VC只是个开发工具,如果讲VC的书不讲MFC,我倒觉得那也不像是讲VC的书了,因为其中涉及倒VC的东西太少了(除了MFC,VC只剩一个IDE界面了,有什么好讲的?),那种可能是“讲SDK的书”(就像《Programming Windows》)或者“讲C++语言的书”。
为什么别人学SDK不仅不觉得妨碍使用MFC,反而觉得大大有助于MFC的学习和使用呢?
就好像有的人认为学习C语言影响了C++语言的学习,有的人却觉得学好C语言对学习C++是很有利的。
开始学的时候想从最低层的学起,就看了 win32 的汇编,学了没多久,烦得要死:)
不过还改造了一个程序,
后来觉得那些汇编符号真是太烦人,就想用C语言了,发现没办法用,因为找不到合适的编译器,
就开始学VC++了,
学了好久了,开始只用API,觉得还可以理解,现在就郁闷 了,
自从看了MFC之后,哎,别提有多痛苦!!