都说MFC开发界面bug多不美观很累人！QT开发界面效果绚！且速度快！QT超越了MFC

Posted 2023-04-13

Flash Builder 4.0开发
1：效果超级绚丽！
2：开发周期超级块！
3：编码也超快！
4：尤其结合了Flash那个牛！
为何用的人不如QT MFC的人多呢！（假如抛开跨平台考虑）是不是用Flash Builder 4.0开发的人就要激增了呢？

请各位开发过多年的比较比较这三个IDE开发软件！

问题2：
我C++也是非常的好！又MFC入了门！看着QT这阵子火！非常喜欢QTC++的风格！所以准备学QT！可我flash很好！刚好赶上ADOBE的 Flash Builder4.0有出现了！所以我想挑三个中的一个好好深入！请各位指点！
但我的直觉觉得Flash Builder 4.0比以上二者更好！
因为Flash 做界面1：效果超级绚丽！
Flash Builder
2：开发周期超级块！
3：编码也超快！
4：尤其结合了Flash那个牛！
！（抛开跨平台考虑）
为什么使用Flash Builder 开发的人不如QT MFC的人多呢
为什么不选择Flash Builder 4.0来开发呢？
请各位做做比较！看看我说的是否在理！

没用过flash builder 所以这个就不评价了

就界面方面，QT比MFC有以下几个优点
1，signal and slot机制，这个比MFC的消息机制更加的灵活和使用方便。
2，布局管理，有了布局管理，是你不要关注你的界面的摆放位置，程序可以自动生成让你看的最舒服的界面。
3，功能齐全的类库，这点比MFC好很多。QT提供的功能基本可以满足你90%的功能，10%的特殊功能，你需要自己去子类化。

但是MFC也有他的优点。这个你懂的 参考技术A 你说的那个是Adobe的flex吧？那个是开发桌面应用的，不是开发应用软件的，而且很多功能都需要在线的。和mfc/qt不好对比的。
我用mfc都六年了，感觉它是一款比较经典的开发工具，主要是它上可以开发上位机程序，下可以开发驱动、sdk程序，这个vs编译环境确实是很优秀的。
但是我也准备放弃继续使用MFC了，为什么？因为微软不开源--就这么简单。
我自己画一周时间才能写好一个控件，比如一个cedit，希望能够排版、字体、颜色与父窗口完全孤立，因为你知道很多所谓的自定义控件，并不是完全和父窗口属性分离的，最简单的：在父窗口中定义OnCtlColor，子窗口的属性就改变了。花了一周时间，最后发现还有一个很关键的接口是kernal32.dll中，这怎么弄呀？没有源代码哈！很多时候都是这样的。有一些关键性的接口微软不留给你用，也不公开。这样会让人用起来十分不便。想想看，MFC都诞生10多年了吧，就算专利也过了时效期了，不开源只会让更多的mfc开发者最终放弃这个曾经经典辉煌的编译环境。 参考技术B Flash 我个人没有深入了解太多，但是他的程序的量级肯定无法和用MFC或则QT编写的量级相比。

特别是一些大型应用程序，效率和稳定性是关键。flash builder我估计主要是满足快速开发和规模相对较小的应用程序实现较好的界面亲和力的轻量级应用吧。 参考技术C QT:可以跨平台、美观、开发嵌入式及智能移动设备功能强大
MFC:主要用于Windows操作系统，是一个类库。
Flash:与上面两个东东好像没有可比性吧，不是同一类东西
呵呵 参考技术D 但我的直觉觉得Flash Builder 4.0比以上二者更好！
因为Flash 做界面1：效果超级绚丽！
Flash Builder
2：开发周期超级块！
3：编码也超快！
4：尤其结合了Flash那个牛！
！（抛开跨平台考虑）
为什么使用Flash Builder 开发的人不如QT MFC的人多呢
为什么不选择Flash Builder 4.0来开发呢？
请各位做做比较！看看我说的是否在理！

MFC和QT的区别

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

Qt这个C++的图形库由Trolltech在1994年左右开发。它可以运行在Windows,Mac OS X, Unix，还有像Sharp Zaurus这类嵌入式系统中。Qt是完全面向对象的。

 

Document/View model:
MFC编程需要使用Document/View模式以及模板(template),如果不使用的话，编程将变得异常困难。而且，模板(template)设定了固定的结构，若所需结构乃模板未定义之结构，则编程难已。例如，划分一区域使显示两个视图(view)于两个文档(document)。还有一个经常的问题是：模板(template)创建了视图(view)却无法访问(access)它，文档（document）要做完所有事情，但是这经常会出现问题。

Document/View模式：

类CDocument主要用来存储数据；类CView绑定到CDocument并根据CDocument中的数据来显示出画面或用来处理与用户的交互来操作CDocument中的数据。Document/View结构的主要好处是一个Document支持多Views，假设你的程序可以让用户以表格的形式看到数据，也可以以图形的形式看到数据，即数据有多种表现形式，并且当数据改变时，表格和图表形式都同时改变。在MFC中，表格视图和图形视图可以是CView派生出来的不同的类，这些类可以只关联上一个Document对象。Document对象保存数据，这些视图访问Document对象并显示出从Document对象获得的数据。

当用户更新这些视图中的一个时，调用CDocument::UpdateAllViews函数，将会通知这个Document关联的所有视图，这些视图将会用CDocument最新的数据来更新自己。

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充满了丈二和尚摸不着头脑的事情，并且，这种错误很难调试。

Qt恰恰相反，它的架构明显是经过精心设计的面向对象的。Qt因此在命名，继承，类的组织等方面保持了优秀的一致性。你只需要提供唯一一个方法的参数，仅此一个。在不同的类中调用方式也是有很强的连贯性。返回值也很有逻辑性。所有一切达到了简单和强大的和谐统一。一旦你使用了其中一个类，其他的类也就触类旁通，因为他们是一致的。

在Qt中可以利用Edit控件，用C++创建类的方法来创建自己的QLineEdit。永远可以马上访问任何的方法，不管它是显示还是隐藏。在这里没有迷局，一切都按照你认为的简单的方式来运作。

 

消息循环: 
MFC是事件驱动的架构。要执行任何操作，都必须是对特定的消息作出响应。Windows对应用程序发送的信息数以千计，遗憾的是，要分清楚这些分繁芜杂的消息是很困难的，并且关于这方面的文档并不能很好的解决这些问题。

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

signal/slot是Qt对象以及其派生类对象之间的一种高效通信接口，它是Qt的核心特性，也是区别与其他工具包的重要地方。它完全独立于标准的C/C++语言，因此用正确的处理好信号和槽，必须借助于一个成为MOC（Meta Object Compiler）的qt工具，该工具是一个C++预处理程序，能为高层次的事件处理自动生成所需要的附加代码。Signal 代码会由 moc 自动生成，开发人员一定不能在自己的C++代码中实现它，并且，它永远都不能有返回值。Slot其实就是一个普通的类函数，并且可以被直接调用，唯一特殊的地方是它可以与signal相链接。

1.信号的定义：

siganls：

void mySignal();

void mySignal( int x );

void mySignal( int x, int y );

其中signals是Qt的关键字，而不是C/C++的关键字。此外信号与一般函数的区别是，它的所有返回值都是void,并且它没有函数实现体，它的函数体是moc自动生成的。

2.槽的定义：

public slots:

void mySlot();

void mySlot( int x );

不同类型的slot有不同的操作权限，具体看slot是public、protected还是private。

3.信号与信号或者与槽的连接：

QObeject::connect( obj1, SIGNAL( mySignal() ), obj2, SLOT( mySlot() )  );

QObeject::connect( obj1, SIGNAL( mySignal() ), obj2, SIGNAL( mySignal2() )  );

4.信号与槽的断开：

QObeject::disconnect( obj1, SIGNAL( mySignal() ), obj2, SLOT( mySlot() )  );

QObeject::disconnect( obj1, SIGNAL( mySignal() ), obj2, SIGNAL( mySignal2() )  );

这种机制GUI控件的操作来说很是方便，当然也要用的恰当，用的规范和科学。

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

在Qt中，任何东西都可以手动的敲出来，因为它很简单：为了得到一个button，可以这样些

button = new PushButton( "buttonName", MyParentName );

如果想在按下某个按钮以后想调用某断代码的执行，可以这样写：

connect( button, SIGNAL( clicked() ), qApp, SLOT( action() ) );

Qt拥有非常简单而又不失强大的layout机制，以至于不使用它就是在浪费时间了。

Qt还提供了一个图形用户工具，Qt Designer，（先安装qt creater），可以用来帮助建立用户界面。可以修改所使用的任何控件的属性。不用将他们放在严格的位置，可以通过layout完美的组织他们。这个工具所产生的代码我们是可以实际上阅读并且可以理解的。生成的代码单独放在一个文件里，在编程的同时，你可以随心所欲的多次重新生成用户界面。

Qt Designer可以让你完成许多在MFC中不可能完成的任务，比如用预先填好的生成listview，在每个tab上用不同的view来使用tab 控制。

 

帮助文档:
用户选择图形开发环境的时候，帮助文档是否周全是左右其选择的重要因素。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产品以及其帮助文档，技术支持是多余的。

 

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的时候这个也碰到很大的麻烦。

相反，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产生一个新的文件而已。

 

resources问题: 
使用MFC，一部分开发过程要依靠“resources”,在很多的案例中开发者必须使用他们。这样会导致如下的后果：

出了Visual Studio，你很难使用其他的工具来完成开发。 
资源编辑器仅有有限的功能，比如：通过Dialog编辑器不可能改变所有的属性，一些属性可以改变，另一些属性则不可能改变。(译者注：下面还有两条陈述MFC缺点的实例，但我感觉这些已经够说明问题了，暂时删节不译) 
然而Qt并没有资源的概念，这就解决了以上所提到的问题。Qt提供了一个脚本使得能将编入你的代码。对于界面设计，Qt Designer则创建了可读的代码。

 

价格:
一旦你购买了Visual Studio，你将免费的获得MFC SDK（Software Development Kit，软件开发工具包）。

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

 

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

Qt则没有这个风险，因为Qt压根就没有“升级整个系统”这个概念。