chemz

興趣是絕對(duì)重要的東西,只有它才能培養(yǎng)一個(gè)人做某件事情的信心和毅力,不可能每一個(gè)人對(duì)任何一件事情都能表現(xiàn)出興趣,所以也就不可能對(duì)任何一件事情表現(xiàn)出毅力。時(shí)間稍長興趣就失去了，那這種可能叫做熱情，不能稱之為興趣，因?yàn)榕d趣是較長時(shí)間的一種固定傾向，不能持續(xù)的不能叫做興趣，所以我覺得問題還是在于有沒有興趣的問題，不要將熱情和興趣劃等號(hào)。

謝謝大家

樓上的需要注意你可能在寫const wchar_t *wstr = L"中國";這句話時(shí)引號(hào)是個(gè)中文的，所以才會(huì)有問題。

樓上的建議非常的好，可以組建一個(gè)組委會(huì)，自發(fā)的總結(jié)一些常見的有意義的問題。

組委會(huì)招募開始......，有致力于從事公益事業(yè)的可以報(bào)名參與（回復(fù)一下就可以了）

繼承這個(gè)問題在我的博克http://m.shnenglu.com/chemz/archive/2007/06/12/26135.html中僅僅描述了虛擬繼承的內(nèi)容，其他內(nèi)容后續(xù)在表述

大家好，如果有興趣可以通過email的方式聯(lián)系chemz@263.net，附帶自己的簡歷和職位申請(qǐng)，如有需要會(huì)通過公司的名義約見各位，待遇面談，謝謝！

樓上提到：
public 是is a
private 是 has a

這個(gè)提法是OO概念發(fā)展的初期的一種認(rèn)識(shí)，有點(diǎn)過于一般化不能更精確的表達(dá)出OO中的實(shí)際思想；一般現(xiàn)在的OO理論中將這樣的概念稱之為LSP(Liskov Substitution Principle)，意思就是從行為上而言子類因該可以完全替換基類完成基類的行為職責(zé)。
public關(guān)鍵字在C++中僅僅只是一個(gè)語法元素，并不能強(qiáng)制使得采用了public繼承的類體系一定滿足LSP，其中還要看看子類在實(shí)現(xiàn)基類的接口行為時(shí)是否遵從了LSP原則，否則通過public繼承而來的子類仍然不能稱之為其滿足LSP，當(dāng)然此時(shí)可能能夠滿足is a關(guān)系。
至于has a關(guān)系在OO中應(yīng)該理解為composite關(guān)系，也就是常說的組合關(guān)系，在其他的OO語言中（如：Java）composite僅僅能夠通過包含關(guān)系來實(shí)現(xiàn)，在C++中則多了一種所謂的實(shí)現(xiàn)繼承private，這樣看來private僅僅只是一種特定語言的實(shí)現(xiàn)手段而已，代表的OO概念沒有區(qū)別。
protected在繼承時(shí)又應(yīng)該是什么呢？其實(shí)如上面private具有相同的含義，僅僅只是為了方便C++類方法的傳遞調(diào)用而設(shè)計(jì)的，也是一種composite關(guān)系而已。
至于virtual繼承關(guān)系請(qǐng)參看 http://m.shnenglu.com/chemz/archive/2007/06/12/26135.html

你的這個(gè)問題應(yīng)該是環(huán)境變量沒有正確的設(shè)置導(dǎo)致的，請(qǐng)仔細(xì)核對(duì)VC、QTDIR、PATH環(huán)境變量

分析的不錯(cuò)，DDD是必須要做的一個(gè)步驟，而用戶的需求可以認(rèn)為是在用戶領(lǐng)域模型下的一種增值業(yè)務(wù)。

我深信一句話：“性格決定命運(yùn)”，而根據(jù)人類社會(huì)學(xué)中的概念，性格的形成來自于兩個(gè)因素：其一、父母的遺傳（這個(gè)部分不可改變）；其二、后天的教育（這個(gè)部分一旦形成也不可改變）。也就是說命運(yùn)從一出生就被確定了一半，后天的教育（大學(xué)及以前）一旦完成也就不可改變了，那么其實(shí)想改變一個(gè)人的命運(yùn)基本上是不可能的。

在Open Source陣營當(dāng)中，沒有一個(gè)軟件會(huì)聲稱自己對(duì)質(zhì)量負(fù)責(zé)，Open Source是一種文化，你認(rèn)同就參與和使用，不認(rèn)同就不要使用否則對(duì)自己是一種折磨，沒有好壞之分，就如同一個(gè)人的性格特征一樣，沒有好壞。

不好意思，你可以到網(wǎng)絡(luò)上去搜索，很容易找到的

變化是有的，沒有那么的翻天覆地，快捷鍵肯定有變化，就和Visual Studio.NET相對(duì)于Visual Studio98那樣沒有多大的關(guān)系啦

MSTP多業(yè)務(wù)傳輸平臺(tái)，沒錯(cuò)，想給我介紹工作么？

不好意思我沒有用過Sun的CC，凡是在Unix環(huán)境下開發(fā)我們都用統(tǒng)一的GNU gcc編譯器集合，這樣會(huì)比較好移植。

離開是新的開始，新的開始為下一次離開做好了準(zhǔn)備

你用的什么編譯器，GNU還是Sun的？

我在搞solaris的時(shí)候也遇到過這個(gè)問題，我所在的環(huán)境是solaris9和10對(duì)于8我不太清楚。是這樣的，在solaris的操作系統(tǒng)安裝光盤中有一張單獨(dú)的Languages語言支持光盤，必須要選擇安裝對(duì)應(yīng)的字符集支持，如果要顯示中文還必須要切換操作系統(tǒng)的當(dāng)前語種到中文（任意一種中文都沒有問題，最好采用GB18030，否則會(huì)出現(xiàn)有些生僻的字沒有編碼的問題），這樣就可以轉(zhuǎn)換和顯示了。對(duì)于solaris8沒有試過，因?yàn)楸容^老了。

http://m.shnenglu.com/chemz/archive/2007/05/31/25189.html文章中jazz提到的那段代碼為何編譯出錯(cuò)的原因在這篇文章中可以找到。
根據(jù)文章中的語義小節(jié)，虛基類的子對(duì)象必須要在每一個(gè)子類中都包含初始化語句所以，僅僅有Usable是虛基類的友元是不行的，還必須將D作為虛基類的友元。如下：
class Usable;
class D;

class Usable_lock {
friend class Usable;
friend class D;
private:
Usable_lock() {}
Usable_lock(const Usable_lock&) {}
};

class Usable : public virtual Usable_lock {
// ...
public:
Usable();
Usable(char*);
// ...
};

Usable a;

class DD : public Usable { };

DD dd;

是的，safe code是在Visual C++2005以上版本添加上去的。visual C++.NET2003中的STL庫已經(jīng)非常的不錯(cuò)了，標(biāo)準(zhǔn)兼容性也很好。我最開始使用2003的時(shí)候使用了STLport4.6.2替換了2003中的STL實(shí)現(xiàn)，感覺還不錯(cuò)的

bjam "sTOOLS=vc-7_1" --prefix=D:\Boost install
你的命令寫錯(cuò)了看到?jīng)]有，仔細(xì)對(duì)比一下；
無法找到windows.h應(yīng)該是VC的環(huán)境變量沒有運(yùn)行的原因

稍后我會(huì)寫一篇關(guān)于虛繼承和虛基類的文章，解釋你所提到的問題。

"空明流轉(zhuǎn)"提到編譯上由于Visual C++2005的Safe Code會(huì)產(chǎn)生很多的警告信息，不會(huì)對(duì)代碼產(chǎn)生任何的影響，關(guān)掉這些警告可能會(huì)比較的順眼，謝謝！

在Visual Studio.NET 2003下編譯boost1.33.1的命令行：
bjam "-sTOOLS=vc-7_1" stage
就可以了，只是這個(gè)版本的regex庫中有一個(gè)文件中包含了非法的注釋字符串，會(huì)導(dǎo)致編譯錯(cuò)誤。
具體解決辦法如下：
libs/regex/src/目錄下的一個(gè)regex_traits_defaults.cpp文件中包含有ANSI編碼無法包含的字符集，所以會(huì)導(dǎo)致編譯的時(shí)候出現(xiàn)錯(cuò)誤，要解決該問題可以將該文件用notepad.exe程序打開，將其中的/*?/字符串替換掉就可以了，對(duì)于VC8還要將config/compiler目錄下的visualc.hpp文件中的第58行移動(dòng)到71行的下面。

虛基類是虛擬繼承下的基類，抽象基類ABC（Abstruct Base Class）是包含有純虛函數(shù)的基類。虛基類在繼承時(shí)會(huì)在其子類中加入虛基類偏移指針，而ABC會(huì)由于具有虛函數(shù)而類中包含了vptr。

樓上的提的非常好。
在面向?qū)ο蟮睦碚撝杏袃煞N概念：接口、實(shí)現(xiàn)，所以就出現(xiàn)了所謂的接口繼承和實(shí)現(xiàn)繼承兩種關(guān)系。而protected和private就是實(shí)現(xiàn)繼承中所要用到的，其實(shí)protected和private兩者則約束繼承時(shí)并沒有形成兩種不同的繼承類別，而僅僅只是為了方便C++類方法的傳遞調(diào)用而設(shè)計(jì)的，其實(shí)在java這樣面向?qū)ο笠蟾鼮閲?yán)格的語言當(dāng)中，沒有實(shí)現(xiàn)繼承，他必須通過委托方式來完成這一概念，如果熟悉java就會(huì)明白，如果一個(gè)對(duì)象要使用另外一個(gè)對(duì)象的接口功能，而自身又不能夠充當(dāng)該對(duì)象所扮演的角色時(shí)，就會(huì)通過委托來完成，這樣一來就必須在對(duì)象中包含一個(gè)委托對(duì)象，通過對(duì)象調(diào)用語法來完成功能；在C++中就可以通過protected和private繼承來完成java中的委托關(guān)系（當(dāng)然C++也可以形成對(duì)象委托關(guān)系），那么這種情況下protected繼承就容許委托可以傳遞（也就是被多級(jí)子類調(diào)用），而private繼承是不容許委托被傳遞的。
區(qū)別就這些。

非常感謝指出，書寫時(shí)漏了L，謝謝！

重載就是為了解決用相同的函數(shù)名稱來引用不同的函數(shù)體而設(shè)計(jì)的，上面的方法時(shí)間上就不算什么重載函數(shù)了，通過def文件將重載函數(shù)的每一個(gè)實(shí)例重新選取了一個(gè)C語言中的名稱

膚淺了點(diǎn)，編譯單元是編譯器在一次編譯過程所對(duì)應(yīng)的編譯狀態(tài)集；比如：如果在b.cpp中包含了a.cpp則在編譯b.cpp文件時(shí)會(huì)在編譯器的上下文形成一個(gè)編譯狀態(tài)集，稱之為一個(gè)編譯單元。

你的內(nèi)容中非常的強(qiáng)調(diào)了“CLI,最大的缺點(diǎn)是不人性.”，我想人性的本質(zhì)好像不是CLI和GUI的區(qū)別吧，不要給CLI扣上這樣的完全沒有碼頭的概念，你寫程序么？你使用XML么？那你會(huì)使用XML Spy中的可視化的方式來編寫大規(guī)模的XML文件么？好好想一想，人類在學(xué)習(xí)讀書時(shí)采用的就是一個(gè)基于字符的文檔，你會(huì)從小到大都看以圖片為主的圖書么？圖片和其他的可視化形式都僅僅只是人類在表達(dá)思想和傳播信息時(shí)的一種清晰的輔助手段而已，不要忘記了人類最基本的習(xí)慣和認(rèn)知。

深刻，boost的慣用法，通過function對(duì)象來將各種可以調(diào)用的實(shí)體（如：全局函數(shù)、成員函數(shù)、functor等）統(tǒng)一成為一種可調(diào)用對(duì)象。

這是一個(gè)非?；镜膯栴},在C/C++語言中所有的定義體都只能有一個(gè),不能夠在多個(gè)編譯單元中重復(fù)出現(xiàn),所以回出現(xiàn)重復(fù)定義的問題,要解決這個(gè)問題可以采用內(nèi)聯(lián)的方式解決,而C++中可以采用隱式內(nèi)聯(lián)和顯示內(nèi)聯(lián)兩種方式,隱式內(nèi)聯(lián)就是寫在類的申明中,顯示內(nèi)聯(lián)就是在聲明和定義出添加inline關(guān)鍵字.