FreeOZ论坛

标题: 请教一下关于Qt/ boost, MPI / socket [打印本页]

作者: GPS 时间: 10-12-2009 15:19
标题: 请教一下关于Qt/ boost, MPI / socket
Qt已经变成了一个C++的框架了，boost也是另外一套，好像更靠近C++标准，请前辈们给比较一下，看看两者的前途，用途和在澳洲的钱途，要不要两个都要懂。

另外再比较一下并行程序中，用MPI还是直接用SOCKET联系呢？也比较一下吧。

boost里似乎已经有MPI的支持了，Qt里怎么用MPI呢？

作者: coredump 时间: 10-12-2009 18:10
QT: A C++ Framework (specially it's a C++ GUI Framework)Boost: A C++ library toolkit

MPI is on top of the socket library.

作者: procoder 时间: 12-12-2009 22:06
网络编程推荐ACE。

作者: mash 时间: 12-12-2009 23:33
QT: 已经不能算GUI库了。应该算是一个夸平台应用开发平台了。GUI，Filesystem, Network, 2D, 3D, plugins, MutiMedia...基本什么都包含了。

优势：文档丰富，API设计优雅，尤其对于Java编程人员。编译的代码尽量靠近本地API。
劣势：代码效率不高，这和设计有关，for Desktop development.

Boost: 夸平台库集合。但模块之间设计原则独立。风格不求一致。包含FileSystem, Network, Smart Pointer...
优势：代码效率高。design for purpose...
劣势：不能算是一个应用开发平台，只能算是一个类库。每个库独立行强。。。不一定够用，尤其没有GUI部分。。。模板概念狂用，对编译器是一个考验。

网络编程：
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一点兴趣都没有了。

[ 本帖最后由 mash 于 12-12-2009 23:35 编辑 ]

作者: GPS 时间: 13-12-2009 22:14
多谢几位前辈的经验。
我还在学习QT, 感觉它的signal-slot特别有意思。就算不做GUI，我也用它的线程和signal-slot机制，尤其是线程间signal-slot可以避免使用mutex。我把要共享的资源放到一个单独的线程去，其它线程就发signal，由于有个signal queue, 就实现了互斥。也不知道该不该这么做。

既然boost效率很高，可是我担心如果和QT合用的话，是不是不太一致。就比如用boost来做network，是不是就没有signals了。还有其它一些类的转换，比如QString.

2楼推荐ACE, 3楼推荐boost，呵呵，能不能再仔细展开一点阿？我是想想先学哪个看看。

另外，我也在用Qt来做手机程序，主要考虑是，一是Qt本身挺方便用，而是也号称跨平台，至少主要的框架可以保留，只要改变涉及本地的API。不过生成windows mobile上的程序挺大，还有一堆库。

至于MPI，似乎接口比较简单，是不是做并行程序，最好还是做个cluster ,用MPI 比直接用SOCKET合适一些呢？具体有哪些考虑呢？另外，beowulf cluster有什么利弊呢？

基本都是初学者的一些问题，几位再指点一下，看看哪里不合适或者不对的。我就想学点LINUX和C++的东西。谢谢。

作者: coredump 时间: 14-12-2009 10:27

原帖由 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实现，对于服务密集型的服务器端编程更有意义，对于客户端，很难体现价值.

作者: coredump 时间: 14-12-2009 10:29

原帖由 GPS 于 13-12-2009 21:14 发表

 登录/注册后可看大图

既然boost效率很高，可是我担心如果和QT合用的话，是不是不太一致。就比如用boost来做network，是不是就没有signals了。还有其它一些类的转换，比如QString.

QT和boost合用没关系的，甚至QT的signal-slot和Boost的signals都可以混用。

QString更是方便了，从stl string转来转去，也不难。而且QString有隐身共享的功能，效率比std::string高很多。

作者: kaile 时间: 16-12-2009 18:45
界面库一般用　xtremetoolkit 和　BCG 。

其他的暂时用着MFC，正在学boost

作者: GPS 时间: 24-12-2009 22:44
我也想学boost，楼上看什么资料阿？能不能介绍下你的学习方法，谢谢阿。

欢迎光临 FreeOZ论坛 (https://www.freeoz.org/bbs/)