如果shared_ptr默认是用delete来释放对象的，而delete动作产生的是本模块的代码，这在windows平台的dll中遇到了问题：可执行程序和dll分属不同模块，分别使用各自的内存管理组件。直接delete,无异于把A堆管理器分配的指针让B堆管理其去释放，崩溃还算好的，悄悄的出错，死都不知道怎么死的。
还好，boost::shared_ptr使用了一个叫get_deleter的东西，内部维护了delete的方法。可是，如果我想自定义一个特别的析构方法怎么办？嗯，特化sp_counted_impl_p<>吧！
特化sp_counted_impl_p可以解决大部分问题。可是，引用计数的问题，则是无法解决的：你不可能重写sp_counted_base。如果我想用shared_ptr指向一个com对象，那么，sp_counted_impl_p<>可以让它工作，但是，com对象内的引用计数将不可能正确。
由此，不由的怀念起Loki的SmartPtr来了，强大的基于策略编程的实现！只要将存储策略中的Destory替换成我想要的实现即可实现定制销毁。替换掉OwnershipPolicy就可以。就算Loki不能进boost（老实说，我认为mpl比typelist好），SmartPtr绝对应该比那shared_ptr强多了！
还好，boost::shared_ptr使用了一个叫get_deleter的东西，内部维护了delete的方法。可是，如果我想自定义一个特别的析构方法怎么办？嗯，特化sp_counted_impl_p<>吧！
特化sp_counted_impl_p可以解决大部分问题。可是，引用计数的问题，则是无法解决的：你不可能重写sp_counted_base。如果我想用shared_ptr指向一个com对象，那么，sp_counted_impl_p<>可以让它工作，但是，com对象内的引用计数将不可能正确。
由此，不由的怀念起Loki的SmartPtr来了，强大的基于策略编程的实现！只要将存储策略中的Destory替换成我想要的实现即可实现定制销毁。替换掉OwnershipPolicy就可以。就算Loki不能进boost（老实说，我认为mpl比typelist好），SmartPtr绝对应该比那shared_ptr强多了！