|
原帖由 mash 于 12-12-2009 22:33 发表
QT: 已经不能算GUI库了。应该算是一个夸平台应用开发平台了。GUI,Filesystem, Network, 2D, 3D, plugins, MutiMedia...基本什么都包含了。
QT仍然是以GUI为核心的,或者广义来说是Client Framework. 虽然QT也有Console Framework,但是无论Trolltech和Nokia都明确表示QT始终关注在客户端,不会再Server Side投入过多精力。
[quote]
优势:文档丰富,API设计优雅,尤其对于Java编程人员。编译的代码尽量靠近本地API。
劣势:代码效率不高,这和设计有关,for Desktop development.
现在的QT对移动平台的关注远远大于桌面开发了, see http://qt.nokia.com 和 http://qt.nokia.com/developer/qt-roadmap. 几乎所有正在开发的new feature都是和移动计算相关的。
Boost: 夸平台库集合。但模块之间设计原则独立。风格不求一致。包含FileSystem, Network, Smart Pointer...
优势:代码效率高。design for purpose...
劣势:不能算是一个应用开发平台,只能算是一个类库。每个库独立行强。。。不一定够用,尤其没有GUI部分。。。模板概念狂用,对编译器是一个考验。
agree!
网络编程:
QT的API很不错,Signal事件接口,我不觉得是异步IO接口,所以效率不高。
BOOST ASIO,异步IO接口,在Windows(IOCP), Solaris(ASIO),FreeBSD(KQUEUE),Linux(epoll), IO效率高。
ACE:和Boost ASIO相比完全落后了。只有Wiindows, Solaris是异步IO,Linux,其它的只能是Reactor。倒是有个澳洲人写了一个包在Linux,FreeBSD上实现了Proactor(epool, kqueue). 不好意思,其中一个版本我还提交和修改了一个bug。但作者现在工作在美国。开过Boost ASIO的代码后,对ACE一点兴趣都没有了。
ACE设计上还是挺优雅的,不过实现代码完全是恐龙级别的。 QT的网络在底层也可以自由替换成各自平台的异步IO。但是默认情况下QT的确并不使用IOCP. ASIO, Kqueue, Epoll这些技术,原因不是不能做,而是源于QT的设计原则:关注GUI,关注客户端。因为这种极端高效的本地化异步IO实现,对于服务密集型的服务器端编程更有意义,对于客户端,很难体现价值. |
|