MFC、WTL、WPF、wxWidgets、Qt、GTK、Cocoa、VCL 各有什么特点？，有需要的朋友可以参考下。WTL都算不上什么Framework，就是利用泛型特性对Win API做了层封装，设计思路也没摆脱MFC的影响，实际上用泛型做UI Framework也只能算是一次行为艺术，这个思路下继续发展就会变得没法用了，比如 代码过于复杂，编译太慢，出错不好调试等问题难以解决。而且封装得也不完全，还是随处可见 HWND HDC之类的东西。用途主要是写一些很小的程序，或者作为其他UI框架的后端实现部分，比如我写过一个小框架用来做安装卸载程序，非常小，其中创建管理窗口部分是用WTL的。MFC是更高级点的Win API封装，比WTL封装彻底，很难见到HWND HDC了，也提供了不少实用工具类，比如高级控件，泛型容器，IO访问，网络协议等。除此之外，还提供了一些基本框架，比如 Document/View，这就是个MVC的简化版本，只有MV，但是对于数据的管理，消息的传递等又没有什么约束，导致Doc/View被用得乱七八糟。尤其是对事件处理的模型，消息映射是功能简陋，而且容易出错的方式，唯一优点是性能好。 从VC++ 1.X就有MFC了，那时整个UI界的设计思想都比较落后（除了Apple），MFC又背负了沉重的兼容性包袱，比如vc++ 1.52的MFC程序到了vc2003稍加修改都可以编译，导致MFC后期没有什么发展，就是沿着老的思路完善了些细节，添加了些组件，但是根本性的设计问题没有改进。GTK，这个吃了语言的亏，用C写面向对象实在是痛苦，虽然在思想上比MFC要先进了些，但是写出来的代码比MFC要罗嗦很多了。相比MFC，多了Layout的概念，事件处理上有了Signal/slot，虽然用起来很麻烦。wxWidgets，这个基本就是个跨平台的MFC，对各个平台的差异做了抽象，实际上后端大多还是用平台原生的API实现，好多控件都是直接用系统原生的。有wxWidgets for GTK+的版本，后端就是GTK+，wxWidgets就是一层壳。这也是wxWidgets的优点，它编译出来的程序发行包比较小，性能也不错。以上这些就是上世纪90年代的UI Framework技术水平了，至今它们也依然没有太多进步。下面来谈谈21世纪的技术。Qt，虽然它也是上世纪90年代出现的，但是它在21世纪有了长足的进步。应该说它的起点就比较高，一开始就定位跨平台，而且不满足于简单封装系统API，而是要自己创造出一套完整的API和框架，甚至要代替系统API，所以不仅仅是做UI，而是涉及到了APP开发所用到的所有东西，包括网络，数据库，多媒体，脚本引擎等。signal/slot是Qt发明的，这是事件通知模型里C++语言的最佳实现了，甚至我都觉得这该写进C++标准，估计C++委员会的老顽固们是从不写GUI的。早期的QT也是没有DirectUI的概念的，每一个QWidget都对应一个原生窗口，从Qt4.4开始，只有顶层QWidget才是原生窗口，而Child Widget是Alien Widget，只是个抽象的图层不对应原生窗口，这就实现了DirectUI的概念，很多图形效果也就变得可能了，比如窗口层叠透明效果。在4.8后实现了QPA(Qt Platform Abstraction)，这就使移植Qt变得很容易，目前Qt是支持平台最多的框架没有之一。由于早期授权的问题，Qt对于开源社区不是很友好，导致推广不太顺利，直到它改成了LGPL方式，如果Qt能早点想开了，恐怕就没有wxWidgets的生存空间了。Qt的缺点也是有的，就是太大，不过可以自己剪裁，我可以把QT库剪裁到发行包压缩后2.5MB。WPF，微软在Win Form的思路上走到死胡同后，终于痛下决心用正确的方法开发UI库了。21世纪的UI一定是定义出来的，绝对不能是代码写出来的，所以有了XAML这个强大的定义工具，不但可以定义UI布局，还包括图形动画效果，消息响应方式等。配合C#这种优秀的语言，更是如虎添翼。但是问题也很明显，就是过于庞大，不仅开发时要用到庞大的IDE和设计工具，发行的安装包也十分巨大，所以目前还是很少有人拿他写通用软件客户端的，大多是做企业项目时写专用客户端。大概4-5年前吧疼讯曾经用WPF写了个QQ，但是只实现了基本功能就已经比C++客户端大好多了，而且运行缓慢，主要是太吃内存，而且那时WPF的优化还不充分。最后我想补充下真正的UI库之王，cocoa。Apple的成功有很多原因，其中之一就是cocoa，cocoa理念十分先进，而且出来得早，我都怀疑Qt和WPF有不少思想都是借鉴cocoa的。定义式的UI，用xib就可以定义UI的绝大部分细节，而且提供所见即所得的可视化设计工具。严格的MVC，而且定义非常清晰，分工明确。signal/slot，虽然不叫这个名字，但思想就是，而且真的是拖动鼠标就能connect。提供了ARC，闭包和反射，给UI开发带来巨大的便利性，当然这得益于Objective-C这个语言。再补充下 Borland的OWL和VCL。我是从Borland C++3.0和Delphi 1.0开始用的，那时的Borland看来很有前途的，可惜后来一系列决策失误导致现在这个公司几乎消失了，同学们不要再往这个坑里跳了。OWL曾经和MFC是竞争对手，设计思想也差不多，个人感觉OWL的API设计更优雅一点，但是在市场上OWL被MFC彻底击败。Delphi是神作，它在RAD（快速应用开发）领域长时间没有对手，直到BS架构取代CS架构。Delphi的特点就是简单、开发快，单纯就写个基本可用的应用来说，可能至今都没有比他更快的，但是缺点就是丑，基本大多数Delphi应用都是一大堆控件堆积在一起，很不美观，另外由于Pascal语言的限制无法和现有大量的C/C++代码融合。虽然后来有C++ Builder，但是Builder里简单和快的优点也消失了。Borland的C++编译器越做越差，导致后来开源项目都不太愿意兼容这个编译器了。VCL准确地说不是UI库，而是一套组件接口规范，类似COM ActiveX。delphi和C++builder都是基于这个规范构建了基础库。UI库是个很大的话题，够写好几本书来探讨的，我这里就是随便写点自己的感受。单纯讨论每个库的优劣是没有意义的，而是要放到具体的应用场景里来看，每个库都有自己擅长的场景。如果仅在Windows下，追求程序小巧，用WTL，不足的地方自己实现去吧，但是视觉效果就呵呵了。如果可以大一点，还要好看点，那就Qt。如果完全不在乎大小，只要视觉效果华丽，就用WPF，如果把开发工具价格也考虑进来，那么土豪才会选WPF呢。MFC就是个鸡肋了，除非你现有的工程师不会用别的，或者有历史遗留代码要保持兼容。如果要求跨平台，那么就用Qt，wxWidgets和GTK+跟现在的Qt比起来没有什么优势了。如果是iOS Android，那么最好用原生UI库，除非你写游戏。参考：/question/2348001
最新教程周点击榜
微信扫一扫[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？_wtl-牛宝宝文章网
[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？ wtl
[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？或者你还知道什么别的好用的图形界面库也可以来谈谈特点。但是，本问题禁止某人推销自己的图形界面库。下面就看看www.niubb.net小编为您搜集整理的参考答案吧。网友姚冬对[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？给出的答复：谢邀（终于用上这个高大上的词汇了，真的有点小激动呢）WTL都算不上什么Framework，就是利用泛型特性对Win API做了层封装，设计思路也没摆脱MFC的影响，实际上用泛型做UI Framework也只能算是一次行为艺术，这个思路下继续发展就会变得没法用了，比如 代码过于复杂，编译太慢，出错不好调试等问题难以解决。而且封装得也不完全，还是随处可见 HWND HDC之类的东西。用途主要是写一些很小的程序，或者作为其他UI框架的后端实现部分，比如我写过一个小框架用来做安装卸载程序，非常小，其中创建管理窗口部分是用WTL的。MFC是更高级点的Win API封装，比WTL封装彻底，很难见到HWND HDC了，也提供了不少实用工具类，比如高级控件，泛型容器，IO访问，网络协议等。除此之外，还提供了一些基本框架，比如 Document/View，这就是个MVC的简化版本，只有MV，但是对于数据的管理，消息的传递等又没有什么约束，导致Doc/View被用得乱七八糟。尤其是对事件处理的模型，消息映射是功能简陋，而且容易出错的方式，唯一优点是性能好。 从VC++ 1.X就有MFC了，那时整个UI界的设计思想都比较落后（除了Apple），MFC又背负了沉重的兼容性包袱，比如vc++ 1.52的MFC程序到了vc2003稍加修改都可以编译，导致MFC后期没有什么发展，就是沿着老的思路完善了些细节，添加了些组件，但是根本性的设计问题没有改进。GTK，这个吃了语言的亏，用C写面向对象实在是痛苦，虽然在思想上比MFC要先进了些，但是写出来的代码比MFC要罗嗦很多了。相比MFC，多了Layout的概念，事件处理上有了Signal/slot，虽然用起来很麻烦。wxWidgets，这个基本就是个跨平台的MFC，对各个平台的差异做了抽象，实际上后端大多还是用平台原生的API实现，好多控件都是直接用系统原生的。有wxWidgets for GTK+的版本，后端就是GTK+，wxWidgets就是一层壳。这也是wxWidgets的优点，它编译出来的程序发行包比较小，性能也不错。以上这些就是上世纪90年代的UI Framework技术水平了，至今它们也依然没有太多进步。下面来谈谈21世纪的技术。Qt，虽然它也是上世纪90年代出现的，但是它在21世纪有了长足的进步。应该说它的起点就比较高，一开始就定位跨平台，而且不满足于简单封装系统API，而是要自己创造出一套完整的API和框架，甚至要代替系统API，所以不仅仅是做UI，而是涉及到了APP开发所用到的所有东西，包括网络，数据库，多媒体，脚本引擎等。signal/slot是Qt发明的，这是事件通知模型里C++语言的最佳实现了，甚至我都觉得这该写进C++标准，估计C++委员会的老顽固们是从不写GUI的。早期的QT也是没有DirectUI的概念的，每一个QWidget都对应一个原生窗口，从Qt4.4开始，只有顶层QWidget才是原生窗口，而Child Widget是Alien Widget，只是个抽象的图层不对应原生窗口，这就实现了DirectUI的概念，很多图形效果也就变得可能了，比如窗口层叠透明效果。在4.8后实现了QPA(Qt Platform Abstraction)，这就使移植Qt变得很容易，目前Qt是支持平台最多的框架没有之一。由于早期授权的问题，Qt对于开源社区不是很友好，导致推广不太顺利，直到它改成了LGPL方式，如果Qt能早点想开了，恐怕就没有wxWidgets的生存空间了。Qt的缺点也是有的，就是太大，不过可以自己剪裁，我可以把QT库剪裁到发行包压缩后2.5MB。WPF，微软在Win Form的思路上走到死胡同后，终于痛下决心用正确的方法开发UI库了。21世纪的UI一定是定义出来的，绝对不能是代码写出来的，所以有了XAML这个强大的定义工具，不但可以定义UI布局，还包括图形动画效果，消息响应方式等。配合C#这种优秀的语言，更是如虎添翼。但是问题也很明显，就是过于庞大，不仅开发时要用到庞大的IDE和设计工具，发行的安装包也十分巨大，所以目前还是很少有人拿他写通用软件客户端的，大多是做企业项目时写专用客户端。大概4-5年前吧疼讯曾经用WPF写了个QQ，但是只实现了基本功能就已经比C++客户端大好多了，而且运行缓慢，主要是太吃内存，而且那时WPF的优化还不充分。最后我想补充下真正的UI库之王，cocoa。Apple的成功有很多原因，其中之一就是cocoa，cocoa理念十分先进，而且出来得早，我都怀疑Qt和WPF有不少思想都是借鉴cocoa的。定义式的UI，用xib就可以定义UI的绝大部分细节，而且提供所见即所得的可视化设计工具。严格的MVC，而且定义非常清晰，分工明确。signal/slot，虽然不叫这个名字，但思想就是，而且真的是拖动鼠标就能connect。提供了ARC，闭包和反射，给UI开发带来巨大的便利性，当然这得益于Objective-C这个语言。再补充下 Borland的OWL和VCL。我是从Borland C++3.0和Delphi 1.0开始用的，那时的Borland看来很有前途的，可惜后来一系列决策失误导致现在这个公司几乎消失了，同学们不要再往这个坑里跳了。OWL曾经和MFC是竞争对手，设计思想也差不多，个人感觉OWL的API设计更优雅一点，但是在市场上OWL被MFC彻底击败。Delphi是神作，它在RAD（快速应用开发）领域长时间没有对手，直到BS架构取代CS架构。Delphi的特点就是简单、开发快，单纯就写个基本可用的应用来说，可能至今都没有比他更快的，但是缺点就是丑，基本大多数Delphi应用都是一大堆控件堆积在一起，很不美观，另外由于Pascal语言的限制无法和现有大量的C/C++代码融合。虽然后来有C++ Builder，但是Builder里简单和快的优点也消失了。Borland的C++编译器越做越差，导致后来开源项目都不太愿意兼容这个编译器了。VCL准确地说不是UI库，而是一套组件接口规范，类似COM ActiveX。delphi和C++builder都是基于这个规范构建了基础库。UI库是个很大的话题，够写好几本书来探讨的，我这里就是随便写点自己的感受。单纯讨论每个库的优劣是没有意义的，而是要放到具体的应用场景里来看，每个库都有自己擅长的场景。如果仅在Windows下，追求程序小巧，用WTL，不足的地方自己实现去吧，但是视觉效果就呵呵了。如果可以大一点，还要好看点，那就Qt。如果完全不在乎大小，只要视觉效果华丽，就用WPF，如果把开发工具价格也考虑进来，那么土豪才会选WPF呢。MFC就是个鸡肋了，除非你现有的工程师不会用别的，或者有历史遗留代码要保持兼容。如果要求跨平台，那么就用Qt，wxWidgets和GTK+跟现在的Qt比起来没有什么优势了。如果是iOS Android，那么最好用原生UI库，除非你写游戏。网友林建入对[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？给出的答复：各个框架的特点 @姚冬 先生已经说的非常清楚了。我补充一点自己的体会，也供大家参考。08 年的时候，我刚听说微软出了 WPF，非常兴奋。那时候的我写的最多的是 WinForms 的应用程序，但我对 WinForms 程序有诸多不满，主要原因是 WinForms 的设计仅仅是对系统的 Win32 API 做了一层薄薄的封装，UI 设计方面束缚依然比较大――老老实实套用内置控件倒还好，一旦要做些许“创新”，开发复杂度就陡然增大。于是当年我就赶紧买下了 Charles Petzold 老爷子写的《Windows Presentation Foundation 程序设计指南》，如获至宝的学起来。这期间逐渐感受到 WPF 的强大，灵活，并憧憬着用它开发出更加酷炫的应用程序。然而现实是残酷的，一个棘手的问题是 WPF 性能比预期差很多。当你为一个控件添加下拉阴影特效(DropShadowEffect)后，再让其参与到动画事件中，性能会急剧下降。起先我以为是我使用方法不正确，但最终发现这是一个普遍问题。归根结底，DropShadowEffect 在当时是用 CPU 完成计算的，当存在动画时，为了保证渲染正确，需要逐帧重新计算，导致 CPU 占用率暴涨，性能自然受到拖累。尽管我们可以尝试一些“优化”手段，例如预先计算出一次 DropShadowEffect 后将其缓存，后续仅以位图方式重绘，这一方案自然能快很多，却也存在这样或那样的弊端，例如需要考虑缓存结果是否能与背景正确匹配的问题。另一种办法，我们还可以在纯色背景上预先计算出 DropShadowEffect 后，再将半透明化，这样既能保证性能，又能保证与背景正确匹配。但还是略有瑕疵。总之方法虽多，但需要具体情况具体设计，非常不方便。说到底这个问题还是应当由微软解决，而不是推给框架的使用者。作为 UI 框架新贵，WPF 存在些许缺陷不足为奇。但有趣的是，下拉阴影导致性能下降的问题在同期的浏览器（如 Firefox）中却并不存在，你可以为任何元素添加下拉阴影，然后让它们动起来，浏览器依然顺畅如初。这一个细节让当年轻视 Web 开发的我逐渐的意识到，浏览器作为一个渲染引擎，其性能经过了精心的优化，是一个优秀的 UI 容器。受此启发，在近两三年里，我便很少再用 WPF 开发了。后续的项目都采用基于内嵌浏览器内核（例如XULRunner、CEF）的方式。这样一来 UI 都用 Web 来做，就拥有极大的灵活性，例如可以使用 ExtJS、Bootstrap、Semantic UI 框架等等，而应用程序的能力则依然是 Native 的，可以完成任何之前的程序所能做到的事（调用 Win32 API？很容易）我们交付的许多项目都是这样实现的。开发成本大大下降，而且跨平台也不再是问题。关键是可以享受到 Web 开发后续发展的所有红利，例如模板引擎，响应式界面，React UI 等等。近来，node.js 的出现也再一次降低了这方面的开发成本，特别是 node-webkit (近来改名为 nw.js)之类的程序，更是将这方面的开发门槛急剧降低――之前你如果不熟悉底层开发，你可能就不知道应当如何将 CEF 之类的控件嵌入到你的程序界面里，另外还需要解决 Web 界面与底层库的通信问题。但是使用 node-webkit 根本无需考虑这方面的问题。对于需要调用底层 API 的时候，直接给 node.js 增加 C++ Addon，在界面里就可以通过 JavaScript 调用。非常方便快捷。而且还有大量的 package 可用。不能更强了。但是底层开发人员在向 Web 技术拓展的时候，常常遇到的最大的问题是在于固有思维定势带来的偏见。其中最常见的问题就是，觉得 Web 很糟糕，没有 Control 的概念，缺乏封装。因此用起来总觉得不好用。起初我也是这样认为的，但后来我发现并非如此。这其实是一个设计理念的差异。慢慢会发现各有利弊。Web 基于 Document 的设计也有颇多精彩之处。总而言之，我总希望大家在传统 Native 框架的基础上，多试试基于 Web 的方案。你一定会因此变得更加强大，并找到更多乐趣的。（关于 WPF 现在我了解的已经很少了，如果有错误，还请谅解）网友白小澜对[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？给出的答复：how does Cocoa compare to Microsoft, Qt?你可以看一下。。。。。。网友王斌对[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？给出的答复：谢邀（终于我也高大上一次了，好激动）本来一肚子话想说，不过发现大部分被姚东说完了，瞬间感觉没有动力了????那我推荐下别的库曾经10年的时候我收集了二十多款界面库（包括各种duilib的改进版）但目前来看，windows上还没出现一款满足：1、轻量（大小在3m以内）2、开源3、控件丰富（包括最难的richedit）4、申明式编程5、动画功能丰富、性能卓越6、支持多平台，比如xp的界面库。不过暂时来看，迅雷的bolt是最接近这个目标的库了。这里我要感谢下迅雷的刘智聪，在09年的时候就提出很多到目前来看来基本是标配的概念：基于原子对象、强制使用脚本、申明式编程（雏形）。bolt最牛逼的是还带了个强大的richedit，这个控件算是所有控件里最复杂最麻烦的东西了。去掉这一点，其实还是挺多库都不错的。但bolt最大的问题还是不开源。这样带来最大的问题是大家开发的时候，碰到不懂的问题无法调试，也无法通过查看代码来了解并解决问题。另外还想推荐下一个库：htmlayout。这玩意基本实现了个浏览器，所以功能上确实无比强大，而且关键是非常轻巧，压缩完才900多K。但这库的问题一是不开源，二是他的脚本是个自己搞的山寨脚本，学习成本稍微有点大。其他真算的上是精巧牛逼了。（库代码其实是可以买的，而且也不贵，才600美元，我就买过，哈哈）轮子哥的库听说很牛逼，不过现在还没时间看未完待续??????网友蒙面大侠对[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？给出的答复：http://nanapro.orgnana，轻量级的boost风格跨平台GUI库，作者还提交给了C++委员会，还申请加入boost中，可以看作是现代化的fltk吧？我想这货应该是最适合配合boost+STL用的C++ GUI库了。作者看名字可能是华人，但是不知道为什么中文圈好像都不知道这个库。网友蒙面大侠对[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？给出的答复：MFC乃曾经的老大，现在来看设计有点落后；原本可以做得更好用，但MS为了推COM而变得臃肿，而现在MS为了推.net更不愿意继续发展它。WTL基于ATL，ATL是COM组件的模版库，COM是C++应用中的毒瘤（明知有人会喷我，我依然坚持真理）; WTL曾受MS打压，因为MS怕它的轻巧特性会妨碍推广.Net，现在不需要打压了，因为已经扶不上墙了。WPF：不是给C++用的。wxWidgets：小巧、小众、多bug；和MFC差不多，这是优点，也是死穴。Qt：库有点庞大，啥都有，信号和槽机制需要特殊的编译器搞；没能尽量复用C++已有的库，看重复的东西会人特别烦。（我个人最看好Qt）。GTK：两个字“难用”。网友匿名用户对[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？给出的答复：使用过mfc，wtl，qt，学习过一个星期的gtk, 一个星期的wpf，然后一直在学习html, javascript,css。mfc框架设计理念比较老旧，效率高，框架中各种hacker手段用的比较多，太过重量级(其实也没qt那么重量级，但设计理念陈旧的原因，给人一种为什么会这么复杂)。wtl 比较轻量，但功能比较弱，封装太薄，实际开发的时候，大量借助api。gtk学了一个星期，写起来太麻烦了，没学下去。wpf理念十分先进，声明式占主导，配合vs十分强大，但我个人比较功利，因为html使用范围更广，所以放弃了wpf。qt 现在已经进化成qt5了，不断吸收各种优秀理念，比如qt4以前的signal/slot基于字符串，连接信号和槽的时候，又掠秩菀仔创恚嘁氲氖焙蛞布觳椴怀隼矗qt5改成了直连两个函数，参数之类的不用写了，并且如果参数不匹配，编译的时候都会自动检查出来。qt3到qt4的变化，让更多的api接口更加清晰易懂，qt4中也与时俱进，增加了相当了css的qss，当然其功能还没有达到html中css的功能那么高级，象float，animation之类的qss还是做不到的。另外qt也与时俱进的给出了和html类似的qt quick，断断续续看了大概1个月，虽然很好，但因为不是标准，感觉没法和html竞争。html, javascript, css 是个国际标准，开发gui很方便，配合python的一些template开发包，能十分方便的生成一套美观的gui，修改起来也十分方便，当然并不是没有缺点，提供的功能对一个完整的软件产品来说是不够的，比如，真正的浮动窗口，可定制化的视频播放，摄像头功能，交互性强的作图(photoshop, cad之类的)等，这些东西不得不借助插件来完成。 另说一下，在qt quick中这些都不是问题。我比较倾向使用qtwebkit来嵌套html，并且qtwebkit制作插件也是非常容易的，有了插件，html中的那些缺点就不是问题了，但带来另一个缺点，就是qtwebkit太大了，优点是qtwebkit也是跨平台的。如果太大不能忍，那就只能为每个浏览器分别制作插件了。最后，想说一下，以后gui方面，我个人感觉命令式占主导的语言应该是会过时的，声明式占主导的语言应该会大行其道。网友陈厚来对[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？给出的答复：我想要这样的库 --1. 小2. 跨平台3. 平台原生界面4. 有丰富控件5. 描述实现GUI、非代码实现GUI总之一句话，就是 -- 没有网友HeliosM对[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？给出的答复：既然只禁止推销自己的那我帮轮子哥@vczh推销一下他的GacLib.net（逃……网友匿名用户对[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？给出的答复：MFC：老；WTL：小而快；wxWidgets：跨平台；Qt：庞大驳杂；GTK：Linux。网友黄勇对[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？给出的答复：mfc win32 native的不二选择。wtl activex 的不二选择。wx 玩玩就好，最好不选择QT 跨平台的不二选择。gtk 开源gui的不二选择。wpf 二的选择。网友蒙面大侠对[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？给出的答复：只用过MFC，之前看到的一个图网友San Cheung对[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？给出的答复：补充一下 @姚冬的答案：MFC，符合微软一贯的风格，大、稳定、丑陋、好用。WTL是微软开发人员自制的库，后来发布出来，就是Window SDK上面套了一层泛型。Qt发展到现在，其实已经是2套东西，一个是传统的Qt Widget，每个控件都是windows的模式，类似于MFC/WTL。另一个是Qt Quick，使用逻辑控件来描述的一个界面库，UI主题是QML（Json+JavaScript），Windowless、MVC、动画一应俱全。缺点发布包太大，动不动就几十M，坑实在太多；Qt Creator用上去实在不太像话；不算系出名门----东家诺基亚不太靠谱。网友匿名用户对[wtl]MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？给出的答复：@vczh欢迎您转载分享：
更多精彩：学C++开发windows图形界面程序是不是要学mfc?_c++吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：271,267贴子：
学C++开发windows图形界面程序是不是要学mfc?收藏
如题，用C++开发图形界面程序win的，是不是要学MFC大家给个建议。
防止二次污染，含汞废物处置就找铜仁银湖化工
表示我windows程序设计还没看完。。。看完之后我决定先看windows核心编程，然后mfc，然后从mfc，Qt，wtl，wxWidgets，GTK+中选择一种作为主要开发库。有时间的话再自己封装个GUI库
本人已知c++有两个图形界面编程，一个就是mfc，另一个是CLR(应该是，反正就是编form啥的，需要.net封装)要编个大部分windows都能用的就只能用mfc，想搞牛逼的.net程序倒不如去学c#
个人觉的Qt更简单
。。。。。。。。。。。。。。不学SDK先去学MFC会莫名其妙的
qt大法好 天灭mfc！
登录百度帐号推荐应用
为兴趣而生，贴吧更懂你。或}