boost庫學習總結

2021-08-11 22:03:57 字數 4204 閱讀 6654

第一次使用boost庫是因為網路程式設計,由於時間比較緊,沒有時間每個庫都學,所以前期想找個專門的boost庫網路教程(以前自己就用過socket寫過,但是為了跨平台,而且boost庫這麼好,還是趁早學吧)。終於在網上找到乙個很好的boost庫教程系列。

。之所以用framework是因為ios裝置和ios模擬器使用的boost庫是不一樣的,乙個是嵌入式裝置版本,另外乙個就是mac os版本,為了解決ios裝置與模擬器之間的除錯差異,使用framework最好不過了。

resolver的非同步查詢(async_resolve)讓我搞了1個小時,雖然教程上說根據說明文件很容易使用async_resolve,但是實際編寫時就遇到問題了。

bug:非同步完成控制代碼被呼叫時始終傳入error。

但從網上查資料,基本跟我寫的一樣啊,沒什麼區別。最後各種嘗試,終於找出裡面的原因來了。

解決方法:io_service必須要在socket,resolver初始化之後才能呼叫run()函式,否則非同步查詢始終出錯。

scoped_ptr:確保指標的所有者只有乙個(當然你不應該將原生指標賦給多個scoped_ptr物件),即scoped_ptr本身不能被scoped_ptr型別構造或者賦值。而且由於將原生指標封裝成類,可就成了異常安全型別了。並且scoped_ptr很適合用於有多個分支的函式,例如一開始申請一塊緩衝區,多個分支函式可能直接返回,在返回之前我們一般都需要刪除這塊記憶體,此時我們可以使用scoped_ptr去指向這塊剛申請的記憶體。這樣我們就不用顯示釋放了。這個方案相比於使用goto語句結構更清晰,更安全。

scoped_array:它和scoped_ptr幾乎一模一樣,除了多提供了operator函式,使其能像一般陣列一樣訪問對應元素。scoped_array一般用於當陣列元素固定的時候(個人認為如果固定的話,除非每個元素大小很大,否則直接使用區域性變數比較好)。動態的陣列分配,如果對效率沒有非常苛刻的要求的話,建議還是使用std::vector。

shared_ptr

在看到boost部分原始碼的時候對其建構函式比較好奇,為了建構函式還使用偏特化模版函式。即

[cpp]view plain

copy

template

class shared_ptr ;  

原來shared_ptr也可以這樣使用。

[cpp]view plain

copy

boost::shared_ptr< void > p( new std::string( "helloworld" );  

這樣就隱藏了智慧型指標p的真實指標型別。但shared_ptr保證能正確錶用std::~string析構函式(內部肯定記錄了)。

這種設計其實背後有很大文章。由於shared_ptr設計中也考慮到相容以前**,所以我們可以從shared_ptr獲取原生指標,但如果使用者使用原生指標刪除了動態分配的物件怎麼辦?

我們可以採用這種模式:

[cpp]view plain

copy

class a ;  

};  

class b : public a   

};  

基類的析構函式是protected,所以基類指標是不能呼叫delete。派生類的是public自然就可以刪除了。有了上面的設計,在加上shared_ptr的模版引數和構造引數可以不同這個特點,就可以解決方面的問題了,如:

[cpp]view plain

copy

boost::shared_ptrcreatea()   

通過此函式建立出來的shared_ptr,其get()返回的指標是無法被刪除的(當然你強制轉換除外)。所以可以放心的把shared_ptr::get()函式返回的指標給需要原生指標的函式使用。

polymorphic_cast

這是乙個dynamic_cast的特殊版,由於dynamic_cast對指標轉換失敗和引用轉換失敗結果不一致,polymorphic_cast決心將其改正,也就是當指標型別轉換失敗的時候也丟擲異常,但是polymorphic_cast不能用於引用型別。個人感覺有點「拗口」。不過書中也提了利用將指標轉換成引用來實現指標轉換失敗時採用像引用轉換失敗的策略(即丟擲異常)。由於現在水平有限,不能很好地體會到大師用意。

polymorphic_downcast

這是非常好的工具,乙個在debug環境下按照dynamic_cast流程走,以方便除錯。但是在release環境下按照static_cast流程走,提高效率。當然前提是你確保傳入的型別按原本的意圖是指傳一種已知的型別,即這個模版函式適用於,原來強制型別轉換的地方(特別是預防以後可能傳入錯誤型別的情況)。

numeric_cast

是個使用的工具,讓我們平時粗心的轉換得到更多安全的保障。

lexical_cast

乙個讓字串和其他型別之間的轉換更「美好「的工具。原理類似與stringstream。使用者自定義的類,只要滿足operator《就能被lexical_cast轉換。如果滿足operator>>就能接受lexical_cast的轉換結果。

boost_static_cast

乙個能在編譯階段確定某模版引數是某一型別的巨集定義。唉,我們日常生活自己編寫模版類的實踐太少,看來中國和最先進的c++水平還是有不少差距啊。

checked_delete

乙個能保證被delete的物件所屬類,在該函式呼叫處,已經有完整資訊。即編譯器有類的足夠資訊,以可以正常呼叫該物件類的析構函式。這種情況很少,但是大師的任務是,杜絕一切可能,提供最牢靠的」防禦「。

noncopyable

乙個在很多類框架中都能看到,而且自己也接觸的模式,就是提供乙個不可複製的基類。讓派生類以私有形式(共有形式也可以,但是在設計角度不夠好)派生該基類。以表達此類具有不可複製的屬性。

address_of

乙個能確保取到變數位址的模版函式,及時這個變數所屬的類過載了取址操作符(&),此函式也能夠取到真正位址。

enable_if, disable_if

乙個能讓某些模版函式或者類加入或者排除在候選過載函式中。牛,我只能說,大師做的事情已經跟我們不乙個級別了。目前還沒遇到過這種情況,但是我相信,如果沒有看到《beyond the c++ standard library: an introduction to boost》,一定會很迷茫。

operator

operators標頭檔案中包含了很多有便擴充套件操作符過載的解決方案,就像書中寫的,如果我們提供operator<,那麼我麼應該提供operator<=,>=,>等操作符,但是其實我們發現,通過opertor《我們能夠推出operator<=,operator>=,operator>等操作符,但是我們卻往往忽略,或者怕出錯誤,以至於我們類的操作符過載不夠「友好」,使用者使用不能像預想的那樣。opertors庫,讓這些依賴於主操作符過載的輔操作符過載更簡單,而且更加概念化,系統化。通過派生於less_than_comparable,我們就能實現比較,通過其他概念,我們將更加簡單而且清晰的實現各類應該具備的操作符。

regular expression

相信做過文字檔案讀取,或者各類工具的程式設計愛好者,一定對於正規表示式十分的嚮往(如果有高效,易用的正規表示式,那麼很多應用將得心應手)。相信boost::regex可以給你帶來希望。基本上是用使用regex需要3部分:需要被處理的源文字字串,匹配結果,正規表示式。通過regex的三大演算法(regex_match,regex_search,regex_replace),我們能實現各種應用,而且還有其他很多如regex_token_iterator等使用操作,讓regex非常好用。但是regex是個很大的庫,裡面包含的知識和應用十分龐大,具體的還是需要參考document,這個章節只是乙個很好的引導者。

any

這個類提供了像shared_ptr一樣的功能:能夠包含任意型別。但是any不是乙個模板類。所以我們可以在stl的容器中使用其作為型別引數,這樣我們就可以實現在stl容器中包含任意型別的目的了。any中的any_cast是其精髓,想要訪問any中的例項都需要這個介面去獲得新的例項拷貝。

Boost庫使用總結

智慧型指標,與引用計數相關 auto ptr 主要為異常安全設計的,在程式正常退出或者異常終止,會呼叫類的析構函式,釋放資源。複製 賦值是損壞性的操作,所以不能繫結到陣列或者變數指標,也不能將auto ptr物件儲存在容器中。auto ptra new int 10 auto ptrb b.rese...

Boost庫學習筆記

timer類 由於精度原因,不適合於精度很高或時間跨度很大的地方。也不能很好的跨平台。呼叫elapsed min 和elapsed max 分別獲取其精度,而且其精度根據平台會有變化。progress timer類繼承與timer類,但是其有乙個析構函式,析構的時候會自動呼叫elapsed 輸出從構...

boost常用庫的使用總結

一 多執行緒 1 thread庫相關的,c 多執行緒是乙個複雜的事情,windows mfc提供了cwinthread類,waitforsingleobject等待 執行緒 linux系統提供了createthread,thread join來 執行緒。boost thread就比較方便了 1 bo...