去年的時候，由於某種原因，我需要將一個文件的二進制形式以文本的格式輸出到一個文本文件中，類似下面這個樣子：
4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00
B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 D0 00 00 00
0E 1F BA 0E 00 B4 09 CD 21 B8 01 4C CD 21 54 68
69 73 20 70 72 6F 67 72 61 6D 20 63 61 6E 6E 6F
74 20 62 65 20 72 75 6E 20 69 6E 20 44 4F 53 20
6D 6F 64 65 2E 0D 0D 0A 24 00 00 00 00 00 00 00
......
我想的很簡單：打開文件，讀取文件，用一個循環，對每個字節使用wsprintf，然後用lstrcat連接起來，寫文件，搞定。於是我很容易地得到了以下這段毫無語法錯誤的代碼：
// 注1：你可以將其中的幾個未定義變量理解為全局變量。
// 注2：NEW是我定義的一個宏函數，仿照了C++ 的operator new。
// #define NEW(type, count) (type *)(malloc(sizeof(type) * (count)))
void Save(void)
{
DWORD dwSize, dwReaded, i;
TCHAR szByte[5];
// 讀取源文件
hFileSrc = CreateFile(szFileSrc, GENERIC_READ, 0, NULL, OPEN_ALWAYS,
0, NULL);
dwSize = GetFileSize(hFileSrc, NULL);
lpbySrc = NEW(BYTE, dwSize);
ReadFile(hFileSrc, (LPVOID)lpbySrc, dwSize, &dwReaded, NULL);
// 下面的MYSIZE是一個指示緩沖區大小的宏，由於計算大小較為繁瑣且與本文無關，所以此處略去
lpDst = NEW(TCHAR, MYSIZE);
*lpDst = '\0';
for (i = 0; i < dwSize - 1; i++)
{
if (i % 16 == 15) // 處理換行
wsprintf(szByte, "%02X\r\n", lpbySrc[i]);
else
wsprintf(szByte, "%02X ", lpbySrc[i]);
lstrcat(lpDst, szByte);
}
// 處理最後一個字節
wsprintf(szByte, "%02X", lpbySrc[i]);
lstrcat(lpDst, szByte);
free(lpbySrc);
lpbySrc = NULL;
CloseHandle(hFileSrc);
// 保存到目標文件
hFileDst = CreateFile(szFileDst, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS,
0, NULL);
WriteFile(hFileDst, (LPCVOID)lpDst, lstrlen(lpDst) * sizeof(TCHAR),
&dwReaded, NULL);
free(lpDst);
lpDst = NULL;
CloseHandle(hFileDst);
}
當把這段代碼拉上陣的時候，我發現雖然它可以正常工作，結果也是我想要的，但是它處理文件的速度慢得出奇，甚至文件的大小相差幾十K都會有明顯的速度差距！我再次浏覽了一遍我的代碼，還是沒有發現什麼致命的錯誤。我靈機一動，心想還好我用的是GUI界面，於是我沒費多少力氣，在這個線程中加了幾行代碼和一個Progress
Bar，繼續編譯運行。
這次的結果出來了，我發現指示字節處理進度的那個Progress Bar越往後走進展速度越慢。我恍然大悟，打開了VC附帶的strcat源碼：
char * __cdecl strcat (char * dst, const char * src)
{
char * cp = dst;
while( *cp )
cp++; /* find end of dst */
while( *cp++ = *src++ ) ; /* Copy src to end of dst */
return( dst ); /* return dst */
}
這個過程很明了，先查找字符串末尾的結束符，然後再進行字符串的復制。那麼在我的代碼中，每完成一次循環，lstrcat就要不厭其煩地去尋找一遍結束符，然後再進行復制——這也就造成了很多無用功，也就是Progress
Bar越走越慢的原因。
在知道了硬傷所在之後，我決定以空間換時間——借用一個變量指向目標字符串的末尾，手動實現字符串的連接。於是我寫就了以下代碼：
void Save(void)
{
DWORD dwSize, dwReaded, i, j, k;
TCHAR szByte[5];
// 讀取源文件
hFileSrc = CreateFile(szFileSrc, GENERIC_READ, 0, NULL, OPEN_ALWAYS,
0, NULL);
dwSize = GetFileSize(hFileSrc, NULL);
lpbySrc = NEW(BYTE, dwSize);
ReadFile(hFileSrc, (LPVOID)lpbySrc, dwSize, &dwReaded, NULL);
// 下面的MYSIZE是一個指示緩沖區大小的宏，由於計算大小較為繁瑣且與本文無關，所以此處略去
lpDst = NEW(TCHAR, MYSIZE);
*lpDst = '\0';
j = 0;
for (i = 0; i < dwSize - 1; i++)
{
if (i % 16 == 15) // 處理換行
{
wsprintf(szByte, "%02X\r\n", lpbySrc[i]);
k = 4;
}
else
{
wsprintf(szByte, "%02X ", lpbySrc[i]);
k = 3;
}
lstrcpy(&lpDst[j], szByte);
j += k;
}
// 處理最後一個字節
wsprintf(szByte, "%02X", lpbySrc[i]);
lstrcpy(&lpDst[j], szByte);
free(lpbySrc);
lpbySrc = NULL;
CloseHandle(hFileSrc);
// 保存到目標文件
hFileDst = CreateFile(szFileDst, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS,
0, NULL);
WriteFile(hFileDst, (LPCVOID)lpDst, lstrlen(lpDst) * sizeof(TCHAR),
&dwReaded, NULL);
free(lpDst);
lpDst = NULL;
CloseHandle(hFileDst);
}
按說代碼寫到這裡也就該結束了，不過這個話題的確值得就此說開去——可以說，導致上文這種麻煩的“罪魁”，就是C-style string本身的“零結尾”機制。那麼我再列出一段代碼以供諸位一品：
void CString::ConcatCopy(int nSrc1Len, LPCTSTR lpszSrc1Data,
int nSrc2Len, LPCTSTR lpszSrc2Data)
{
// -- master concatenation routine
// Concatenate two sources
// -- assume that 'this' is a new CString object
int nNewLen = nSrc1Len + nSrc2Len;
if (nNewLen != 0)
{
AllocBuffer(nNewLen);
memcpy(m_pchData, lpszSrc1Data, nSrc1Len*sizeof(TCHAR));
memcpy(m_pchData+nSrc1Len, lpszSrc2Data, nSrc2Len*sizeof(TCHAR));
}
}
如你所見，這是MFC Framework中的CString源碼片斷。CString為了避免尋找結尾可能造成的尴尬，它的連接函數使用了memcpy而不是strcat/lstrcat，並且由參數給定的字串長度直接確定了字串的尾部位置。那麼，可以用CString::operator+=來完成上邊的操作嗎？
答案還是不可以。我的確說過CString避免了尋找結尾的尴尬，但是CString卻帶來了另外一個尴尬——重復復制的尴尬。CString::operator+=歸根結底是調用了上邊的CString::ConcatCopy，並且調用一次CString::ConcatCopy就意味著調用memcpy兩次，所以用CString::operator+=則是更得不償失的一種方法。
無論是C的字符串處理函數還是用C++構造的字符串類，都可以看作是一種“黑箱”。在一般情況下，用戶無需了解黑箱內部的實現機理，只要假設“黑箱”是完美的並直接使用就可以了。然而事實上黑箱本身並不是完美萬能的——即使這種黑箱是C/C++標准庫，也許令你摸不著頭腦的錯誤，就隱藏在那看似完美的黑箱背後。
