我知道有很多Qt和MFC问题,但我会尝试非常具体.
我们有一个很大的(10年的开发)C++ MFC应用程序的利基行业.它应该永远只保留Windows和英语.但是我们需要添加一堆新的设计器绘制的GUI和GUI控件(对话框,按钮,自定义列表......).
我们可以雇用1或2个新的GUI开发人员来构建这些新接口,因此我们可以选择与MFC不同的技术.
Qt似乎最有希望并且适合与MFC并排运行(哦,不,我们不是从头开始减少应用程序).
似乎大多数引用的Qt优势都是无关紧要的:跨平台开发,易于国际化,开源,非GUI库(我们不需要网络,并且已经实现了大部分其他功能).
但Qt也因其良好的OO设计而闻名,他们最近推出了QtQuick.我想给它一个机会,所以问题是
可能不会。
如果 gui 和业务逻辑很好地分离，那么将 gui 逐渐转移到 Qt 或在 Qt 中实现新部分可能是有意义的 - 但我们都知道 gui/逻辑将是一个可怕的混合在一起的混乱
如果您正在进行重写（这就是 Qt 最终的结果），那么如果它是常规业务类型应用程序，那么使用 C#/.net 可能会更容易。
如果性能至关重要，并且您拥有大量与定义明确、分离的 C++ 库相关的领域知识，那么 Qt 前端将是值得的