C/C++ 最大難點揭秘：編程的禍根！
引言
但事實并非如此。本文將讓您在短時間內理解與良好內存相關的編碼的所有本質：
正確的內存管理的重要性
在可以使用 C 或 C++ 的地方，也廣泛支持使用其他許多通用語言(如 Java?、Ruby、Haskell、C#、Perl、Smalltalk 等)，每種語言都有眾多的愛好者和各自的優(yōu)點。但是，從計算角度來看，每種編程語言優(yōu)于 C 或 C++ 的主要優(yōu)點都與便于內存管理密切相關。與內存相關的編程是如此重要，而在實踐中正確應用又是如此困難，以致于它支配著面向對象編程語言、功能性編程語言、高級編程語言、聲明性編程語言和另外一些編程語言的所有其他變量或理論。
與少數(shù)其他類型的常見錯誤一樣，內存錯誤還是一種隱性危害：它們很難再現(xiàn)，癥狀通常不能在相應的源代碼中找到。例如，無論何時何地發(fā)生內存泄漏，都可能表現(xiàn)為應用程序完全無法接受，同時內存泄漏不是顯而易見。
因此，出于所有這些原因，需要特別關注 C 和 C++ 編程的內存問題。讓我們看一看如何解決這些問題，先不談是哪種語言。
內存錯誤的類別
這是所有類型。即使遷移到 C++ 面向對象的語言，這些類型也不會有明顯變化;無論數(shù)據(jù)是簡單類型還是 C 語言的 struct或 C++ 的類，C 和 C++ 中內存管理和引用的模型在原理上都是相同的。以下內容絕大部分是“純 C”語言，對于擴展到 C++ 主要留作練習使用。
void f1(char *explanation)
{
char p1;
p1 = malloc(100);
(void) sprintf(p1,
"The f1 error occurred because of '%s'.",
explanation);
local_log(p1);
}
在實際的 C 和 C++ 編程中，這不足以影響您對 malloc()或 new的使用，本部分開頭的句子提到了“資源”不是僅指“內存”，因為還有類似以下內容的示例(請參見清單 2)。FILE句柄可能與內存塊不同，但是必須對它們給予同等關注：
清單 2. 來自資源錯誤管理的潛在堆內存丟失
int getkey(char *filename)
{
FILE *fp;
int key;
fp = fopen(filename, "r");
fscanf(fp, "%d", &key);
return key;
}
錯誤分配的管理不是很困難。下面是一個示例(請參見清單 3)：
清單 3. 未初始化的指針
void f2(int datum)
{
int *p2;
/* Uh-oh! No one has initialized p2. */
*p2 = datum;
...
}
在此錯誤類型中存在多個變種。free()釋放的內存比 malloc()更頻繁(請參見清單 4)：
/* Allocate once, free twice. */
void f3()
{
char *p;
p = malloc(10);
...
free(p);
...
free(p);
}
/* Allocate zero times, free once. */
void f4()
{
char *p;
/* Note that p remains uninitialized here. */
free(p);
}
void f8()
{
struct x *xp;
xp = (struct x *) malloc(sizeof (struct x));
xp.q = 13;
...
free(xp);
...
/* Problem! There's no guarantee that
the memory block to which xp points
hasn't been overwritten. */
return xp.q;
}
即使影響提前釋放內存范圍的代碼已本地化，內存的使用仍然可能取決于應用程序甚至(在極端情況下)不同進程中的其他執(zhí)行位置。
懸空指針可能發(fā)生在以微妙方式使用內存的代碼中。結果是，即使內存在釋放后立即被覆蓋，并且新指向的值不同于預期值，也很難識別出新值是錯誤值。懸空指針不斷威脅著 C 或 C++ 程序的運行狀態(tài)。
內存編程的策略
清單 6. 識別資源的源代碼示例
/********
* ...
*
* Note that any function invoking protected_file_read()
* assumes responsibility eventually to fclose() its
* return value, UNLESS that value is NULL.
*
********/
FILE *protected_file_read(char *filename)
{
FILE *fp;
fp = fopen(filename, "r");
if (fp) {
...
} else {
...
}
return fp;
}
/*******
* ...
*
* Note that the return value of get_message points to a
* fixed memory location. Do NOT free() it; remember to
* make a copy if it must be retained ...
*
********/
char *get_message()
{
static char this_buffer[400];
...
(void) sprintf(this_buffer, ...);
return this_buffer;
}
/********
* ...
* While this function uses heap memory, and so
* temporarily might expand the over-all memory
* footprint, it properly cleans up after itself.
*
********/
int f6(char *item1)
{
my_class c1;
int result;
...
c1 = new my_class(item1);
...
result = c1.x;
delete c1;
return result;
}
/********
* ...
* Note that f8() is documented to return a value
* which needs to be returned to heap; as f7 thinly
* wraps f8, any code which invokes f7() must be
* careful to free() the return value.
*
********/
int *f7()
{
int *p;
p = f8(...);
...
return p;
}
硬件檢查器在這整個領域中，我始終認為最有用并且投資回報率最大的是考慮改進源代碼的風格。它不需要昂貴的代價或嚴格的形式;可以始終取消與內存無關的段的注釋，但影響內存的定義當然需要顯式注釋。添加幾個簡單的單詞可使內存結果更清楚，并且內存編程會得到改進。
我沒有做受控實驗來驗證此風格的效果。如果您的經歷與我一樣，您將發(fā)現(xiàn)沒有說明資源影響的策略簡直無法忍受。這樣做很簡單，但帶來的好處太多了。
檢測是編碼標準的補充。二者各有裨益，但結合使用效果特別好。機靈的 C 或 C++ 專業(yè)人員甚至可以瀏覽不熟悉的源代碼，并以極低的成本檢測內存問題。通過少量的實踐和適當?shù)奈谋舅阉?，您能夠快速驗證平衡的 *alloc()和 free()或者 new和 delete的源主體。人工查看此類內容通常會出現(xiàn)像清單 7中一樣的問題。
清單 7. 棘手的內存泄漏
static char *important_pointer = NULL;
void f9()
{
if (!important_pointer)
important_pointer = malloc(IMPORTANT_SIZE);
...
if (condition)
/* Ooops! We just lost the reference
important_pointer already held. */
important_pointer = malloc(DIFFERENT_SIZE);
...
}
希望讓您的代碼無 lint。盡管 lint已過時，并有一定的局限性，但是，沒有使用它(或其較高級的后代)的許多程序員犯了很大的錯誤。通常情況下，您能夠編寫忽略 lint的優(yōu)秀的專業(yè)質量代碼，但努力這樣做的結果通常會發(fā)生重大錯誤。其中一些錯誤影響內存的正確性。與讓客戶首先發(fā)現(xiàn)內存錯誤的代價相比，即使對這種類別的產品支付最昂貴的許可費也失去了意義。清除源代碼?，F(xiàn)在，即使 lint標記的編碼可能向您提供所需的功能，但很可能存在更簡單的方法，該方法可滿足 lint，并且比較強鍵又可移植。
由于這些原因，我們催促 C 和 C++ 程序員為解決內存問題先了解一下自己的源。在這完成之后，才去考慮庫。
使用幾個庫能夠編寫常規(guī)的 C 或 C++ 代碼，并保證改進內存管理。Jonathan Bartlett 在 developerWorks 的 2004 評論專欄中介紹了主要的候選項，可以在下面的參考資料部分獲得。庫可以解決多種不同的內存問題，以致于直接對它們進行比較是非常困難的;這方面的常見主題包括垃圾收集、智能指針和智能容器。大體上說，庫可以自動進行較多的內存管理，這樣程序員可以犯更少的錯誤。
我對內存庫有各種感受。他們在努力工作，但我看到他們在項目中獲得的成功比預期要小，尤其在 C 方面。我尚未對這些令人失望的結果進行仔細分析。例如，業(yè)績應該與相應的手動內存管理一樣好，但是這是一個灰色區(qū)域——尤其在垃圾收集庫處理速度緩慢的情況下。通過這方面的實踐得出的最明確的結論是，與 C 關注的代碼組相比，C++ 似乎可以較好地接受智能指針。
本文主要討論了基于軟件的內存工具。還有硬件內存調試器;在非常特殊的情況下(主要是在使用不支持其他工具的專用主機時)才考慮它們。
市場上的軟件內存工具包括專有工具(如 IBM Rational Purify 和 Electric Fence)和其他開放源代碼工具。其中有許多可以很好地與 AIX 和其他操作系統(tǒng)一起使用。
所有內存工具的功能基本相同：構建可執(zhí)行文件的特定版本(很像在編譯時通過使用 -g標記生成的調試版本)、練習相關應用程序和研究由工具自動生成的報告。請考慮如清單 8所示的程序。
清單 8. 示例錯誤
int main()
{
char p[5];
strcpy(p, "Hello, world.");
puts(p);
}
結束語
逆鋒起筆是一個專注于程序員圈子的技術平臺，你可以收獲最新技術動態(tài)、最新內測資格、BAT等大廠的經驗、精品學習資料、職業(yè)路線、副業(yè)思維，微信搜索逆鋒起筆關注！
評論
圖片
表情