在下面的示例中，我們的工作將圍繞一個為投資（或者是股票、證券等等）建模的庫展開，在這個庫中，各種各樣的投資類型都繼承自同一個基類——Investment：
class Investment { ... }; // 投資類型層次結構的基類
繼續上面的示例，我們考慮通過工廠函數（參見條目7）來提供具體的Investment對象：
Investment* createInvestment(); // 返回一個指針，指向Investment
// 層次結構中動態分配的對象，
// 調用者必須要自行將其刪除
// （省略參數表以簡化代碼）
從上面代碼中的注釋中可以看出，當調用者完成對于createInvestment函數返回對象的操作后，有義務刪除這一對象。請看下邊代碼中一個履行這一義務的函數——f：
void f()
{
Investment *pInv = createInvestment(); // 調用工廠函數
... // 使用pInv
delete pInv; // 釋放該對象
}
這看上去可以正常運行，但是在一些情況下f可能無法成功刪除它從createInvestment獲得的對象。在上述代碼的“...”部分中的某處可能存在不成熟的return語句。一旦這樣的return語句得到了執行，那么程序將永遠無法到達delete語句。當createInvestment和delete在一個循環內使用時，也會出現類似的情形，這樣的循環有可能在遇到continue或goto語句而提前退出。最后，“...”中的一些語句還有可能拋出異常。如果真的有異常拋出，程序同樣也不會達到delete。無論delete是如何被跳過的，包含Investment對象的內存都將泄漏，同時這些對象所包含的資源都有可能得不到釋放。
當然，用心編程就有可能防止這類錯誤發生，但是請想象一下代碼會多么的不固定——你需要不停地修改代碼。隨著軟件不斷得到維護，為一個函數添加return或continue語句可能會對其資源管理策略造成怎樣的影響呢，一些人可能由于不完全理解這一問題就這樣做了。還有更嚴重的，就是f函數的“...”部分可能調用了一個這樣的函數：它原先不會拋出異常，但在其得到“改進”之后，它突然又開始能夠拋出異常了。寄希望于f函數總能達到其中的delete語句并不可靠。
為了確保createInvestment所返回的資源總能得到釋放，我們需要將這類資源放置在一個對象中，并讓該對象的析構函數在程序離開f時自動釋放資源。實際上，這就是本條目蘊含理念的一半了：通過將資源放置在對象中，我們可以依賴C++對默認析構函數的自動調用來確保資源及時得到釋放。（另一半理念稍后講解。）
許多資源是在堆上動態分配的，并且僅僅在單一的程序塊或函數中使用，這類資源應該在程序離開這一程序塊或函數之前得到釋放。標準庫中的auto_ptr就是為這類情況量身定做的。auto_ptr是一個類似于指針的對象（智能指針），其析構函數可以自動對其所指內容執行delete。以下代碼描述了如何使用auto_ptr來防止f潛在的資源泄漏。
void f()
{
std::auto_ptr<Investment> pInv(createInvestment());
// 調用工廠函數
... // 像前文示例一樣使用pInv
} // 通過auto_ptr的析構函數
// 自動刪除pInv
這一簡單的示例向我們展示了使用對象管理資源的兩大關鍵問題：
l 獲取資源后，資源將立即轉交給資源管理對象。上邊的示例中，createInvestment返回的資源將初始化一個auto_ptr，從而實現對這類資源的管理。事實上，使用對象來管理資源的理念通常稱為“資源獲取即初始化”（Resource Acquisition Is Initialization，簡稱RAII），這是因為，在同一個語句中獲取一個資源并且初始化一個資源管理對象是很平常的。某些時候獲取的資源就是會賦值給一個資源管理對象，而不是初始化。但是無論是哪種途徑，在獲取到一個資源時，每個資源都都會立即轉向一個資源管理對象。
l 資源管理對象使用其析構函數來確保資源得到釋放。由于析構函數是在對象銷毀時自動調用的（比如，當對象在其作用域外時），所以不管程序是如何離開一個塊的，資源都會被正確地釋放。如果釋放資源會帶來異常，那么事情就會變得錯綜復雜。但那是條目8中介紹的內容，我們這里不關心這些。
由于當一個auto_ptr被銷毀時，它將自動刪除其所指向的內容，所以永遠不存在多個auto_ptr指向同一個對象的情況，這一點很重要。如果存在的話，這個對象就會被多次刪除，這樣你的程序就會立即陷入未定義行為。為了防止此類問題發生，auto_ptr有一個不同尋常的特性：如果你復制它們（通過拷貝構造函數或者拷貝賦值運算符），它們就會被重設為null，然后資源的所有權將由復制出的指針獨占！
std::auto_ptr<Investment> pInv1(createInvestment());
// pInv1指向createInvestment
// 所返回的對象
std::auto_ptr<Investment> pInv2(pInv1);
// 現在pInv2指向這一對象，
// pInv1被重設為null
pInv1 = pInv2; // 現在pInv1指向這一對象
// pInv2被重設為null
在這一古怪的復制方法中，由于auto_ptr必須僅僅指向一個資源，因此增加了對于資源管理的潛在需求。這意味著auto_ptr并不適合于所有動態分配的資源。比如說，STL容器要求其內容表現出“正常”的復制行為，所以在容器中放置auto_ptr是不允許的。
引用計數智能指針（reference-counting smart pointer，簡稱RCSP）是auto_ptr的一個替代品。RCSP是這樣的智能指針：它可以跟蹤有多少的對象指向了一個特定的資源，同時當沒有指針在指向這一資源時，智能指針會自動刪除該資源。可以看出，RCSP的行為與垃圾回收器很相似。然而，與垃圾回收器不同的是，RCSP不能夠打斷循環引用（比如兩個不同的、空閑的、互相指向對方的對象）。
TR1的tr1::shared_ptr就是一個RCSP，于是你可以按下面的方式來編寫f：
void f()
{
...
std::tr1::shared_ptr<Investment>
pInv(createInvestment()); // 調用工廠函數
... // 像前文示例一樣使用pInv
} // 通過shared_ptr的析構函數
// 自動刪除pInv
上面的代碼與使用auto_ptr時幾乎完全相同，但是復制shared_ptr的行為更加自然：
void f()
{
...
std::tr1::shared_ptr<Investment> pInv1(createInvestment());
// pInv1指向createInvestment
// 所返回的對象
std::tr1::shared_ptr<Investment> pInv2(pInv1);
// 現在pInv1與pInv2均指向同一對象
pInv1 = pInv2; // 同上 — 因為什么都沒有改變
...
} // pInv1與pInv2被銷毀，
// 它們所指向的對象也被自動刪除了
由于復制tr1::shared_ptr的工作可以“如期進行”，所以在auto_ptr會出現另類的復制行為的地方，比如STL容器以及其它一些上下文中，這類指針能夠安全地應用。
但是，請不要迷失方向。本條目并不是專門講解auto_ptr和tr1::shared_ptr的，也不是講解智能指針的。本條目的核心內容是使用對象管理資源的重要性。auto_ptr和tr1::shared_ptr僅僅是這類對象的示例。（關于tr1::shared_ptr的更多信息，請參見條目14、18和54。）
auto_ptr和tr1::shared_ptr在析構函數中使用的都是delete語句，而不是delete[]。（條目16中描述了二者的區別。）這就意味著對于動態分配的數組使用auto_ptr和tr1::shared_ptr不是一個好主意。但是遺憾的是，這樣的代碼會通過編譯：
std::auto_ptr<std::string> aps(new std::string[10]);
// 壞主意！
// 這里將使用錯誤的刪除格式
std::tr1::shared_ptr<int> spi(new int[1024]);
// 同樣的問題
你可能會很吃驚，因為在C++中沒有類似于auto_ptr和tr1::shared_ptr的方案來解決動態分配數組的問題，甚至TR1中也沒有。這是因為vector和string通常都可以代替動態分配的數組。如果你仍然希望存在類似于auto_ptr和tr1::shared_ptr的數組類，請參見Boost的相關內容（見條目55）。那兒會滿足你需求：Boost提供了boost::scoped_array和boost::shared_array來處理相關問題。
本條目中指引你使用對象來管理資源。如果你手動釋放資源（比如使用delete而不是使用資源管理類），你就在做一些錯事。諸如auto_ptr和tr1::shared_ptr等封裝好的資源管理類通常可以讓遵循本條目的建議變成一件很容易的事情，但是某些情況下，你的問題無法使用這些現成的類來解決，此時你便需要創建自己的資源管理類。但這并沒有想象中那么難，但是確實需要你考慮一些細節問題。這些細節問題就是條目14和條目15的主題。
最后說一下，我必須指出createInvestment的原始指針返回類型存在著潛在的內存泄漏問題，因為調用者十分容易忘記在返回時調用delete。（甚至在調用者使用auto_ptr或tr1::shared_ptr來運行delete時，他們仍然需要在一個智能指針對象中保存createInvestment的返回值。）解決這一問題需要改變createInvestment的接口，這是條目18的主題。
時刻牢記
l 為了避免資源泄漏，可以使用RAII對象，這類對象使用構造函數獲取資源，析構函數釋放資源。
l auto_ptr或tr1::shared_ptr是兩個常用并且實用的RAII類。通常情況下tr1::shared_ptr是更好的選擇，因為它的復制行為更加直觀。復制一個auto_ptr將會使其重設為null。