首先，智慧型指標是模擬真實指標，但是負責管理資源釋放的類。
第一，為何要用指標，而不是直接用物件。指標是實現多型的基礎，同時具備靈活繫結性的一種型別（引用也可以實現多型，但是不具備靈活繫結性。而且你不能在堆中申請一塊記憶體，然後繫結，然後他就乖乖幫你釋放，做不到這種效果，所以他並不比指標更強大，卻很容易誤導人寫出錯誤的程式）。因此，用指標，主要目的就是實現多型，次要原因是需要後期繫結，比如在建立物件的時候不能準確得知這部分資料（但是或許用乙個stl容器包裝會是更好的設計）。
第二，智慧型指標不等於共享物件的潛台詞。在物件設計中，拷貝往往是深拷貝才符合語義，那麼這時候實現共享的智慧型指標一點意義也沒有（或者作為一種優化）。但如果是常量型資料成員的設計需求，可以用共享型智慧型指標來提高拷貝速度。拷貝構造是靜態的，不能支援多型，因此非共享型的智慧型指標的模板型別，就必須提供一種虛擬拷貝構造的方法。
第三，在c++中，構造物件即申請資源這個正規化很流行，所以我認為，作為智慧型指標，他所負責資源管理的是在他建立的時候所同時繫結的物件。除此之外，必須通過顯示的成員函式呼叫來改變這種繫結關係，而不能隱式，在無法看到這是乙個智慧型指標，而不是真是指標的情況下改變這種繫結。對於這種構造則繫結的需求，其實已經在c 99中得到體現，一種xx指標，鎖定在乙個堆物件中。
第四，智慧型指標的預設構造應該是怎樣的？stl容器需要預設建構函式，如果希望能與stl 容器配合，那麼智慧型指標就需要設計乙個預設建構函式。 預設清零，或者預設生成對應型別的物件。清零和真實指標比較類似，同時保證了丟擲異常的準確性。用預設型別物件，可以更加接近非指標容器，同時也保留了以後修改的繫結物件可能。
第五，共享型智慧型指標作為優化手段，可以保證讀共享，寫入前拷貝新物件。但是共享型也有個麻煩，那就是迴圈計數引用的問題。比如 a 指向 b， b 指向 a， 你想釋放a，b還有乙個計數在那裡，所以你不能釋放， 你想釋放b也是同樣的道理。 但是迴圈引用並不多見，vb 就是無視這個問題，也一樣沒見有多少人發覺是個問題。所以實際編碼中，絕少出現。 但是為了杜絕一切可能，我們只好認真研究解決的方法。迴圈引用為何少發生，那是因為迴圈引用發生的條件很苛刻：首先，a，b需要是乙個非普通型別物件，他們的成員有智慧型指標，然後指向對方型別。 也就是說，發生是依賴物件設計的，很少有這種物件設計，所以也就很少發生。要解決這個問題，我們可以防止這樣的物件設計，但是免不了的時候，首先應該清楚有多少約束條件，知道得越多，就越容易找到突破口。比如這種情況只會出現在後期繫結（至少其中乙個節點）上，在建立a就繫結b，建立b就繫結a，這是不可能成立的。
第六，指向棧中的物件，是危險的，棧有自己獨特的釋放規律。因此必須保證智慧型指標不指向棧中的物件。當然我想這是沒有辦法的，這是客戶的任務，而不是設計者能辦到的。也就是說存在這種迴圈引用的物件，應該只生存在堆中。因為如此，又必須由在棧中的智慧型指標來管理他們，因為你用普通指標，直接刪除某個物件，都是破壞了整個物件迴圈結構，後果是嚴重的。 棧中的智慧型指標決定了這個物件迴圈的生命週期，如果沒有棧中的指標，整個物件迴圈就應該析構。設計者可以想辦法統計這個資料，來完成物件的釋放。
關於智慧型指標使用的一些注意點
1.盡量使用unique ptr而非shared ptr 原因 1.unique ptr可以在需要共享物件時轉化為shared ptr，但shared ptr卻不能轉化為unique ptr 2.shared ptr內部維護著乙個引用計數器以及乙個控制塊，實現比unique ptr更為複雜，且需要消...
智慧型指標（一）
c 程式設計中使用堆記憶體是非常頻繁的操作，堆記憶體的申請和釋放都由程式設計師自己管理。管理是麻煩點 e.g.手動釋放等 但無傷大雅，勉強可以接受 但要命的是，容易出問題 為了解決該問題，c 11 引入智慧型指標概念使記憶體管理變得更為方便，且不易出錯 智慧型指標包含在標頭檔案中，包括 shared...
硬體的一些效能指標
換算關係 1 s 10 3 ms 10 6 us 10 9 ns 10 12 s 秒 毫秒 微秒 納秒 皮秒 總結一下，它們之間的關係就是，指令週期由若干個機器週期組成，匯流排週期一般由4個時鐘週期組成。機器週期和匯流排週期 機器週期指的是完成乙個基本操作的時間，這個基本操作有時可能包含匯流排讀寫，...