C++作為一種編程語言，僅僅是它的語法、特性、標准類庫就已經是一項非常難理解的東西了，所以在開始接觸時，一定要打下良好的代碼，這樣才會給今後的學習帶來便捷的道路。下面說一下C++風格與技巧問題。
早在1981年，我就指出，通過將我必須顯式地跟蹤的對象的數量從幾萬個減少到幾打，為了使程序正確運行而付出的努力從可怕的苦工，變成了應付一些可管理的對象，甚至更加簡單了。如果你的程序還沒有包含將顯式內存管理減少到最小限度的庫，那麼要讓你程序完成和正確運行的話，最快的途徑也許就是先建立一個這樣的庫。
- #include<memory>
- #include<iostream>
- using namespace std;
- struct S {
- S() { cout << "make an S\n"; }
- ~S() { cout << "destroy an S\n"; }
- S(const S&) { cout << "copy initialize an S\n"; }
- S& operator=(const S&) { cout << "copy assign an S\n"; }
- };
模板和標准庫實現了容器、資源句柄以及諸如此類的東西，更早的使用甚至在多年以前。異常的使用使之更加完善。如果你實在不能將內存分配/重新分配的操作隱藏到你需要的對象中時，你可以使用資源句柄resource handle），以將內存洩漏的可能性降至最低。
這裡有個例子：我需要通過一個函數，C++風格與技巧在空閒內存中建立一個對象並返回它。這時候可能忘記釋放這個對象。畢竟，我們不能說，僅僅關注當這個指針要被釋放的時候，誰將負責去做。
使用資源句柄，這裡用了標准庫中的auto_ptr，使需要為之負責的地方變得明確了。在更一般的意義上考慮資源，而不僅僅是內存。如果在你的環境中不能系統地應用這些技巧例如，你必須使用別的地方的代碼。
或者你的程序的另一部分簡直是原始人類譯注：原文是Neanderthals，尼安德特人，舊石器時代廣泛分布在歐洲的猿人）寫的，如此等等），那麼注意使用一個內存洩漏檢測器作為開發過程的一部分，或者插入一個垃圾收集器garbage collector）。
我為什麼在捕獲一個異常之後就不能繼續？換句話說，C++為什麼不提供一種簡單的方式，讓程序能夠回到異常拋出點之後，並繼續執行？主要的原因是，如果從異常處理之後繼續，那麼無法預知擲出點之後的代碼如何對待異常處理，是否僅僅繼續執行，就象什麼也沒有發生一樣。
異常處理者無法知道，在繼續之前，有關的上下文環境context）是否是“正確”的。要讓這樣的代碼正確執行，拋出異常的編寫者與捕獲異常的編寫者必須對彼此的代碼與上下文環境都非常熟悉才行。這樣會產生非常復雜的依賴性，因此無論在什麼情況下，都會導致一系列嚴重的維護問題。
當我設計C++的異常處理機制時，我曾經認真地考慮過C++風格與技巧允許這種繼續的可能性，而且在標准化的過程中，這個問題被非常詳細地討論過。請參見《C++語言的設計和演變》中的異常處理章節。
