| 去年的时候，由于某种原因，我需要将一个文件的二进制形式以文本的格式输出到一个文本文件中，类似下面这个样子：
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++标准库，也许令你摸不着头脑的错误，就隐藏在那看似完美的黑箱背后。 |