love in C++, live on MFC

關(guān)于GetBuffer/ReleaseBuffer,網(wǎng)上比較流行的一種說法是:如果你要直接修改CString的內(nèi)部數(shù)據(jù),就要調(diào)用GetBuffer/ReleaseBuffer.我也同意這樣的表述.

下面是幾個(gè)例子,主要是錯(cuò)誤的例子,來加深理解.
1
這種用法當(dāng)然沒有錯(cuò),但是我認(rèn)為這里的GetBuffer/ReleaseBuffer是沒有必要的,為什么呢?因?yàn)?br />int __cdecl atoi(const char *) 的參數(shù)是const char*,CString的內(nèi)部數(shù)據(jù)肯定不會被修改的.
所以上面的代碼可以直接寫成
順便說一下GetBuffer的參數(shù)問題,網(wǎng)上的例子中,很多都是GetBuffer(5) GetBuffer(10)這樣的常數(shù),實(shí)際中的程序不可能是這么容易事先知道的,所以也就有了strTest.GetBuffer(strTest.GetLength() )的寫法.其實(shí),GetBuffer(0)就可以了.可以由GetBuffer的源碼得到驗(yàn)證.

2
運(yùn)行上面的代碼,可以看到strTest的值也變了,呵呵,這就是程序中一些關(guān)與CString的奇怪問題的起源.如果用注釋中的GetBuffer/ReleaseBuffer方法,就一點(diǎn)問題也沒有了.
同樣,對于ReleaseBuffer的參數(shù),缺省的是-1,但是我不建議.因?yàn)?1表示使用當(dāng)前的00結(jié)束符位置來確定新的長度.而上面的例子中,strtok是會重新設(shè)置00結(jié)束符的,所以,安全的做法,就是把這個(gè)CString的長度設(shè)為0,ReleaseBuffer(0),反正它的內(nèi)容已經(jīng)變了,也沒有人要用了.
說明一下,GetBuffer/ReleaseBuffer方法只能保證strTest不變,strTest2還是會變的.所以,對于一個(gè)成員變量,比如m_strTest2調(diào)用ReleaseBuffer要多一個(gè)心眼,局部變量就不用想這么多了.
那么怎么從最開始就意識到程序?qū)戝e(cuò)了呢?上面代碼中(char*)(LPCTSTR)是很危險(xiǎn)的,把const去掉了,否則strtok是編譯不過的,也從一個(gè)側(cè)面說明了const的重要性.

http://www.cpper.com/
那里論壇里的都是大牛，說的話我聽不懂，插不上嘴。

在《工作中發(fā)現(xiàn)的 》中，提到析構(gòu)函數(shù)可以自己調(diào)用，并用一個(gè)例子編譯、運(yùn)行證明了。
現(xiàn)在有個(gè)問題，除了知道“析構(gòu)函數(shù)可以自己調(diào)用”外，那么什么時(shí)候必須顯式調(diào)用析構(gòu)函數(shù)？

先看一段現(xiàn)實(shí)生活中的代碼吧，mfc源碼中：
在上面的代碼中，就有顯式調(diào)用CString的析構(gòu)函數(shù)的代碼。cool。
因?yàn)檫€調(diào)用了CControlBar::AllocElements()，上面的代碼不是很明顯，我把CControlBar::AllocElements簡化一下后：

BOOL CStatusBar::AllocElements(int nElements, int cbElement)
{
    // destruct old elements
    AFX_STATUSPANE* pSBP = _GetPanePtr(0);
    for (int i = 0; i < m_nCount; i++)
    {
        pSBP->strText.~CString();   //注意看這里
        ++pSBP;
    }

    // allocate new elements
    //if (!CControlBar::AllocElements(nElements, cbElement))
    //    return FALSE;
    //簡化后的代碼，實(shí)際運(yùn)行肯定有問題，但是關(guān)鍵東西出來了
    free(pSBP);//注意這里調(diào)用的是free
    pSBP = calloc(nElements, cbElement);

    // construct new elements
    pSBP = _GetPanePtr(0); //根據(jù)mfc的代碼，可以理解這里的pSBP和前面的pSBP還是同一個(gè)地址
    for (i = 0; i < m_nCount; i++)
    {
        memcpy(&pSBP->strText, &afxEmptyString, sizeof(CString));
        ++pSBP;
    }
    return TRUE;
}

這個(gè)時(shí)候，如果注意到我特別注釋的free函數(shù)調(diào)用，可能已經(jīng)意識到了為什么要顯式調(diào)用析構(gòu)函數(shù)了。
如果還沒有，那么可以問自己一個(gè)面試常規(guī)問題：delete和free有什么區(qū)別？答：delete會使析構(gòu)函數(shù)被調(diào)用。
或者反過來說，free沒有調(diào)用析構(gòu)函數(shù)，那么怎么辦？所以你必須自己顯示調(diào)用析構(gòu)函數(shù)。

上面的這個(gè)例子可以這樣抽象下，現(xiàn)在需要free掉一塊內(nèi)存，而那塊內(nèi)存中，還有一個(gè)類，類里面還有指針，（這里是CString）需要在析構(gòu)函數(shù)中釋放內(nèi)存。因?yàn)橛玫氖莊ree，所以那個(gè)類的析構(gòu)函數(shù)不會自動(dòng)被調(diào)用，這個(gè)時(shí)候，就必須顯式調(diào)用那個(gè)類的析構(gòu)函數(shù)。

這個(gè)是不是很偏的問題呢？遇到了就看看，沒有遇到過，也不會影響日常工作，哈。

另外繼續(xù)問個(gè)面試問題，new和calloc的區(qū)別？哈，構(gòu)造的函數(shù)的調(diào)用啊
所以，上面的代碼用的calloc，就必須顯示調(diào)用構(gòu)造函數(shù)啊，在哪里呢？就是
和CString的構(gòu)造函數(shù)比較下：
但是，為什么不就直接調(diào)用構(gòu)造函數(shù)呢？我也不知道。詳見dhong下面的評論。（dhong糾正了我的一個(gè)錯(cuò)誤）

不過，下面的代碼

是編譯不過的。

 

今天看java，提到這樣一種變量命名形式：
也就是說，在命名一個(gè)沒有太多實(shí)際意義的變量時(shí)，可以在前面加一個(gè)“a”。
呵呵，我覺得這種命名方法還是蠻好的，可能是我看書看的少，在c++的書中還沒有看到過這樣的寫法推薦。
而在msdn中，常見的例子為：
或者
呵呵，也是盡量寫一個(gè)名詞形式。

所以呢，新的寫法可以寫成


細(xì)小的問題，不用鉆牛角尖，好玩。

關(guān)于CString的兩個(gè)問題
讀CString,string,char*的綜合比較(一) 

1 CString的基類
在《比較》一文中，寫到：
“CString（typedef CStringT<TCHAR, StrTraitMFC<TCHAR>> CString）為Visual C++中最常用的字符串類，繼承自CSimpleStringT類，主要應(yīng)用在MFC和ATL編程中，主要數(shù)據(jù)類型有char(應(yīng)用于ANSI)，wchar_t(unicode)，TCHAR(ANSI與unicode均可)；”
我第一感覺就是文章寫錯(cuò)了，因?yàn)槲铱催^CString的源碼的啊：

但是看文章的樣子，也不像是粗制濫造的，心里很是疑惑。
后來再打開VC7的源碼看，果然：

看來微軟在不知不覺中做了這么大的變化。

2
“string是方便的，可以從幾乎所有的字符串構(gòu)造而來，包括CString和char*； 
 CString次之，可以從基本的一些字符串變量構(gòu)造而來，包括char*等； ”
的確，如下的代碼是可以編譯的：

但是這是表明string比CString方便嗎？
實(shí)際上，在string sTest(strTest);中有一個(gè)函數(shù)被調(diào)用，就是：

然后才是string構(gòu)造生成，這能說是string比CString方便嗎？應(yīng)該說是CString比string方便才好。
雖然可以用

來初始化CString，但是CString沒有參數(shù)為string的構(gòu)造函數(shù)，也是一個(gè)小小的遺憾，畢竟string是c++標(biāo)準(zhǔn)庫的一部分了。

當(dāng)我在運(yùn)行wizard,選到某一個(gè)類時(shí),遇到了這個(gè)錯(cuò)誤提示:
Parsing error : Expected "*/"
出錯(cuò)的代碼如下
  但是我看來看去沒有問題.

后來找到最初的代碼一對比,原來/* Leave Cell */中間有個(gè)空格, 是的wizard解析出錯(cuò),去掉空格就好了.哈

編譯結(jié)束時(shí)總是有個(gè)消息提示框出來,
"the .plg file has been modified outside of the source editor. Do you want to reload it?"
點(diǎn)yes或者no都還是不行,總是出來

問題的答案在
http://www.codecomments.com/Debugger/message500008.html
也就是在菜單window->Close All

文章來源:http://blog.csdn.net/flyingxu/archive/2006/02/12/597392.aspx

Code reviews are often misused and painful for everyone, but they don't have to be. Some simple steps can convert torture into teaching and improve the long-term outlook for code quality in your organization.
文章來源:http://blog.csdn.net/flyingxu/archive/2006/02/09/594974.aspx

class wizard出錯(cuò)與c++語法出錯(cuò)沒有關(guān)系

class wizard根據(jù)//{{來尋找插入函數(shù)的入口,所以,如果//{{出現(xiàn)的次數(shù)有多次,就出錯(cuò)了.
需要注意的是,幾時(shí)是被注釋掉的代碼,對class wizard也有影響,雖然編譯能通過.

參見http://www.codeguru.com/forum/archive/index.php/t-112218.html
Check that you have only one of each of these in MyClass.h:

//{{AFX_DATA(CMyClass)
//{{AFX_VIRTUAL(CMyClass)
//{{AFX_MSG(CMyClass)

...and that you have only one of each of these in MyClass.cpp:
//{{AFX_DATA_INIT(CMyClass)
//{{AFX_DATA_MAP(CMyClass)
//{{AFX_MSG_MAP(CMyClass)

文章來源:http://blog.csdn.net/flyingxu/archive/2006/02/09/594960.aspx

看了一篇blog文章“摘：VC編碼規(guī)范 ”（http://blog.csdn.net/lts007007/archive/2006/01/05/571377.aspx），有幾點(diǎn)意見：

函數(shù)名中用下劃線，我覺得不好，ceate_point()我覺得可以寫成CreatePoint()，這樣的風(fēng)格才是Windows API風(fēng)格，我覺得可以借用。
反擴(kuò)號的注釋內(nèi)容“}//end while(condition2)”我覺得完全多余，因?yàn)樵赩C環(huán)境中，可以用ctrl+]來定位括號之間的對應(yīng)關(guān)系
對于局部變量，我覺得不用寫l，如果一個(gè)變量不寫g或者m，那么它就是局部變量

不知道那篇blog時(shí)作者原創(chuàng)還是轉(zhuǎn)載，總的來說我覺得其中的VC規(guī)范不好（關(guān)于目錄結(jié)構(gòu)的還可以）。

文章來源:http://blog.csdn.net/flyingxu/archive/2006/01/08/573967.aspx