对于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吗？