现在的位置: 首页 > 自动控制 > 工业·编程 > 正文

无比强大的boost库

2014-04-18 05:25 工业·编程 ⁄ 共 3387字 ⁄ 字号 暂无评论

最近这段时间以理解asio为契机,开始学习了一些以前并不用到的boost库,慢慢的发现boost库的强大远超过我的想象,以前我也就用用boost库中的智能指针,后来TR1出来后,在学习正则表达式的时候,尝试用过其boost::regex这个以后肯定会进C++09标准的东西,其他东西用的还真是不多,毕竟工作中学习的时间还是少了些,公司的开发又完全不准用boost的,加上又有太多东西要学,直到最近说要学习网络编程的相关知识,然后找到了asio,才开始又一次的慢慢接触boost库了,再加上学习python的过程中,不断的对C++现有体系进行了反思(其实主要还是语法上的,毕竟我层次还没有那么高),常常回过头来看看C++中的对应用法,虽然这里将一个超级慢的动态语言的语法优点来和以效率为生命的C++来对比不是太公平,但是起码我加深了对很多东西的理解,在连续的三篇文章中可以得到体现:

分别是《多想追求简洁的极致,但是无奈的学习C++中for_each的应用》,《其实C++比Python更需要lambda语法,可惜没有。。。。》,《boost::function,让C++的函数也能当第一类值使用》,其实,也许还可以为boost::bind专门写一篇,但是后来觉得自己对嵌套反复的bind语法还是比较反感,就作罢了,虽然boost::bind比现在标准库中的bind1st,bind2nd加一大堆的mem_funXXX的东西优美一些,但是即便新的标准加上bind,加上mem_fn,其实感觉还是在语言上打补丁一样,还不是那么的优美,唉。。。具体要多优美,这个我也就不好说了。。。。。。。弱弱的说一句,看看python的列表解析。。。。

但是,对boost库的进一步了解,倒是让我对自己写一个可移植网络框架的心少了很多,一方面的确也是精力不太够,另一方面我发现自己没有办法写的比boost中现有的更好(也许能更加精简)。这里将原有的计划列出来,对比一下boost中已经有的东西。详细计划见原来的文章《工作之外的学习/开发计划(1) -- windows/linux服务器程序支持库的开发

工作之外的学习/开发计划(1) -- windows/linux服务器程序支持库的开发

简化服务器程序的开发,设计合理的服务器框架程序。 --- 主要目的

实现工程文件(对我来说一般就是服务器程序)以同一套源码在windows和linux下的编译运行。 -- 次要目的,但是必完成-_-!

其实对于支持库来说,很重要的一点来说,就是尽量对外实现操作系统无关的同一套接口。。。。

需求列表:(仅仅是知识还非常欠缺的我目前能想到的,以后需要再添加吧)

网络框架支持:

windows服务器TCP用IOCP模型

linux服务器TCP用epoll模型

UDP都用同一套

另外,为简单的网络应用程序(其实在我们公司中是客户端跑的)使用select模型。(就目前我浅显的网络知识了解,我不明白为什么要这样,select其实也是属于I/O复用的模型了,但是实际客户端方面用的都是单套接字,单连接,单处理线程,难道仅仅是为了防止输入阻塞和套接字API阻塞的冲突?)

服务器其他支持库

1. 序列化支持。

2. 日志系统支持。

3. 脚本语言配置文件支持。(可考虑上脚本系统)

4. 运行时异常dump支持。

5. 多线程支持。(其实看很多书说Linux下弄单进程更好,但是那样和windows下共用一套源码估计就更难了。)

6. windows下也能跑的posix库。

7. ODBC库/mySQL API 支持库(任选)

8. 多进程支持(待选)。

这里给出一个boost中已有实现的对比。。。

首先,我的目标。。。。可移植的网络框架,以简化开发服务器为目的。。

boost作为准标准库可移植性实在是做的够好了。。。。看看其文档中支持的编译器/环境列表就知道了,远超我以前的目标Windows/Linux可移植。。。。

其次,核心模块,网络框架,boost::asio的实现就是和我原有设想的实现一模一样。。。。。windows用IOCP模型,linux用epoll,并且作为一个已经获得较广泛使用的轻量级网络支持库,见《Who is using Asio? 》并且甚至可能进入下一版的C++标准(虽然个人认为可能性还是比较小),还是远超我以前的目标。。。。。当然,我从来没有目标去达到想ACE一样,asio就很不错了。

然后,其他支持库:

1.序列化支持。==》boost::serialize库,强大,强大,还是强大,我有一系列文章,介绍了其强大和使用方法。《序列化支持(1)》,《序列化支持(2)—Boost的序列化库》,《序列化支持(3)—Boost的序列化库的使用》,《序列化支持(4)—Boost的序列化库的强大之处》。但是比较遗憾的是,虽然据说BS以前很遗憾的说,现在C++中最大的遗憾就是没有数据持久化和垃圾回收机制的话,但是,boost::serialize似乎还是没有希望进入下一版C++标准,也就是说,我们以后的C++只能还是没有一个标准的序列化方式可以使用。。。。

2.日志系统支持。==》这个boost种据说以前有过,但是后来停止开发了,最近也在某个地方看到过一个使用标准iostream的日志库,一下子没有找到,但是其实实在没有,用log4cxx也不错。再没有自己写一个也不难(在公司我就完成过用额外的线程写日志的工作,包括测试也就用了一天时间)

3. 脚本语言配置文件支持。(可考虑上脚本系统)==》这点更好了,boost::Program Options就是完全对应的选择,并且,假如我想用Python,我还可以不仅仅是使用Python的C API,个人感觉要完全用Python C API去映射C++的类相对来说还是比较难,但是有了boost::Python库又不一样了。。。。生活可以更美的。

4.运行时异常dump支持。==》这个嘛。。。。除了我以前研究过的google的breakpad似乎不知道还有其他更好的选择没有,实在不行也就只能自己做了。注意啊,这个dump不仅仅是出错/异常的时候,我应该能在我需要的任何时候进行core dump,而不影响程序的运行。

5.多线程支持。==》天哪。。。boost::thread库就是为这个准备的,并且其实现的确不错,虽然假如自己要实现一套也不算太难。

6. windows下也能跑的posix库。==》虽然说boost::System库设计的就像是错误代码集合库,但是在大量的使用boost库后,posix的很多功能有没有必要使用还难说。。。。。比如说boost::Filesystem,boost:: Date Time的支持作用还是很强的

7. 多进程支持==》创建进程的方式在Windows(CreateProcess)和Linux(Fork)下的差异还是有的,但是也不是完全不能统一,麻烦点的就是Windows没有僵尸进程的概念导致进程ID不能真正区别出一个进程,比如说一个ID100的进程关闭了,然后一个新的进程启动后ID为100,并且父子进程之间的联系比Linux下要弱的多。,比如没有getppid系统调用,其实CreateProcess后,父进程将子进程的句柄都close后,两者就几乎没有关系了,可能仅有的联系就是子进程继承了父进程的核心对象列表,而Linux下子进程可是必须等待父进程来‘收割的啊:)但是最最核心的问题还是IPC(进程通信)的问题,还好,boost::Interprocess又是完美的满足了需求

如上所述。。。一个可移植的网络服务器开发支持库,基本上也就是boost库的一个子集。。。。我们能使用的还有如boost::Signals这样的库来实现网络包的分发及映射,有如智能指针,boost::funtion, boost::lambda, boost::bind,boost::foreach来简化我们的程序,这个C++的世界还能更加美好吗?。。。。。。。呵呵,除非等下一代C++的标准出来了。。。。。

也许,使用boost库唯一的问题是。。。。让我使用了这么好用的库,假如我以后不能使用boost库那怎么办啊?!

呵呵,当然,总是要在自己的程序中带上很多的boost库的dll,其实也算是个问题。

作者:程序即人生

给我留言

留言无头像?