@xcj
多謝回復。

vim、emacs的強大之處，我并沒有否認，我現在還在用vim編輯很多東西，但是我已經過了狂熱的那個時候了，我不會用vim來編輯C/C++代碼，畢竟有比vim和emacs更好的IDE，我自然是優先使用它們。我也同樣使用emacs + paredit來寫scheme代碼，但是我不會用emacs編輯其他文件，因為有vim和更好用的IDE，我現在是哪個編輯適合編輯哪種類型的文件，我就使用哪個編輯器。至于你說的混淆IDE和編輯器，我不知道我文中哪里有把他們混淆，我說的很多人說這些編輯器可以通過插件完成各種功能，都是停留在理論里，實際效果并不好，而很多人用個編輯器都能產生優越感。

對于MBA，我只說過死了兩次機，但是我并沒有說它不好，相反它是我用過的筆記本里最好的，我最近兩年的時間基本都在使用MBA。我所說的是那些用了個MBA和MBP就產生優越感的人。

對于C/C++的問題，對于我這個從C語言入門程序設計的人來說，我還是有自信自己能寫出基本合格的C程序的。C++程序員不合格的多，但是我還是見過幾個真人（身邊的）能寫出合格的C++程序，而對于寫出合格C程序的程序員，在我身邊我目前還沒見過（我所在的公司的部門一直以來都寫C為主），當然你可以說我的層次比較低，我確實沒見過活的寫C程序牛逼的程序員。

另外技術的優越感一說，這就是跟我公司環境有關了，這個我只能說你對我的評價太過武斷了。

對于你說的最后一句話，這一直都是我的寫程序的基本原則。而我說的那些帶有優越感的人，才應該學習你這句話。

@陳梓瀚(vczh)
哈哈，早知道陳祖寫過正則引擎的系列文章，一直沒看，是想在我自己思考之后如果遇到問題的時候再看，啊哈哈。

膜拜空明巨巨！

@zenk

OP_VARARG這條指令就是訪問...參數的，可以看到用
int n = cast_int(base - ci->func) - cl->p->numparams - 1;
來計算可變參數變參的個數（cl->p->numparams是這個函數的固定參數的個數），接下來在判斷B參數是否為0，如果為0，那就有多少個變參就復制多少個，不然就復制B - 1個變參。在lua中如下代碼會生成OP_VARARG指令：
function f(...)
print(...)
end

至于arg變量，在lua 5.2中已經不會自動打包可變參數...為一個arg變量，在lua 5.2中要使用arg變量可以這樣寫：
function f(...)
local arg = table.pack(...)
end

@zenk
我對這段描述不夠清楚，現在已經補上了。

復制的只是固定的那些參數，"..."所代表的變參并沒有復制，保留在base指針前面，這樣可以保證后續指令訪問固定的那些參數和非可變參數函數是一致。

同感吶。

@LOGOS
筆記本你就沒辦法用手掌左側了。

匈牙利命名法的一個及其明顯的弊端，比如：
開始定義了一個 int nSize;使用了一段時間后，被后面維護代碼的人因為某種需求改成了DWORD（或者其它類型），那是不是這個變量也要跟著改成dwSize才能符合匈牙利命名法，但是如果這個變量被很多地方使用，改起來豈不是很麻煩。雖然可以通過VA來rename，但是在團隊開發中，團隊成員不一定會去把變量名同步修改。
當然這只是個例子。
另一方面我非常贊同空明流轉兄，我覺得變量類型編譯時期就確定了，沒有必要這么去在變量名里面暴露類型。而對于動態語言的話，那類型更加不確定，隨著運行的過程，變量可以是任意類型，所以我覺得變量是要表達你所要代表的意思而不是類型。像上面那個例子的變量名為size就行，表達出它的作用就行，當然可能還會具體些，命名為xxx_size。
在C++模板中，模板中的代碼類型更加不確定了，自然不能把類型寫到變量名中。

1、四格縮進，整體簡潔統一，函數不要太長，一般不超過30行。
2、只要是非匈牙利命名法覺得都可以（最討厭匈牙利命名法，看了《觀止》之后發現卡特勒也很討厭它，我就更加堅定了），比較喜歡google的命名方式。
3、邏輯簡潔，函數和類單一職責，RAII，個人比較傾向使用異常，異常能夠讓代碼更整潔的處理錯誤。當然公司的話，看項目是怎么定的了。

特別希望其他人提交到庫里面的代碼沒有注釋掉的代碼，最討厭看到注釋掉的代碼。函數不要太長，類不要太大，一切都是為了單一職責。
被強加的規則，好的接受，不喜歡的也得接受，因為自己不是老大。

Windows上開發的程序個人傾向靜態鏈接，一是用的都是最新的VS（目前用VS2010），為了讓程序在沒有裝CRT機器上運行；二是個人開發的程序不大，靜態鏈接體積也大不了多少。
公司開發一般都是動態鏈接。

“加上volatile關鍵字后在gcc上就能得到正常的結果了”什么是你想要的正常結果？既然標準既沒有規定求值順序，那你的想要的"正常結果"即使在你使用了某種特殊的方法后得到了，那換了一個編譯器之后也不一定就是你想要的。標準沒有規定求值順序，決定權自然是有各個編譯器掌握，而gcc自然有權利決定加volatile和不加volatile的結果是否相同。

這個跟volatile沒關系的，int m = (++z) + (++z) + (++z);這個東西的求值順序標準沒有規定，不同編譯器的實現是不同的。

標準沒有規定先對哪個求值，完全由編譯器決定，而對于這種標準未定義的東西，沒必要去浪費時間，你只需知道求值順序不確定就行，在實際編碼中就不應該出現這樣的代碼。
PS:其實你可以BS下出這種題目的人。

@lv
恩，基于libtorrent的軟件很多，Deluge就是其中之一。

額，還是膜拜下。

繼續膜拜大神！

保持隊形，膜拜大神啊！

@陳梓瀚(vczh)
不定參數模板是可以實現Tuple的，可以看看gcc 4.5的Tuple的實現，它就是用的不定參數模板來做的。

@cexer
@陳梓瀚(vczh)
兩位都說的不錯，自身的提高都是通過自我否定之后，重新定一個新的目標來達到的。

Loki::ScopeGuard實際上是一個通用的RAII，它是通過在ScopeGuardImplBase的所有派生類的析構函數里面SafeExecute(*this)來做到RAII，而在SafeExecute做資源釋放操作是通過調用派生類的fun_，如果不try...catch，那么fun_執行如果發生異常的話，那異常就逃離了析構函數。在C++中析構函數是不應該有異常產生的，詳見《Effective C++》。

單元測試最好是在項目初期就使用，項目已經到后期的才做單元測試性價比不高，尤其是各個模塊間的耦合很大時很難做單元測試。項目開始就用單元測試可以幫助降低模塊的耦合。

@expter
可以啊，這個調試器主要就是用來調試作為C++擴展的Lua。

@megax
像ctags這種僅僅是提取token來作提示只能應付簡單C語言程序，復雜一點的C++程序，多點template，多點typedef，ctags分析的那些東西就費掉了，個人覺得要做好智能提示必須通過語法分析來做。所以有些vimer和emacser才會不滿于ctags和etags這些東西，CEDET這種東西才會出現，不過比起VA來說還是差遠了。

google常量折疊

@陳梓瀚(vczh)
C++的一個哲學就是讓類庫盡可能的提供功能，為了達到這個目標，不同的語法就必需盡可能正交，而且功能強大到到處都可以插入callback，從而寫出高質量而且語法優美的類庫了。所以正確的使用方法應該是大規模使用stl和boost，而不是直接使用C++去構造所有東西。
====================================================
贊同，這段話讓我想起了《C++ 沉思錄》中說的：語言設計就是庫設計，庫設計就是語言設計。