boost在实际项目中的使用

boost在实际项目中的使用
boost在实际项目中的使用
分类：编程基础开源库介绍 2013-02-03 16:05 134人阅读评论(0) 收藏举报
对于boost在实际项目中的使用应该有一个相对客观的态度，既不能过分使用，在项目中铺满boost，又不能对其畏之如虎，不敢使用。

我想实际游戏开发中，我们的团队伙伴大多应该是跟我一样程度的----对c++有一定的了解，又绝对成不上专家。

所以，我们使用boost应该有下面这些原则或者说是注意事项：
1、不要认为boost非常庞大就一概否定，认为游戏客户端里面绝对不能或者完全没有必要加boost。

我们完全可以使用bcp裁剪我们需要的模块，虽然boost的牵连性还是很大的，裁剪一个智能指针有可能会裁剪出一大堆文件，但是至少不会把100mb+ 的代码都加到项目中。

2、我们常用的一些boost库已经加到tr1里面了，我们常用的开发环境又都是支持tr1的。

vs2010、xcode、android ndk。

所以如果我们只是用这些功能的话那么确实没有必要引入boost。

3、尽量避免需要编译的boost库的使用。

只使用头文件形式的。

如果一定要使用的话，那么可以选择把实现文件直接加到项目中，当做我们自己的代码来进行维护。

这样ios和android环境维护起来要方便很多。

如果我们只在windows下进行开发，那么boost的auto_link机制也还方便。

至少最近几个版本的boost编译起来已经相当方便了，方便到不需要教程的地步了。

4、尽量避免平台相关的库的使用。

虽然像filesystem这样的库使用起来很方便，boost也帮助我们封装了平台依赖。

但是还是尽量要避免这些库的使用。

因为boost虽然支持ios和android，但并不意味着这些库在ios和android下都能正常工作。

比如我之前就碰到过，filesystem的某个函数在ipad2上会崩溃，但是在iphone和ipad1
上面又正常。

还有boost::mutex在ios下怎么也锁不住，但是自己简单封装下pthread又可以正常工作。

所以与平台紧密相关的操作还是自己维护的好，否则就是要替boost debug代码了。

5、不要认为boost什么都好，就在代码里面充斥着boost的代码。

因为boost再工业化强度，也仅仅是“准”标准库。

不是人人都会使用boost，也不是人人都愿意学习boost。

代码中大量出现mpl 什么的绝对不是一个聪明的选择。

6、boost相关的头文件，要么加入到预编译头里面。

要么放到实现文件里面。

千万不要放到会被大量引用，但是又没有预编译的头文件。

因为boost里面大量充斥着模板，编译起来时间相当漫长。

7、我常用的一些boost库：
smart_ptr function bind 这三个不用多说了，已经加到tr1里面的，如果还不会的话，就跟c++程序员不会stl一样，直接面壁去。

algorithm/string 字符串算法库，这个相当好用并且很基础。

如果不用这个话，那肯定还是要自己重复造轮子的。

format 这个见仁见智，如果不喜欢它的语法的话，那就自己封装个。

这个比vsnprintf最大的好处就是安全性，不会因为参数传错而崩溃
pool 这个还没有真正使用，不过如果我有内存池的需要的话，绝对不会介意使用这个
regex 这个也是加到tr1里面的，不过ios下面貌似没有。

不管怎么说，如果用到正则表达式，这个还是首选。

虽然它有一大堆实现文件。

一些我个人绝对不会使用的库：
test 用起来很不方便，不如用cxxtest
preprocessor 游戏开发需要词法分析吗？加上这个库会让你的工程编译时间变成一个世纪那么长
mpl 牛人可以使用它来封装自己的模板库，但是接口中一定不要暴露出相关的东西。

因为这个东西可不是人人都懂的。

lambda 虽然tr1中也有lambda，但是还是不要为了省两行代码加入匿名函数了。

自己看着爽了，别人就都看不懂了。

毕竟c++是c++，java是java
date_time 这么简单的东西，还是自己封装下好了。

牵扯到夏时令还有时区的时候，还是自己写的更加放心
property_tree 可能我会封装一个类似的兼容xml和json和ini 的配置读取方式，但是肯定不会是property_tree这样的形式，应该更加简洁一些，即便扩展性差些。

thread 前面说过了，自己封装下也不麻烦，不就是pthread吗？。