精华内容
下载资源
问答
  • MFC和QT区别

    千次阅读 2019-04-29 17:06:38
    MFC 微软基础类库(英语:Microsoft Foundation Classes,简称MFC)是微软公司提供的...其中包含大量Windows句柄封装类很多Windows的内建控件组件的封装类。早期很多学习计算机专业的读者可以在学校里面都有接触...

     

    MFC
    微软基础类库(英语:Microsoft Foundation Classes,简称MFC)是微软公司提供的一个类库(class libraries),以C++类的形式封装了Windows API,并且包含一个应用程序框架,以减少应用程序开发人员的工作量。其中包含大量Windows句柄封装类和很多Windows的内建控件和组件的封装类。早期很多学习计算机专业的读者可以在学校里面都有接触过,因为这个是每一个计算机专业的读者必修课程,所以在早期的C++项目里面很多都是使用MFC为开发框架进行构建的,因为它有一个很大的好处就是和我们的windows的系统兼容性很好,可以直接调用整个系统的API函数,而且开发的程序对系统的支持度很好,因为我们现在的windows系统都是在向前兼容的,如windows系统里面有win 95、win98、win2000,win Xp,win7,这些操作系统都是一致向前兼容的,如果经历过这些系统的读者都会发现系统在win8之前一直往前兼容,造成操作系统变得越来越大,在win8系统,后windows系统引入C#一起来对windows系统进行调控,这时我们会发现win8对win7的兼容性很差,而且这个操作系统也是微软除visit系统最短命的系统,这个时候我们就会发现我们的MFC开发的程序在整个windows兼容性不是那么高了,而且由于当时,对于我们的C++开发一直有一个叫做visual studio 的编译器在C#语言没有出来前,只能编译C++,所以visual studio作为全世界最优的编译器也是整体支持MFC,所以这个时候我们现实生活中在windows系统开发的程序很大部分都是使用了MFC框架进行开发,在如今我们的很多酒店、政府等等很多行业上面用的都是MFC框架进行开发,MFC全面支持COM组件开发,这个时候很多在windows开发的程序也会在这上面支持COM组件开发,还有由于在中国大部分计算机的使用者都是用的windows系统,所以在开发程序中用C++来开发的时候都是使用了最为稳定的MFC进行开发,记得几年前和一位一起工作的朋友曾经谈过,只要微软不倒闭,MFC的工作者就不会失业,为啥呢,哪怕现在在windows上面最为流行的C#语言也没有C++中的windows编程对windows操作系统操作这么流利,打个比方如果你的电脑里面在加上一个高拍仪这个时候要用到的是USB驱动进行调用,这个时候处理USB驱动调用的时候就会发现,驱动调用的数据都需要进行位运算,这个时候用C++来处理是最为方便的,所以C++在windows上面的开发之所以占尽了便宜,是因为windows编程,而我们的MFC是封装后的windows编程。

    QT
     

    是一个1991年由Qt Company开发的跨平台C++图形用户界面应用程序开发框架。它既可以开发GUI程序,也可用于开发非GUI程序,比如控制台工具和服务器。Qt是面向对象的框架,使用特殊的代码生成扩展(称为元对象编译器(Meta Object Compiler, moc))以及一些宏,Qt很容易扩展,并且允许真正地组件编程。QT在很多时候我们都不是很了解,是因为在QT在2008年由诺基亚收购后出现了我们的诺基亚第一个智能手机系统塞班图,但是由于当时的安卓系统的流行,所以最后我们的手机神话诺基亚也因此迅速下滑,最后QT被诺基亚公司转让给Digia,2014年4月,跨平台集成开发环境Qt Creator 3.1.0正式发布,实现了对于iOS的完全支持,新增WinRT、Beautifier等插件,废弃了无Python接口的GDB调试支持,集成了基于Clang的C/C++代码模块,并对Android支持做出了调整,至此实现了全面支持iOS、Android、WP,它提供给应用程序开发者建立艺术级的图形用户界面所需的所有功能。基本上,Qt 同 X Window 上的 Motif,Openwin,GTK 等图形界 面库和 Windows 平台上的 MFC,OWL,VCL,ATL 是同类型的东西。优良的跨平台特性: Qt支持下列操作系统: Microsoft Windows 95/98, Microsoft Windows NT, Linux, Solaris, SunOS, HP-UX, Digital UNIX (OSF/1, Tru64), Irix, FreeBSD, BSD/OS, SCO, AIX, OS390,QNX 等等。面向对象:Qt 的良好封装机制使得 Qt 的模块化程度非常高,可重用性较好,对于用户开发来说是非常 方便的。 Qt 提供了一种称为 signals/slots 的安全类型来替代 callback,这使得各个元件 之间的协同工作变得十分简单。丰富的 API:Qt 包括多达 250 个以上的 C++ 类,还提供基于模板的 collections, serialization, file, I/O device, directory management, date/time 类。甚至还包括正则表达式的处理 功能。支持 2D/3D 图形渲染,支持 OpenGL;
     

     

    在windows系统


    由于QT开发的界面全面支持脚本开发并且QT可以嵌入到visual studio进行开发,所以做出来的界面非常的精美,所以现在C++在windows平台开发会使用QT作为应用程序开发,进而调用windows编程来进行驱动的开发,这样俩者完美的兼容在一起,这样可以避免QT开发程序的不稳定性和MFC开发界面不够美观的问题,所以在windows上面一般使用C++开发桌面应用程序使用的是windows编程+QT框架编程;


    在liunx系统

    liunx系统上面进行开发是我们所有学习C++读者必须知道的知识,为啥liunx下面有俩个大东西,服务器和嵌入式,做服务器可以在linux下面做多线程开发,这个线程池的开发,所以现在大部分的服务器都是运行在liunx系统上面,嵌入式开发由于liunx的开发板现在是最为便宜的也和学校里面的学习上面有关,所以很多嵌入式设备里面嵌入的都是liunx系统,在这上面我们的QT可以在liunx下面从事嵌入式界面开发,因为liunx程序也会有桌面程序,这个时候可以通过QT arm开发所以可以在linux下面进行界面开发



    作者:莫影
    链接:https://www.zhihu.com/question/286904809/answer/452036336
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。


     

    展开全文
  • mfc和qt区别

    2019-09-24 08:22:37
    QT使用的编译器是MinGW,即Linux下的GCC移植到...MFC使用的编译器是Visual C++ QT的应用主要在Linux下,但是它本身是跨平台的,也支持其他操作系统,是现在比较著名的界面库,著名的KDE就是使用QT开发的。...

    注:引用来源 http://wenda.chinabaike.com/b/30934/2013/1208/707410.html

     

    QT使用的编译器是MinGW,即Linux下的GCC移植到windows的版本;MFC使用的编译器是Visual C++
    QT的应用主要在Linux下,但是它本身是跨平台的,也支持其他操作系统,是现在比较著名的界面库,著名的KDE就是使用QT开发的。MFC是提供给VC的,但是它主要是代码库,不像VCL和编译器挂钩很多,但是MFC主要是对windows API的封装,所以只能用于windows平台

    根据你所说的方面,简单比较一下:
    1.开发速度
    整体来说可能MFC会快捷一些,因为windows平台的开发工具大多很智能,因为立足于windows的开发人群很广,从菜鸟到专业人士,但是QT由于基于Linux,可用的开发工具不多,大都比较专业,多是第三方产品,而且集成度不大,第三方库也没有MFC的多,从这一点MFC略胜一筹,但是QT自从被Nokia收购后,官方发布了跨平台集成开发环境QTCreator,所以之后走向就不好说了,个人总体感觉QT Creator和VS.net差距比较大,还需改进
    但是从库本身来说QT集成的功能较MFC庞大,而且使用的封装技术信号和槽也是比较受到赞许的,比如QT Script为QT提供嵌入式脚本,QT界面库支持CSS,所以QT做出来的界面比MFC要好,而且比较容易,MFC就需要借助第三方库了。因为MFC是浅层封装(最新的2008 sp1加入了BCG的高级界面库,可能有所改善)windows SDK,以降低使用windows SDK引起的开发效率的降低,和开发难度的增加。所以QT库是比MFC优秀的,两个库都经受了时间的考验,稳定性都很高,Bug几乎没有
    2.运行效率
    MFC由于其浅层封装的特点,所以运行效率是比较高的,加上vc对windows的针对性优化,整体性能是比较高的,但是如果加入第三方库就不敢保证了QT因为库比较庞大,封装层次较深,所以运行效率较MFC为低,但是在现在的机器配置下,C#大家都不介意了,这些会引起人们的介意吗?
    3.应用范围,现在windows的普及范围谁能比过,所以MFC的客户量比较多,QT主要是Linux下的开发人员在使用,但MFC也只是得益于windows(感觉又是一次捆绑战略),MFC不支持嵌入式开发(主要指手机平台),但是QT有对应的模块

     

    4.学习难度
    QT的封装哲学比较明晰,和系统隔离的比较好,所以个人感觉门槛不高
    MFC较难精通,因为深入开发之后SDK还是要了解的,否则程序感觉比较儿童化,呵呵
    最近用了一段时间Qt,觉得网上这篇文章讲述Qt与MFC之间的区别很到位,分享一下。

     

    ----------------------------------原文----------------------------------------------------

     

    我曾经使用过QT和MFC来开发过软件,我想和大家分享我使用他们时所体会的不同之处。

     

    我并非一个职业作家,这篇文章可能看起来不如专业的杂志和网站上的那么条理清晰。但是,我在这里是用我自己的语言来表达我自己的经验,希望能和你分享。英语比不是我的母语,所以可能会有一些用词古怪,词句错误之处,请发信给我,我可以改正他们。

     

    本文不想假装客观公正,我只想表述我使用的经验。文中不会逐条的列举Qt和MFC各自的优缺点。我在使用MFC之前就已经使用Qt这个事实可能影响了我的客观性。

     

    文章从实用主义的观点出发:我的老板给我一份软件的规划说明,并且让我来开发。其中一些我用Qt来开发,而另外一些我使用MFC来开发。

     

    MFC(微软基础类库)是专门为windows设计的一个用于开发图形用户界面的类库。MFC或多或少使用了面向对象的方法包装了Win32的API,正因如此,这些API有时是C++,有时是C,甚至是C和C++的混合体。

     

    Qt这个C++的图形库由Trolltech在1994年左右开发。它可以运行在Windows,Mac OSX, Unix,还有像Sharp Zaurus这类嵌入式系统中。Qt是完全面向对象的。Document/View modelMFC编程需要使用Document/View模式以及模板(template),如果不使用的话,编程将变得异常困难。而且,模板(template)设定了固定的结构,若所需结构乃模板未定义之结构,则编程难已。例如,划分一区域使显示两个视图(view)于两个文档(document)。还有一个经常的问题是:模板(template)创建了视图(view)却无法访问(access)它,文档(document)要做完所有事情,但是这经常会出现问题。 (这种数据和视图分开的设计模式也是一种不错的模式,不应该成为否定MFC的理由)Qt不强制使用任何设计模式。如果你认为恰当,使用Document/view没有任何问题。不使用也没有任何问题。

     

     

     

    伪对象 vs 真对象

     

    归根结底,Qt和MFC的差异在于其设计的差异。MFC的根本目的是访问包装起来的用C语言写的windows的API。 这绝非好的面向对象的设计模式,在很多地方,你必须提供一个包含15个成员的C语言的struct,但是其中只有一个与你所期望的相关,或者必须用旧式的参数来调用你的函数。MFC还有许多让人摸不着头脑的地方,函数名没有任何的连续性。比如,如果你创建了一个graphical类,直到调用了creat()以后该类才会被创建。然而对dialogs,必须要等到OnInitDialog()才能创建这个对象。奇怪的是到了views,创建该类的函数名竟然成了OnInitUpdate(),......你自己创建一个类用他们的方式调用它,你的程序崩溃了。

     

    比如说有一个dialog包含CEdit控件,如果没有调用DoModal()你就不能使用GetWindowText()。否则将会莫名其妙的失败。总之,MFC充满了丈二和尚摸不着头脑的事情,并且,这种错误很难调试。 (诚然,MFC是为了封装Window API。用MFC比WinowsAPI会简单些,但确实有些函数的调用时机、先后顺序,如果不是用过一段时间,确实可能

     

    因此导致问题)

     

    Qt恰恰相反,它的架构明显是经过精心设计的面向对象的。Qt因此在命名,继承,类的组织等方面保持了优秀的一致性。你只需要提供唯一一个方法的参数,仅此一个。在不同的类中调用方式也是有很强的连贯性。返回值也很有逻辑性。所有一切达到了简单和强大的和谐统一。一旦你使用了其中一个类,其他的类也就触类旁通,因为他们是一致的。在Qt中可以利用Edit控件,用C++创建类的方法来创建自己的QLineEdit。永远可以马上访问任何的方法,不管它是显示还是隐藏。在这里没有迷局,一切都按照你认为的简单的方式来运作。

     

     

     

    消息循环

     

    MFC是事件驱动的架构。要执行任何操作,都必须是对特定的消息作出响应。Windows对应用程序发送的

     

    信息数以千计,遗憾的是,要分清楚这些分繁芜杂的消息是很困难的,并且关于这方面的文档并不能很好的解决这些问题。

     

    Qt的消息机制是建立在SIGNAL()发送和SLOT()接受的基础上的。这个机制是对象间建立联系的核心机制。利用SIGNAL()可以传递任何的参数。他的功能非常的强大。可以直接大传递信号给SLOT(),因此可以清楚的理解要发生的事情。一个类所发送的信号的数量通常非常的小(4或者5),并且文档也非常的齐全。这让你感觉到一切尽在掌握之中。SIGNAL/SLOT机制类似于Java中listener机制,不过这种机制更加轻量级,功能更齐全。(这种机制确实貌似简单清晰了一些)

     

     

     

    创建界面

     

    MFC无法创建大小动态可变的子窗口 ,必须重新手动修改代码来改变窗口的位置(这恰好解释了为什么windows里的dialog是不可以改变的)这个问题在软件进行国际化翻译的时候更加严重,因为许多国家表达相同意思需要更长的词汇和句子,必须要对每个语言的版本重新修改自己的软件。

     

    在Qt中,任何东西都可以手动的敲出来,因为它很简单:为了得到一个utton,可以这样些button = new PushButton( "buttonName", MyParentName );如果想在按下某个按钮以后想调用某断代码的执行,可以这样写:connect( button, SIGNAL( clicked() ), qApp, SLOT( action() ) );Qt拥有非常简单而又不失强大的layout机制,以至于不使用它就是在浪费时间了。

     

    Qt还提供了一个图形用户工具,Qt Designer,可以用来帮助建立用户界面。可以修改

     

    所使用的任何控件的属性。不用将他们放在严格的位置,可以通过layout完美的组织他们。

     

    这个工具所产生的代码我们是可以实际上阅读并且可以理解的。生成的代码单独放在一个文

     

    件里,在编程的同时,你可以随心所欲的多次重新生成用户界面。

     

    Qt Designer可以让你完成许多在MFC中不可能完成的任务,比如用预先填好的生成listview,在每个tab上用不同的view来使用tab 控制。 (界面方面Qt确实很好很强大)

     

     

     

    帮助文档

     

    用户选择图形开发环境的时候,帮助文档是否周全是左右其选择的重要因素。Visual的开发环境的帮助文档MSDN(这个还要单独掏钱购买)非常的庞大,有10个CDROM光盘。他包罗万象,涵盖广泛。但是难免有泥沙俱下,主题模糊,关键信息不突出的遗憾。其链接设计的也很糟糕,通过链接很难从一个类跳转到其父类或者子类以及相关的类。如果你搜索一个关键字,不管是Visual C++, Visual J++, Visual Basic,只要包含这些关键字的信息统统的返回来。

     

     

     

    Qt的文档设计的相当优秀。你可以到doc.tolltech.com上面一睹芳容。Qt的文档完备且详细的覆盖了Qt的方方面面,竟然仅有18M。每一个类和方法都被详尽描述,巨细靡遗,举例充实。通过Trolltech公司提供的链接或者是Qt Assistant工具,可以方便的从一个类或者方法跳转到其他的类。文档还包含了一个初学者教程和一些典型应用的例子。同时还提供了FAQ和邮件列表,方便通过Internet或者用户群来查阅。如果你购买了授权,在一天之内你将会得到Trolltech公司的技术支持。实际上,Qt优秀的帮助文档使得寻求外部帮助的机会大大减少。Tolltech公司的一个宗旨是:有如此优秀的Qt产品以及其帮助文档,技术支持是多余的。

     

    (MSDN用熟了很好用,很全面,相关的背景知识,例子都能找到。而且网上还有丰富的例程可以参考。仅凭Qt的帮助文档绝对不足以解决所有问题,而网上我只找了个Qt中文论坛,提过几个问题,有的给出了解决办法,有的也没人回答,还要靠自己试)

     

     

     

    Unicode

     

    使用MFC,如果要显示unicode,在编译链接的时候必须用到特殊的参数(和改变可执行文件执行的入口),必须在每个string前面加上T,将char修改成TCHAR,每个字符串处理函数(strcpy(), strdup(), strcat()...... )都要改变成另外的函数名。更令人恼火的是支持Unicode的软件竟然不能和不支持Unicode的DLL一起工作。当使用外部DLL来开发的时候

     

    这是个很严重的问题,但是你毫无选择。

     

    使用Qt,字符串用QString来处理,其本身是与生俱来的Unicode.不需要改变什么东西。不要在编译/链接时候增添参数,不要修改代码,只需要使用QString就可以了。QSting类功能强大,你可以广泛的使用它,并且不要担心Unicode问题。这使得转换为Unicode非常的方便。QSting提供了转换为char * 和UTF8的函数。显然,MFC的CString的设计相比于Qt的QString设计有着巨大的不同。CString以char *为基础提供了很少的功能。它的优点是当需要char *类型的时候,可以直接使用CString类型。乍看起来这个好像是个优点,其实实质上还是有很大的缺陷的,特别是可以直接修改char * 而不要更新类。在转变为Unicode的时候这个也碰到很大的麻烦。(CString随编译选项可以是Unicode版)相反,QString在内部以unicode存储string,需要时提供char *功能。实际上很少用到char *,因为整个Qt的API用文本的方式响应QString参数。QString还附带许多其他的功能,比如自动分享QString的内容。这是一个非常强大的类,你会喜欢在很多地方用它

     

    的。

     

     

     

    国际化

     

    使用MFC是可以国际化的,但是需要将每一个字符串放在一个字符串表中,在代码中到处使用LoadString(IDENTIFIET)。然后转化这些资源到DLL中,翻译字符串到所需要的语言,改变图形界面,然后调用程序使用这个DLL。整个过程是如此的繁琐,可谓牵一发而动全身。考虑的事情要面面俱到。

     

    使用Qt的时候,只需要将字符串置于函数tr()中,在程序开发中这算是举手之劳。可以直接在代码中改变字符串的参考。Qt Linguist,Qt的一个工具,能够提取所有待翻译的string并按照友好的界面显示出来。这个用户界面非常适合翻译,使用字典,显示字符串内容,恰当的unicode显示,快捷方式冲突检测,检测未翻译的字符串,检测字符串修改情况,功能齐全。这个软件可以供没有任何编程经验的翻译者使用。同时该软件在GPL的版权下发布,可以按照你的需求来修改它。翻译以后的文档保存在XML中,适合软件复用的原则。为软件增加一种新的语言版本仅仅是用Qt Linguist产生一个新的文件而已。(这点Qt做的很不错。)

     

     

     

    resources问题

     

    使用MFC,一部分开发过程要依靠“resources”,在很多的案例中开发者必须使用他们。这样会导致如下的后果:出了Visual Studio,你很难使用其他的工具来完成开发。 资源编辑器仅有有限的功能,比如:通过Dialog编辑器不可能改变所有的属性,一些属性可以改变,另一些属性则不可能改变。(译者注:下面还有两条陈述MFC缺点的实例,但我感觉这些已经够说明问题了,暂时删节不译)

     

    然而Qt并没有资源的概念,这就解决了以上所提到的问题。Qt提供了一个脚本使得能将编入你的代码。对于界面设计,Qt Designer则创建了可读的代码。 (Qt Designer设计界面很不错)

     

     

     

    价格

     

    一旦你购买了Visual Studio,你将免费的获得MFC SDK。Qt在Unix上是可以免费获得其遵守GPL版权的版本(译者注:现在在windows 上也可以免费获得其GPL版本)。如果要开发不公开源代码的软件,必须购买Qt的授权。在特定平台下,每个开发者购买一个永久性授权,并获得一年的技术支持。(译者注:后面关于购买价格等问题删去,因为价格不固定,如果有疑问请到官方网站查询价格)

     

    发布

     

    在发布基于MFC的软件时,必须依靠存在于客户电脑上的MFC。但是这是不安全的,同样是MFC42.dll,可以基于相同的库得到3个不同的版本。通常,需要检查是否拥有正确的MFC42.dll版本,如果不是,就升级它。但是升级MFC42.dll会改变很多软件的行为。这让我感到很不舒服,如果用户在安装我的软件以后导致其机器死机该怎么办?

     

    Qt则没有这个风险,因为Qt压根就没有“升级整个系统”这个概念。(如果不是一个版本的Qt,还是会有问题的)

     

     

     

    速度

     

     

     

    MFC是专为Windows设计的,而Qt是跨平台的。所以MFC编写的程序的运行速度、响应时间都优于Qt.

     

    转载于:https://www.cnblogs.com/ldhbetter/p/8400028.html

    展开全文
  • MFCQT区别

    2018-09-06 12:18:00
    QT使用的编译器是MinGW,即Linux下的GCC移植到windows的版本;...MFC是提供给VC的,但是它主要是代码库,不像VCL编译器挂钩很多,但是MFC主要是对windows API的封装,所以只能用于windows平台根据...

    QT使用的编译器是MinGW,即Linux下的GCC移植到windows的版本;MFC使用的编译器是Visual C++

    QT的应用主要在Linux下,但是它本身是跨平台的,也支持其他操作系统,是现在比较著名的界面库,著名的KDE就是使用QT开发的。MFC是提供给VC的,但是它主要是代码库,不像VCL和编译器挂钩很多,但是MFC主要是对windows API的封装,所以只能用于windows平台

    根据你所说的方面,简单比较一下:
    1.开发速度
    整体来说可能MFC会快捷一些,因为windows平台的开发工具大多很智能,因为立足于windows的开发人群很广,从菜鸟到专业人士,但是QT由于基于Linux,可用的开发工具不多,大都比较专业,多是第三方产品,而且集成度不大,第三方库也没有MFC的多,从这一点MFC略胜一筹,但是QT自从被Nokia收购后,官方发布了跨平台集成开发环境QTCreator,所以之后走向就不好说了,个人总体感觉QT Creator和VS.net差距比较大,还需改进
    但是从库本身来说QT集成的功能较MFC庞大,而且使用的封装技术信号和槽也是比较受到赞许的,比如QT Script为QT提供嵌入式脚本,QT界面库支持CSS,所以QT做出来的界面比MFC要好,而且比较容易,MFC就需要借助第三方库了。因为MFC是浅层封装(最新的2008 sp1加入了BCG的高级界面库,可能有所改善)windows SDK,以降低使用windows SDK引起的开发效率的降低,和开发难度的增加。所以QT库是比MFC优秀的,两个库都经受了时间的考验,稳定性都很高,Bug几乎没有
    2.运行效率
    MFC由于其浅层封装的特点,所以运行效率是比较高的,加上vc对windows的针对性优化,整体性能是比较高的,但是如果加入第三方库就不敢保证了QT因为库比较庞大,封装层次较深,所以运行效率较MFC为低,但是在现在的机器配置下,C#大家都不介意了,这些会引起人们的介意吗?
    3.应用范围,现在windows的普及范围谁能比过,所以MFC的客户量比较多,QT主要是Linux下的开发人员在使用,但MFC也只是得益于windows(感觉又是一次捆绑战略),MFC不支持嵌入式开发(主要指手机平台),但是QT有对应的模块

    4.学习难度
    QT的封装哲学比较明晰,和系统隔离的比较好,所以个人感觉门槛不高
    MFC较难精通,因为深入开发之后SDK还是要了解的,否则程序感觉比较儿童化,呵呵
    最近用了一段时间Qt,觉得网上这篇文章讲述Qt与MFC之间的区别很到位,分享一下。

    ----------------------------------原文----------------------------------------------------

    我曾经使用过QT和MFC来开发过软件,我想和大家分享我使用他们时所体会的不同之处。

    我并非一个职业作家,这篇文章可能看起来不如专业的杂志和网站上的那么条理清晰。但是,我在这里是用我自己的语言来表达我自己的经验,希望能和你分享。英语比不是我的母语,所以可能会有一些用词古怪,词句错误之处,请发信给我,我可以改正他们。

    本文不想假装客观公正,我只想表述我使用的经验。文中不会逐条的列举Qt和MFC各自的优缺点。我在使用MFC之前就已经使用Qt这个事实可能影响了我的客观性。

    文章从实用主义的观点出发:我的老板给我一份软件的规划说明,并且让我来开发。其中一些我用Qt来开发,而另外一些我使用MFC来开发。

    MFC(微软基础类库)是专门为windows设计的一个用于开发图形用户界面的类库。MFC或多或少使用了面向对象的方法包装了Win32的API,正因如此,这些API有时是C++,有时是C,甚至是C和C++的混合体。

    Qt这个C++的图形库由Trolltech在1994年左右开发。它可以运行在Windows,Mac OSX, Unix,还有像Sharp Zaurus这类嵌入式系统中。Qt是完全面向对象的。Document/View modelMFC编程需要使用Document/View模式以及模板(template),如果不使用的话,编程将变得异常困难。而且,模板(template)设定了固定的结构,若所需结构乃模板未定义之结构,则编程难已。例如,划分一区域使显示两个视图(view)于两个文档(document)。还有一个经常的问题是:模板(template)创建了视图(view)却无法访问(access)它,文档(document)要做完所有事情,但是这经常会出现问题。 (这种数据和视图分开的设计模式也是一种不错的模式,不应该成为否定MFC的理由)Qt不强制使用任何设计模式。如果你认为恰当,使用Document/view没有任何问题。不使用也没有任何问题。

     

    伪对象 vs 真对象

    归根结底,Qt和MFC的差异在于其设计的差异。MFC的根本目的是访问包装起来的用C语言写的windows的API。 这绝非好的面向对象的设计模式,在很多地方,你必须提供一个包含15个成员的C语言的struct,但是其中只有一个与你所期望的相关,或者必须用旧式的参数来调用你的函数。MFC还有许多让人摸不着头脑的地方,函数名没有任何的连续性。比如,如果你创建了一个graphical类,直到调用了creat()以后该类才会被创建。然而对dialogs,必须要等到OnInitDialog()才能创建这个对象。奇怪的是到了views,创建该类的函数名竟然成了OnInitUpdate(),......你自己创建一个类用他们的方式调用它,你的程序崩溃了。

    比如说有一个dialog包含CEdit控件,如果没有调用DoModal()你就不能使用GetWindowText()。否则将会莫名其妙的失败。总之,MFC充满了丈二和尚摸不着头脑的事情,并且,这种错误很难调试。 (诚然,MFC是为了封装Window API。用MFC比WinowsAPI会简单些,但确实有些函数的调用时机、先后顺序,如果不是用过一段时间,确实可能

    因此导致问题)

    Qt恰恰相反,它的架构明显是经过精心设计的面向对象的。Qt因此在命名,继承,类的组织等方面保持了优秀的一致性。你只需要提供唯一一个方法的参数,仅此一个。在不同的类中调用方式也是有很强的连贯性。返回值也很有逻辑性。所有一切达到了简单和强大的和谐统一。一旦你使用了其中一个类,其他的类也就触类旁通,因为他们是一致的。在Qt中可以利用Edit控件,用C++创建类的方法来创建自己的QLineEdit。永远可以马上访问任何的方法,不管它是显示还是隐藏。在这里没有迷局,一切都按照你认为的简单的方式来运作。

     

    消息循环

    MFC是事件驱动的架构。要执行任何操作,都必须是对特定的消息作出响应。Windows对应用程序发送的

    信息数以千计,遗憾的是,要分清楚这些分繁芜杂的消息是很困难的,并且关于这方面的文档并不能很好的解决这些问题。

    Qt的消息机制是建立在SIGNAL()发送和SLOT()接受的基础上的。这个机制是对象间建立联系的核心机制。利用SIGNAL()可以传递任何的参数。他的功能非常的强大。可以直接大传递信号给SLOT(),因此可以清楚的理解要发生的事情。一个类所发送的信号的数量通常非常的小(4或者5),并且文档也非常的齐全。这让你感觉到一切尽在掌握之中。SIGNAL/SLOT机制类似于Java中listener机制,不过这种机制更加轻量级,功能更齐全。(这种机制确实貌似简单清晰了一些)

     

    创建界面

    MFC无法创建大小动态可变的子窗口 ,必须重新手动修改代码来改变窗口的位置(这恰好解释了为什么windows里的dialog是不可以改变的)这个问题在软件进行国际化翻译的时候更加严重,因为许多国家表达相同意思需要更长的词汇和句子,必须要对每个语言的版本重新修改自己的软件。

    在Qt中,任何东西都可以手动的敲出来,因为它很简单:为了得到一个utton,可以这样些button = new PushButton( "buttonName", MyParentName );如果想在按下某个按钮以后想调用某断代码的执行,可以这样写:connect( button, SIGNAL( clicked() ), qApp, SLOT( action() ) );Qt拥有非常简单而又不失强大的layout机制,以至于不使用它就是在浪费时间了。

    Qt还提供了一个图形用户工具,Qt Designer,可以用来帮助建立用户界面。可以修改

    所使用的任何控件的属性。不用将他们放在严格的位置,可以通过layout完美的组织他们。

    这个工具所产生的代码我们是可以实际上阅读并且可以理解的。生成的代码单独放在一个文

    件里,在编程的同时,你可以随心所欲的多次重新生成用户界面。

    Qt Designer可以让你完成许多在MFC中不可能完成的任务,比如用预先填好的生成listview,在每个tab上用不同的view来使用tab 控制。 (界面方面Qt确实很好很强大)

     

    帮助文档

    用户选择图形开发环境的时候,帮助文档是否周全是左右其选择的重要因素。Visual的开发环境的帮助文档MSDN(这个还要单独掏钱购买)非常的庞大,有10个CDROM光盘。他包罗万象,涵盖广泛。但是难免有泥沙俱下,主题模糊,关键信息不突出的遗憾。其链接设计的也很糟糕,通过链接很难从一个类跳转到其父类或者子类以及相关的类。如果你搜索一个关键字,不管是Visual C++, Visual J++, Visual Basic,只要包含这些关键字的信息统统的返回来。

     

    Qt的文档设计的相当优秀。你可以到doc.tolltech.com上面一睹芳容。Qt的文档完备且详细的覆盖了Qt的方方面面,竟然仅有18M。每一个类和方法都被详尽描述,巨细靡遗,举例充实。通过Trolltech公司提供的链接或者是Qt Assistant工具,可以方便的从一个类或者方法跳转到其他的类。文档还包含了一个初学者教程和一些典型应用的例子。同时还提供了FAQ和邮件列表,方便通过Internet或者用户群来查阅。如果你购买了授权,在一天之内你将会得到Trolltech公司的技术支持。实际上,Qt优秀的帮助文档使得寻求外部帮助的机会大大减少。Tolltech公司的一个宗旨是:有如此优秀的Qt产品以及其帮助文档,技术支持是多余的。

    (MSDN用熟了很好用,很全面,相关的背景知识,例子都能找到。而且网上还有丰富的例程可以参考。仅凭Qt的帮助文档绝对不足以解决所有问题,而网上我只找了个Qt中文论坛,提过几个问题,有的给出了解决办法,有的也没人回答,还要靠自己试)

     

    Unicode

    使用MFC,如果要显示unicode,在编译链接的时候必须用到特殊的参数(和改变可执行文件执行的入口),必须在每个string前面加上T,将char修改成TCHAR,每个字符串处理函数(strcpy(), strdup(), strcat()...... )都要改变成另外的函数名。更令人恼火的是支持Unicode的软件竟然不能和不支持Unicode的DLL一起工作。当使用外部DLL来开发的时候

    这是个很严重的问题,但是你毫无选择。

    使用Qt,字符串用QString来处理,其本身是与生俱来的Unicode.不需要改变什么东西。不要在编译/链接时候增添参数,不要修改代码,只需要使用QString就可以了。QSting类功能强大,你可以广泛的使用它,并且不要担心Unicode问题。这使得转换为Unicode非常的方便。QSting提供了转换为char * 和UTF8的函数。显然,MFC的CString的设计相比于Qt的QString设计有着巨大的不同。CString以char *为基础提供了很少的功能。它的优点是当需要char *类型的时候,可以直接使用CString类型。乍看起来这个好像是个优点,其实实质上还是有很大的缺陷的,特别是可以直接修改char * 而不要更新类。在转变为Unicode的时候这个也碰到很大的麻烦。(CString随编译选项可以是Unicode版)相反,QString在内部以unicode存储string,需要时提供char *功能。实际上很少用到char *,因为整个Qt的API用文本的方式响应QString参数。QString还附带许多其他的功能,比如自动分享QString的内容。这是一个非常强大的类,你会喜欢在很多地方用它

    的。

    国际化

    使用MFC是可以国际化的,但是需要将每一个字符串放在一个字符串表中,在代码中到处使用LoadString(IDENTIFIET)。然后转化这些资源到DLL中,翻译字符串到所需要的语言,改变图形界面,然后调用程序使用这个DLL。整个过程是如此的繁琐,可谓牵一发而动全身。考虑的事情要面面俱到。

    使用Qt的时候,只需要将字符串置于函数tr()中,在程序开发中这算是举手之劳。可以直接在代码中改变字符串的参考。Qt Linguist,Qt的一个工具,能够提取所有待翻译的string并按照友好的界面显示出来。这个用户界面非常适合翻译,使用字典,显示字符串内容,恰当的unicode显示,快捷方式冲突检测,检测未翻译的字符串,检测字符串修改情况,功能齐全。这个软件可以供没有任何编程经验的翻译者使用。同时该软件在GPL的版权下发布,可以按照你的需求来修改它。翻译以后的文档保存在XML中,适合软件复用的原则。为软件增加一种新的语言版本仅仅是用Qt Linguist产生一个新的文件而已。(这点Qt做的很不错。)

    resources问题

    使用MFC,一部分开发过程要依靠“resources”,在很多的案例中开发者必须使用他们。这样会导致如下的后果:出了Visual Studio,你很难使用其他的工具来完成开发。 资源编辑器仅有有限的功能,比如:通过Dialog编辑器不可能改变所有的属性,一些属性可以改变,另一些属性则不可能改变。(译者注:下面还有两条陈述MFC缺点的实例,但我感觉这些已经够说明问题了,暂时删节不译)

    然而Qt并没有资源的概念,这就解决了以上所提到的问题。Qt提供了一个脚本使得能将编入你的代码。对于界面设计,Qt Designer则创建了可读的代码。 (Qt Designer设计界面很不错)

    价格

    一旦你购买了Visual Studio,你将免费的获得MFC SDK。Qt在Unix上是可以免费获得其遵守GPL版权的版本(译者注:现在在windows 上也可以免费获得其GPL版本)。如果要开发不公开源代码的软件,必须购买Qt的授权。在特定平台下,每个开发者购买一个永久性授权,并获得一年的技术支持。(译者注:后面关于购买价格等问题删去,因为价格不固定,如果有疑问请到官方网站查询价格)

    发布

    在发布基于MFC的软件时,必须依靠存在于客户电脑上的MFC。但是这是不安全的,同样是MFC42.dll,可以基于相同的库得到3个不同的版本。通常,需要检查是否拥有正确的MFC42.dll版本,如果不是,就升级它。但是升级MFC42.dll会改变很多软件的行为。这让我感到很不舒服,如果用户在安装我的软件以后导致其机器死机该怎么办?

    Qt则没有这个风险,因为Qt压根就没有“升级整个系统”这个概念。(如果不是一个版本的Qt,还是会有问题的)

    速度

    MFC是专为Windows设计的,而Qt是跨平台的。所以MFC编写的程序的运行速度、响应时间都优于Qt

    转载于:https://www.cnblogs.com/forever5325/p/9597649.html

    展开全文
  • Qt控件窗口封装进dll中,并使用MFC和Qt应用程序写出demo来调用该dll。将dll中封装的Qt窗口嵌入到主程序中,实现窗口渲染消息传递。
  • MFCQT区别

    万次阅读 2016-06-28 20:35:29
    “前言” 写得还不错,但打上了些许个人色彩...QT的应用主要在Linux下,但是它本身是跨平台的,也支持其他操作系统,是现在比较著名的界面库,著名的KDE就是使用QT开发的。MFC是提供给VC的,但是它主要是代码库,不像V

    引用来源 http://wenda.chinabaike.com/b/30934/2013/1208/707410.html

    “前言”

    写得还不错,但打上了些许个人色彩,个人认为这很正常的,希望大家多喷多讨论

    QT使用的编译器是MinGW,即Linux下的GCC移植到windows的版本;MFC使用的编译器是Visual C++

    QT的应用主要在Linux下,但是它本身是跨平台的,也支持其他操作系统,是现在比较著名的界面库,著名的KDE就是使用QT开发的。MFC是提供给VC的,但是它主要是代码库,不像VCL和编译器挂钩很多,但是MFC主要是对windows API的封装,所以只能用于windows平台

    根据你所说的方面,简单比较一下:
    1.开发速度
    整体来说可能MFC会快捷一些,因为windows平台的开发工具大多很智能,因为立足于windows的开发人群很广,从菜鸟到专业人士,但是QT由于基于Linux,可用的开发工具不多,大都比较专业,多是第三方产品,而且集成度不大,第三方库也没有MFC的多,从这一点MFC略胜一筹,但是QT自从被Nokia收购后,官方发布了跨平台集成开发环境QTCreator,所以之后走向就不好说了,个人总体感觉QT Creator和VS.net差距比较大,还需改进
    但是从库本身来说QT集成的功能较MFC庞大,而且使用的封装技术信号和槽也是比较受到赞许的,比如QT Script为QT提供嵌入式脚本,QT界面库支持CSS,所以QT做出来的界面比MFC要好,而且比较容易,MFC就需要借助第三方库了。因为MFC是浅层封装(最新的2008 sp1加入了BCG的高级界面库,可能有所改善)windows SDK,以降低使用windows SDK引起的开发效率的降低,和开发难度的增加。所以QT库是比MFC优秀的,两个库都经受了时间的考验,稳定性都很高,Bug几乎没有
    2.运行效率
    MFC由于其浅层封装的特点,所以运行效率是比较高的,加上vc对windows的针对性优化,整体性能是比较高的,但是如果加入第三方库就不敢保证了QT因为库比较庞大,封装层次较深,所以运行效率较MFC为低,但是在现在的机器配置下,C#大家都不介意了,这些会引起人们的介意吗?
    3.应用范围,现在windows的普及范围谁能比过,所以MFC的客户量比较多,QT主要是Linux下的开发人员在使用,但MFC也只是得益于windows(感觉又是一次捆绑战略),MFC不支持嵌入式开发(主要指手机平台),但是QT有对应的模块

    4.学习难度
    QT的封装哲学比较明晰,和系统隔离的比较好,所以个人感觉门槛不高
    MFC较难精通,因为深入开发之后SDK还是要了解的,否则程序感觉比较儿童化,呵呵
    最近用了一段时间Qt,觉得网上这篇文章讲述Qt与MFC之间的区别很到位,分享一下。

    ----------------------------------原文----------------------------------------------------

    我曾经使用过QT和MFC来开发过软件,我想和大家分享我使用他们时所体会的不同之处。

    我并非一个职业作家,这篇文章可能看起来不如专业的杂志和网站上的那么条理清晰。但是,我在这里是用我自己的语言来表达我自己的经验,希望能和你分享。英语比不是我的母语,所以可能会有一些用词古怪,词句错误之处,请发信给我,我可以改正他们。

    本文不想假装客观公正,我只想表述我使用的经验。文中不会逐条的列举Qt和MFC各自的优缺点。我在使用MFC之前就已经使用Qt这个事实可能影响了我的客观性。

    文章从实用主义的观点出发:我的老板给我一份软件的规划说明,并且让我来开发。其中一些我用Qt来开发,而另外一些我使用MFC来开发。

    MFC(微软基础类库)是专门为windows设计的一个用于开发图形用户界面的类库。MFC或多或少使用了面向对象的方法包装了Win32的API,正因如此,这些API有时是C++,有时是C,甚至是C和C++的混合体。

    Qt这个C++的图形库由Trolltech在1994年左右开发。它可以运行在Windows,Mac OSX, Unix,还有像Sharp Zaurus这类嵌入式系统中。Qt是完全面向对象的。Document/View modelMFC编程需要使用Document/View模式以及模板(template),如果不使用的话,编程将变得异常困难。而且,模板(template)设定了固定的结构,若所需结构乃模板未定义之结构,则编程难已。例如,划分一区域使显示两个视图(view)于两个文档(document)。还有一个经常的问题是:模板(template)创建了视图(view)却无法访问(access)它,文档(document)要做完所有事情,但是这经常会出现问题。 (这种数据和视图分开的设计模式也是一种不错的模式,不应该成为否定MFC的理由)Qt不强制使用任何设计模式。如果你认为恰当,使用Document/view没有任何问题。不使用也没有任何问题。

    伪对象 vs 真对象

    归根结底,Qt和MFC的差异在于其设计的差异。MFC的根本目的是访问包装起来的用C语言写的windows的API。 这绝非好的面向对象的设计模式,在很多地方,你必须提供一个包含15个成员的C语言的struct,但是其中只有一个与你所期望的相关,或者必须用旧式的参数来调用你的函数。MFC还有许多让人摸不着头脑的地方,函数名没有任何的连续性。比如,如果你创建了一个graphical类,直到调用了creat()以后该类才会被创建。然而对dialogs,必须要等到OnInitDialog()才能创建这个对象。奇怪的是到了views,创建该类的函数名竟然成了OnInitUpdate(),......你自己创建一个类用他们的方式调用它,你的程序崩溃了。

    比如说有一个dialog包含CEdit控件,如果没有调用DoModal()你就不能使用GetWindowText()。否则将会莫名其妙的失败。总之,MFC充满了丈二和尚摸不着头脑的事情,并且,这种错误很难调试。 (诚然,MFC是为了封装Window API。用MFC比WinowsAPI会简单些,但确实有些函数的调用时机、先后顺序,如果不是用过一段时间,确实可能

    因此导致问题)

    Qt恰恰相反,它的架构明显是经过精心设计的面向对象的。Qt因此在命名,继承,类的组织等方面保持了优秀的一致性。你只需要提供唯一一个方法的参数,仅此一个。在不同的类中调用方式也是有很强的连贯性。返回值也很有逻辑性。所有一切达到了简单和强大的和谐统一。一旦你使用了其中一个类,其他的类也就触类旁通,因为他们是一致的。在Qt中可以利用Edit控件,用C++创建类的方法来创建自己的QLineEdit。永远可以马上访问任何的方法,不管它是显示还是隐藏。在这里没有迷局,一切都按照你认为的简单的方式来运作。

    消息循环

    MFC是事件驱动的架构。要执行任何操作,都必须是对特定的消息作出响应。Windows对应用程序发送的

    信息数以千计,遗憾的是,要分清楚这些分繁芜杂的消息是很困难的,并且关于这方面的文档并不能很好的解决这些问题。

    Qt的消息机制是建立在SIGNAL()发送和SLOT()接受的基础上的。这个机制是对象间建立联系的核心机制。利用SIGNAL()可以传递任何的参数。他的功能非常的强大。可以直接大传递信号给SLOT(),因此可以清楚的理解要发生的事情。一个类所发送的信号的数量通常非常的小(4或者5),并且文档也非常的齐全。这让你感觉到一切尽在掌握之中。SIGNAL/SLOT机制类似于Java中listener机制,不过这种机制更加轻量级,功能更齐全。(这种机制确实貌似简单清晰了一些)

    创建界面

    MFC无法创建大小动态可变的子窗口 ,必须重新手动修改代码来改变窗口的位置(这恰好解释了为什么windows里的dialog是不可以改变的)这个问题在软件进行国际化翻译的时候更加严重,因为许多国家表达相同意思需要更长的词汇和句子,必须要对每个语言的版本重新修改自己的软件。

    在Qt中,任何东西都可以手动的敲出来,因为它很简单:为了得到一个utton,可以这样些button = new PushButton( "buttonName", MyParentName );如果想在按下某个按钮以后想调用某断代码的执行,可以这样写:connect( button, SIGNAL( clicked() ), qApp, SLOT( action() ) );Qt拥有非常简单而又不失强大的layout机制,以至于不使用它就是在浪费时间了。

    Qt还提供了一个图形用户工具,Qt Designer,可以用来帮助建立用户界面。可以修改

    所使用的任何控件的属性。不用将他们放在严格的位置,可以通过layout完美的组织他们。

    这个工具所产生的代码我们是可以实际上阅读并且可以理解的。生成的代码单独放在一个文

    件里,在编程的同时,你可以随心所欲的多次重新生成用户界面。

    Qt Designer可以让你完成许多在MFC中不可能完成的任务,比如用预先填好的生成listview,在每个tab上用不同的view来使用tab 控制。 (界面方面Qt确实很好很强大)

    帮助文档

    用户选择图形开发环境的时候,帮助文档是否周全是左右其选择的重要因素。Visual的开发环境的帮助文档MSDN(这个还要单独掏钱购买)非常的庞大,有10个CDROM光盘。他包罗万象,涵盖广泛。但是难免有泥沙俱下,主题模糊,关键信息不突出的遗憾。其链接设计的也很糟糕,通过链接很难从一个类跳转到其父类或者子类以及相关的类。如果你搜索一个关键字,不管是Visual C++, Visual J++, Visual Basic,只要包含这些关键字的信息统统的返回来。

    Qt的文档设计的相当优秀。你可以到doc.tolltech.com上面一睹芳容。Qt的文档完备且详细的覆盖了Qt的方方面面,竟然仅有18M。每一个类和方法都被详尽描述,巨细靡遗,举例充实。通过Trolltech公司提供的链接或者是Qt Assistant工具,可以方便的从一个类或者方法跳转到其他的类。文档还包含了一个初学者教程和一些典型应用的例子。同时还提供了FAQ和邮件列表,方便通过Internet或者用户群来查阅。如果你购买了授权,在一天之内你将会得到Trolltech公司的技术支持。实际上,Qt优秀的帮助文档使得寻求外部帮助的机会大大减少。Tolltech公司的一个宗旨是:有如此优秀的Qt产品以及其帮助文档,技术支持是多余的。

    (MSDN用熟了很好用,很全面,相关的背景知识,例子都能找到。而且网上还有丰富的例程可以参考。仅凭Qt的帮助文档绝对不足以解决所有问题,而网上我只找了个Qt中文论坛,提过几个问题,有的给出了解决办法,有的也没人回答,还要靠自己试)

    Unicode

    使用MFC,如果要显示unicode,在编译链接的时候必须用到特殊的参数(和改变可执行文件执行的入口),必须在每个string前面加上T,将char修改成TCHAR,每个字符串处理函数(strcpy(), strdup(), strcat()...... )都要改变成另外的函数名。更令人恼火的是支持Unicode的软件竟然不能和不支持Unicode的DLL一起工作。当使用外部DLL来开发的时候

    这是个很严重的问题,但是你毫无选择。

    使用Qt,字符串用QString来处理,其本身是与生俱来的Unicode.不需要改变什么东西。不要在编译/链接时候增添参数,不要修改代码,只需要使用QString就可以了。QSting类功能强大,你可以广泛的使用它,并且不要担心Unicode问题。这使得转换为Unicode非常的方便。QSting提供了转换为char * 和UTF8的函数。显然,MFC的CString的设计相比于Qt的QString设计有着巨大的不同。CString以char *为基础提供了很少的功能。它的优点是当需要char *类型的时候,可以直接使用CString类型。乍看起来这个好像是个优点,其实实质上还是有很大的缺陷的,特别是可以直接修改char * 而不要更新类。在转变为Unicode的时候这个也碰到很大的麻烦。(CString随编译选项可以是Unicode版)相反,QString在内部以unicode存储string,需要时提供char *功能。实际上很少用到char *,因为整个Qt的API用文本的方式响应QString参数。QString还附带许多其他的功能,比如自动分享QString的内容。这是一个非常强大的类,你会喜欢在很多地方用它

    的。

    国际化

    使用MFC是可以国际化的,但是需要将每一个字符串放在一个字符串表中,在代码中到处使用LoadString(IDENTIFIET)。然后转化这些资源到DLL中,翻译字符串到所需要的语言,改变图形界面,然后调用程序使用这个DLL。整个过程是如此的繁琐,可谓牵一发而动全身。考虑的事情要面面俱到。

    使用Qt的时候,只需要将字符串置于函数tr()中,在程序开发中这算是举手之劳。可以直接在代码中改变字符串的参考。Qt Linguist,Qt的一个工具,能够提取所有待翻译的string并按照友好的界面显示出来。这个用户界面非常适合翻译,使用字典,显示字符串内容,恰当的unicode显示,快捷方式冲突检测,检测未翻译的字符串,检测字符串修改情况,功能齐全。这个软件可以供没有任何编程经验的翻译者使用。同时该软件在GPL的版权下发布,可以按照你的需求来修改它。翻译以后的文档保存在XML中,适合软件复用的原则。为软件增加一种新的语言版本仅仅是用Qt Linguist产生一个新的文件而已。(这点Qt做的很不错。)

    resources问题

    使用MFC,一部分开发过程要依靠“resources”,在很多的案例中开发者必须使用他们。这样会导致如下的后果:出了Visual Studio,你很难使用其他的工具来完成开发。 资源编辑器仅有有限的功能,比如:通过Dialog编辑器不可能改变所有的属性,一些属性可以改变,另一些属性则不可能改变。(译者注:下面还有两条陈述MFC缺点的实例,但我感觉这些已经够说明问题了,暂时删节不译)

    然而Qt并没有资源的概念,这就解决了以上所提到的问题。Qt提供了一个脚本使得能将编入你的代码。对于界面设计,Qt Designer则创建了可读的代码。 (Qt Designer设计界面很不错)

    价格

    一旦你购买了Visual Studio,你将免费的获得MFC SDK。Qt在Unix上是可以免费获得其遵守GPL版权的版本(译者注:现在在windows 上也可以免费获得其GPL版本)。如果要开发不公开源代码的软件,必须购买Qt的授权。在特定平台下,每个开发者购买一个永久性授权,并获得一年的技术支持。(译者注:后面关于购买价格等问题删去,因为价格不固定,如果有疑问请到官方网站查询价格)

    发布

    在发布基于MFC的软件时,必须依靠存在于客户电脑上的MFC。但是这是不安全的,同样是MFC42.dll,可以基于相同的库得到3个不同的版本。通常,需要检查是否拥有正确的MFC42.dll版本,如果不是,就升级它。但是升级MFC42.dll会改变很多软件的行为。这让我感到很不舒服,如果用户在安装我的软件以后导致其机器死机该怎么办?

    Qt则没有这个风险,因为Qt压根就没有“升级整个系统”这个概念。(如果不是一个版本的Qt,还是会有问题的)

    速度


    MFC是专为Windows设计的,而Qt是跨平台的。所以MFC编写的程序的运行速度、响应时间都优于Qt.





    展开全文
  • MFC调用QT类库

    2017-10-31 18:17:55
    MFC调用QT类库,实现QMessagebox弹出提示,在MFC中动态创建QT控件!
  • MFC和QT混合编译

    2020-09-24 14:20:58
    所需文件 支持Qt5的qtwinmigrate,下载...VS新建一个MFC工程,然后卸载项目,右击编辑***.vcxproj工程文件 找到以下配置处,添加Keyword字段 Qt4VSv1.0,可以新建一个QT工程打开看看值是多少 <PropertyGroup Label.
  • 编写QT的dll,QT调用QT的dll,QT调用外部的dll,MFC程序调用QT的dll,
  • MFC和QT混合编程的问题

    千次阅读 2018-07-26 09:41:07
    最近本猿搞一个MFC和QT混合编程的东西,经常出现这样的错误: :/Program Files (x86)/Microsoft Visual Studio 14.0/VC/ATLMFC/INCLUDE/atlbase.(3210): Parse error at "__identifier" 查了一下,发现...
  • MFC调用Qt类库.zip

    2020-01-15 09:22:01
    MFC调用Qt控件MFC
  • Qt vs MFCQt和MFC的战争)

    千次阅读 2013-07-23 10:00:40
    Qt vs MFCQt和MFC的战争) 分类: 其它文章 Qt MFC 2012-01-13 10:54 428人阅读 评论(0) 收藏 举报  在网上看到的,拿来大家一起讨论下。蓝字均为转载 我曾经使用过QT和MFC来开发过软件,我想大家分享我使用...
  • 找一个懂MFC和qt的,帮我把mfc动态库转成qt动态库,然后用我一个qt程序能调用就可以了 这是一个带界面的动态库. 1
  • MFC和Qt分别使用Qt生成的Dll。 1、2017年8月3日17:56:33。 #ifndef QTDLGDLL #define QTDLGDLL #ifdef QTDLGDLL_LIBRARY //#include //# define QTDLGDLL_API Q_DECL_EXPORT #define QTDLGDLL_API __declspec...
  • MFC调用QT页面

    2015-11-16 23:44:55
    MFC 调用QT制作的界面,非常好用,值得学习。
  • Qt vs MFC (Qt和MFC的战争) 我曾经使用过QT和MFC来开发过软件,我想大家分享我使用他们时所体会的不同之处。 我并非一个职业作家,这篇文章可能看起来不如专业的杂志网站上的那么条理清晰。但是,我在...
  • VS2010 QT4.7.1 简易计算器的两种框架的实现
  • VTK三维可视化开发库,在WINDOWS7系统中,开发环境VS2010情况下,配置MFC和QT详细说明分析,实际操作总结。
  • QT调用mfc dll和qt dll

    热门讨论 2011-08-23 17:23:12
    该资源能够使用qt生成dll, 同时又mfc dll的例程,同时有使用qt调用 mfc 和qt dll的例程 。对于 学习使用qt dll很有帮助。
  • MFCQt的迁移-演练

    2020-11-11 13:55:27
    MFCQt的迁移-演练
  • 控制台、win32 、mfcQT区别

    千次阅读 2017-05-19 18:24:05
    控制台程序主要用于早期dos(disk operate system)编程。 win32 在windows95系统以前,c++还未流行起来,面向c语言(面向过程)的窗口编程。 mfc基于win32添加了c++...qt相对于mfc,有更标准的模式,相对mfc更简单。
  • Qt vs MFCQt和MFC的战争)

    千次阅读 2015-08-14 09:01:53
    关于QtMFC的话题,首选法国人Pascal Audoux所写的Impressions on MFC vs Qt Programming。当然,原文是法语,后由Philippe Fremy整理并翻译成英语。 其他站点获取 以下URL地址链接到其他站点,小木...
  • 这是一个只有几百行代码的,懂点内存方面的更好 1 1 1
  • MFC vs QT

    2012-07-06 14:57:00
    Impressions on MFC vs Qt Programming Written by Pascal Audoux Translated and improved by Philippe Fremy After putting this article on the web, it has received the following critics : It

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 16,152
精华内容 6,460
关键字:

mfc和qt区别