boost 在实际项目中的使用

原文链接：http://blog.csdn.net/linuxchyu/article/details/9230641

对于 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 下面貌似没有。不管怎么说，如果用到正则表达式，这个还是首选。虽然它有一大堆实现文件。

8、一些我个人绝对不会使用的库：

test 用起来很不方便，不如用cxxtest

preprocessor 游戏开发需要词法分析吗？  加上这个库会让你的工程编译时间变成一个世纪那么长

mpl  牛人可以使用它来封装自己的模板库，但是接口中一定不要暴露出相关的东西。因为这个东西可不是人人都懂的。

lambda 虽然tr1中也有lambda，但是还是不要为了省两行代码加入匿名函数了。自己看着爽了，别人就都看不懂了。毕竟c++是c++，java是java

date_time 这么简单的东西，还是自己封装下好了。牵扯到夏时令还有时区的时候，还是自己写的更加放心

property_tree 可能我会封装一个类似的兼容 xml 和 json 和 ini 的配置读取方式，但是肯定不会是 property_tree 这样的形式，应该更加简洁一些，即便扩展性差些。

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