不要被这个标题唬住了，实际上我是非常认可Qt的。在C++实现的开源产品中没有哪一个的API风格比得上Qt，拥有高度一致性，符合常识，符合直觉，几乎不用学就可以直接上手。或许是由于我们摆脱不了马太效应的控制，赞誉已经给到了Qt的缺陷。Qt的最大问题就是提供了uic和moc。界面设计器生成xml文件，需要uic编译它生成C++代码；组织界面的C++代码其实一点都不复杂，完全可以由界面设计器直接生成。可以给Qt找到需要uic的理由——实现了分工，可以并行，为设计器开发团队屏蔽了C++语法的复杂性。然而，uic相对于界面设计器来说，工作量几乎可以忽略不记，在管理实践上如此不平衡的分工没有任何意义，并行也就说不过去了。组织界面的C++代码完全掌控在Qt团队手里，完全可以用最简单的方式实现（uic生成的c++代码也确实非常简单），这样一来也没有什么“C++语法的复杂性”需要屏蔽了。如果uic对用户来说没有坏处，仅仅给Qt团队增加了工作量，也就无可非议了。但是，uic集成到第三方开发工具中时，导致设计器创建的界面，不能及时生成为C++代码，必须手动执行一下uic。
uic跟moc比起来，就是小巫见大巫了。提供moc的原因，很大一部分是因为信号和槽机制。每每听到有人带着无比崇敬的态度布道Qt的信号和槽机制，真希望他们能知道信号和槽到底为了什么而存在。还是先来看一段Qt的代码吧。
class QDataSourceWidget : public QTreeView { Q_OBJECT public: explicit QDataSourceWidget(QWidget *parent = 0); ~QDataSourceWidget(); signals: void LayerAdded(IMapPtr, ILayerPtr, ILayerProviderPtr); protected: virtual void LayerAddEvent(IMapPtr map, ILayerPtr layer, ILayerProviderPtr provider) { emit LayerAdded(map,layer,layerProvider); } private slots: void NodeDoubleClicked(const QModelIndex &index) { ... LayerAddEvent(map,layer,provider); } };