@Kevin Lynx
這個問題后來我試過，在我的項目里（ 前面提到的，使用了VC6），問題出在使用singleton生成單個factory對象的地方。如果將factory的構(gòu)造函數(shù)設(shè)計為private，同時提供一個類get_instance()的public static方法，會產(chǎn)生多個factory實例。具體表現(xiàn)就是，register()函數(shù)的確執(zhí)行了， 但是所有的注冊內(nèi)容都注冊到了第一個factory對象身上，等到運行期使用create方法的時候，使用的卻是后面新生成的factory對象，因此會發(fā)生沒有注冊過的假象。

解決方法為：將factory()構(gòu)造函數(shù)聲明為public，在factory類外面定義一個singleton函數(shù)，并一直使用這個函數(shù)進行注冊與創(chuàng)建。但這種方法的缺點是你無法從語法上確保所有用戶使用的都是這個singleton對象。

懷疑為VC6的bug，不過由于已經(jīng)基本滿足了需要，未繼續(xù)深究。

你可以用&sname[0]， 如果覺得不安全可以用strdup(sname.c_str())， 會返回一個copy

@oldman
對， 無法區(qū)分跨多行的/**/注釋的后面部分

@simon
不，其實這個不容易看出來， 是因為網(wǎng)頁的名字叫peak.html，peak與pickle諧音，很扯的理由， 哈哈

@萬連文
哈哈， 現(xiàn)在哪高就呢？

兄弟你是完美的吧？ 這個框架我在內(nèi)部bbs上見過， 但rtx上怎么沒有你的名字呢？

@simon
你去看一個網(wǎng)頁的源代碼，里面有一個鏈接， 你點一下會出現(xiàn) and the next nothing is 92512， 替換Url里linkedlist.php?nothing=12345中的12345，然后再回車， 你就會發(fā)現(xiàn)規(guī)律了

@oldman
&str[0]的數(shù)據(jù)是可以修改的， 而str.data()的數(shù)據(jù)不能修改

判斷是否為奇偶數(shù)可以用(a&1)， 取最后一位，是0則為偶數(shù)，是1則是奇數(shù)

自己試了一把， 還真是這樣， 真悲劇啊

switch語句被匯編翻譯的結(jié)果與case的長度及數(shù)值規(guī)律有密切關(guān)系，并不是簡單的翻譯成跳轉(zhuǎn)表， 同時與編譯器的優(yōu)化能力也有關(guān)。

你可以看一下這篇文章：
http://www.shnenglu.com/besterChen/archive/2009/12/07/102682.html

沒看出來“偷懶的”三個字的含義是什么

@right

:) 跟vc6不能說關(guān)系大， 也不能說沒有關(guān)系。但就本篇所表達的思想講，您可以認為是獨立于vc6的

寶貴意見，非常感謝！

代碼是簡潔了， 但閱讀起來更費神了。為什么要寫成這樣呢？ 生成的匯編代碼應(yīng)該是一樣的

文章很好， 我也保留一份， 嘿嘿

留名，學(xué)習(xí)

@oldman
對您提出的意見表示感謝
但是， 這文章是轉(zhuǎn)csdn上的一篇帖子，帖子的地址您可以在文章的最開始處看到，基于尊重原創(chuàng)的想法，我覺得還是不要去修改的好。
再次表示感謝！

@fool
支持你一下， 哈哈

觀察者模式應(yīng)用起來的確有些復(fù)雜，也許你可以考慮仿寫一個c#的delegate，這樣的話可以支持多播， 而且編程實現(xiàn)上要簡單不少。

A arr[10]={0}; 的生成匯編中就調(diào)用了memeset，但前者比后者還多了一個賦值，因此還要稍慢一點 :D

@classyk
我的理解：volatile const其實是變量可以不可預(yù)期的被程序以外的環(huán)境所改變，而對于相同的一段程序內(nèi)部而言，這樣聲明并不能使你有更好的方式可以修改此變量的值

@vincent
在默認情況下，其實不是這樣的。
const 修飾內(nèi)置數(shù)據(jù)類型時，比如const int a= 10; 則a是一個編譯期常量，因此你可以進一步定義int b[a]= {0}; 在編譯意味著它沒有內(nèi)存地址（這是一個運行期的概念），因此并不存在放置于只讀數(shù)據(jù)段的現(xiàn)象。

只所以說是“默認情況”，是因此在更復(fù)雜的情況下const常量對象是需要分配內(nèi)存的，比如說文章中出現(xiàn)的取其地址的時候，再比如定義更加復(fù)雜的集合對象的時候。

@冬瓜
可不僅僅是這樣的，對于修飾為const的變量，編譯器可能會去做一些處理，表現(xiàn)在有無const，最終生成的匯編代碼很可能是不同的

@airtrack
受教了， 呵呵， 第一次聽說這個詞， 謝謝

這個對比非常好， 呵呵

@陳梓瀚(vczh)
這是為什么？ 好像stlport中std::string的operator= 就是用memcpy實現(xiàn)的吧

fastdelegate, 前兩天還真看見公司的一個項目上用到它了， 看實現(xiàn)應(yīng)該很快，不過可惜的是不支持多播

@星綻紫輝
呵呵， 受教了

@冬瓜
是這樣的， 大家覺得如果直接用shared_ptr的話就沒有必要寫一個delete_null函數(shù)了

@Jeff
沒有， 非常歡迎你的評論。大家的回復(fù)讓我想了很多，這些都是非常意外而重要的收獲。

其實， 最直接的問題是：我沒有權(quán)利在項目中引入一個像boost 這樣大的庫，因此這不但限制了應(yīng)用，也限制了我的眼界。

@陳梓瀚(vczh)
看了這么多回復(fù)， 如果我沒想錯的話，是不是大家都推崇使用shared_ptr替代原始對象指針？如果多數(shù)人都這認為的話，那肯定是有道理的。如你所言，看來有時間我得去仔細研究一下shared_ptr了。

我現(xiàn)在能想到的問題是，假如我自己寫了一個shared_ptr加入到了舊的項目中，那么所有其它使用該對象的地方（包括參數(shù)）是否都必須帶著shared_ptr<T>的聲明呢？

感謝回復(fù)，不忙的時候研究一下。

@空明流轉(zhuǎn)
我所指的“不穩(wěn)定”是指boost一直在開發(fā)，里面有長期積累下來的庫，也有新加入的庫，只是加入到項目中，新庫在未證明其穩(wěn)定性之前也有可能被使用，而這可能導(dǎo)致一些問題。

另外， 你說得對，相比于資源的分配與回收，shared_ptr的開銷是可以忽略的，但我們的系統(tǒng)中現(xiàn)在還沒有這樣的機制，而且我說過了，真正的原因是我尚未發(fā)現(xiàn)讓我不得不用它的理由。

最后， 我其實是很贊同使用RAII的，實際上，我們已經(jīng)在陸續(xù)使用它了。

感謝回復(fù)！

@Jeff
唉， 這批評還真犀利呀！
1. 不直接使用boost中的智能指針最直接的原因是boost不穩(wěn)定，而且并不是boost中的所有特性都對項目有幫助的。你可能會問為什么我不自己實現(xiàn)一個，一個類似于shared_ptr的東西，除了那一點性能損失外，真正的原因是我還沒有發(fā)現(xiàn)讓我不得不用的理由。而且，項目中有很多地方是不能直接調(diào)用析構(gòu)函數(shù)的，而是需要單獨寫一個Destroy的函數(shù)，因為時機。
2. 關(guān)于異常安全，我想，如果析構(gòu)函數(shù)本身是異常安全的話，那么我的代碼本身應(yīng)該算異常安全了吧？反之，如果析構(gòu)函數(shù)本身不安全的話，那無論采用什么方法析構(gòu)都是有問題的。

如果我的想法有什么問題的話，請不吝指正，非常感謝。

直接輸入行號按下G就可以跳轉(zhuǎn)到指定行

好文章， 非常細致

memset是一種高效的數(shù)組初始化方式，它本身是用匯編寫的，vc下應(yīng)該是位于memset.asm中，當你使用部分初始化時， 比如int a[100]={0}， 你會看到它的匯編代碼其實用的就是memset。

把sqrt(N)拿到外面那個， 你不覺得你的代碼中每次循環(huán)sqrt(N)都會調(diào)用一遍嘛？當然， 現(xiàn)代編譯器的話，這種簡單的調(diào)用可以被優(yōu)化掉，但作為碼農(nóng)， 你不應(yīng)該寫成這樣

不要使用using namespace std; 因為std命名空間里的東西全是一些常見的名字， 像string, vector, list等等，直接使用std::string，以防止重名

#define N 100可以使用const常量代替（并且，盡量放到一個空的namespace下），否則你需要定義成#define N (100)，加括號，這是常識

prim[i]=true;的那個循環(huán)可以改成memset(&prim, 1, sizeof prim)

for(i=2;i<=sqrt(N);i++)---請把sqrt(N)拿到循環(huán)外面來

看你寫代碼的樣子，應(yīng)該是vc6吧，把int i,j;放后面點吧，不過在在未使用的地方就定義變量，比如int j完全可以放到循環(huán)內(nèi)部定義

分得太細反而著了相， 不要太看重語法上的區(qū)別，這些東西都是基于應(yīng)用而衍生的，多研究一些設(shè)計的東西， 比仔細區(qū)分這些語法概念要合算

-__-看不出來

@金慶
不好使
我想應(yīng)該是這個問題：
Only problem is that the symbol is not very...simple. I have a class called fxAttributeEditor, but you can't just do /include:fxAttributeEditor. The symbol is actually:

??_C@_0BC@OFGGEBAJ@fxAttributeEditor?$AA@

And that does work, but having to add that seems like a terrible coding decision. It seems like going the dynamic library route would be far better. I've had a variety of really good reasons for not wanting to do that. I'm not against DLLs, but in some cases (like mine) I don't believe it's the best choice. Is there not any better way to go about this?

Thanks,

這是引用原文， 大概意思是“不能夠在#pragma comment(linker, /include:)中直接使用你定義的那個變量名”，因為c++編譯時會將其改為??_C@_0BC@OFGGEBAJ@fxAttributeEditor?$AA@這樣的的形式。

我不知道是不是真的這樣， 但我的實驗結(jié)果是找不到我自己定義的變量名

我以前也試過這樣的方法， 項目用的是vc6，只debug版本下對象是可以生生的，release版本中就被人優(yōu)化掉了，沒有找到保持這種級別低耦合度的替代方案。
到現(xiàn)在為止， 我寫的那個factory類再也沒有用過，因為看不到優(yōu)勢在哪里， 還不如現(xiàn)寫一個工廠來得清晰

@xu
提供功能性接口，去完成有意義的操作，盡可能的不要暴露數(shù)據(jù)成員

厲害， 這都行

這種題只能拿來隨便練練， 每個面試官都會出自己的題

@free2000fly
這個是單播的、面向編譯器的

@foxriver
呀，意外之喜，同樣謝謝你，哈哈

@guest
好， 謝啦

@OwnWaterloo
不過你說的那三種語法中的第三種，VC6肯定支持，呵呵，現(xiàn)在正在向第二種努力

@OwnWaterloo
恐怕暫時不會去試boost了，其實我到想，但公司明確禁止在項目中使用boost。我曾經(jīng)試過，被上司否定了

@陳梓瀚(vczh)
我也不想用啊，但我只是個兵啊，這不是沒有辦法么，呵呵