最近工作上遇到幾個問題都與boost庫有關，所以做一下簡單的總結。

1.多執行緒環境使用boost庫引起的crash

專案中使用到boost::filesystem::is_regular_file來做判斷，但是在多執行緒環境下出現了crash，檢視原因是在boost庫中進行窄字串與寬字串轉換的時候，進入到一個靜態函式中，但是靜態函式沒有加鎖，所以導致在第一個執行緒修改結束之前第二個執行緒沒有等待就直接使用了指標，使用空指標導致crash。

boost::filesystem::path 型別在多執行緒環境下要謹慎使用。

boost庫的bug track：https://svn.boost.org/trac/boost/ticket/6320

const path::codecvt_type *& path::wchar_t_codecvt_facet() {

static const std::codecvt<wchar_t, char, std::mbstate_t> *

facet(

&std::use_facet<std::codecvt<wchar_t, char, std::mbstate_t> >

(path_locale()));

return facet;

}

This method is entered by multiple threads concurrently and the static pointer "facet" gets initialized by the first thread (which takes some time) but the other threads don't wait and just continue while facet is a NULL pointer.

In boost 1.44 this crash didn't occur. It seems that the initialization of global variable const fs::path dot_path(L"."); in filesystem/v3/source/path.cpp resulted in a call of path::wchar_t_codecvt_facet(), so the static "facet" pointer got initialized during program startup while no other threads were running.

In boost 1.48 the initialization of the same globale variable doesn't result in a call of path::wchar_t_codecvt_facet() so race conditions might occur during initialization of the static "facet" pointer (in C++ 03).

2.boost庫的效能問題

Boost庫在效能上並沒有做的那麼完美，在進行字串查詢的時候，boost庫提供了一個boost::contains和boost::icontains方法，後者忽略字串大小寫。但是在測試效能的時候，這兩個函式對效能影響巨大，使用string/wstring自帶的find函式，效能會提高不少。boost::icontain耗效能的主要原因查看了原始碼，發現主要是在內部做了多次is_equal()的呼叫，且每次is_equal時都會進行to_upper()或者to_lower()一類的操作。所以非常考慮效能的話建議使用string自帶的find。