挑選log模塊的時候 我還是喜歡方便格式化輸出的類printf方式，就象ace的log方式，iostream方式的進行格式化輸出太不方便了
re: 歷時14個月的修煉，略有感悟[未登錄] cppexplore 2008-01-05 14:39
祝福！
加油！！
re: 華為某牛人的超強言論.年輕的可以看看[未登錄] cppexplore 2007-12-28 11:32
敬佩一切成功人士
re: 【原創】我在成都當程序員 [未登錄] cppexplore 2007-12-26 11:07
原創 不錯！！ 這年頭 做什么都不容易
re: 慶祝我的C++博客開通[未登錄] cppexplore 2007-12-25 11:40
多多發些經驗 心得啊
re: 工作效率和薪水加倍的7個秘訣 [未登錄] cppexplore 2007-12-21 08:51
絕對正解
另外再加一條：工作時間不要瀏覽和工作無關的blog， just like this. 呵呵
re: 【原創】秀一秀我的陪測程序[未登錄] cppexplore 2007-12-19 16:34
@秦歌
呵呵 多多交流啊！
re: 心情壓抑[未登錄] cppexplore 2007-12-12 11:47
昨晚上的文章怎么消失了啊
呵呵 “浮士德” 想起大一的時光 陽光明媚的下午 去學校的閱覽室 坐在靠窗的位置看這本書 雖說整體是部悲劇 我還是喜歡里面上進的句子 從另一個層面上來看 它更象勵志小說。 不過那書真是厚啊 拿著象筆記本一樣沉
re: 一段代碼優化的討論[未登錄] cppexplore 2007-12-07 14:55
@LouixG
（1）這個問題不敢妄言，多核下編程重來沒有接觸過。不知道這種各個cpu的分配，是在編譯期間由編譯器完成的，還是在運行期間由額外的硬件決定把指令分配給某個cpu的？這種多核下的編程，值得探討的問題就多了，尤其這種在一個線程內的數據被分配到多個cpu，如果真有這種情況，估計以后會有語言層面的東西支持。不同線程分配不同的cpu，這個到還好。
（2）這個例子的高性能我絲毫不懷疑，通過字節對齊提高性能。其實標準庫函數也是這么做的。不過這個例子沒意義啊，直接使用庫函數就好。
re: 一段代碼優化的討論[未登錄] cppexplore 2007-12-07 12:35
@搞笑
這樣說就不對了 文章寫出來 大家share下 目的是互補長短 互相交流 互相進步
@笨笨
從本文中例子來說 這種“優化”，可讀性更好，更好維護。的確是正確的。這種差異不是算法的造成的，是開始設計的不合理。另，我的建議真的不是無聊的建議 ：）。
@LouixG
(1)展開循環的點滴性能不是問題
（2）多線程模型的目的一般系統設計層面的吧，主要是提高系統的吞吐能力，這種問題上的性能遠遠談不上
（3）后面的問題帶來移植性的問題，非底層的關鍵算法 也不會有人去做這種優化
@夢在天涯
blog里的文章真是多啊
@me
廢話真多。。。。。。
re: C++接口與實現分離的2種方法[未登錄] cppexplore 2007-12-07 12:17
第一種方式比較奇怪啊，感覺毫無意義啊
增加功能的角度有adapter模式
隔離的角度有proxy模式
第二種是典型的接口
re: C++內存泄露的檢測（四）[未登錄] cppexplore 2007-12-07 12:07
linux/unix下最強大的開源內存檢測工具是valgrind
re: 一段代碼優化的討論[未登錄] cppexplore 2007-12-07 08:28
根本原因要看編譯器 優化 后的匯編代碼
重構代碼的出發點是可讀性 可維護性 不是優化
系統性能依賴于設計階段 之后就是關鍵算法 性能工具檢測的性能瓶頸處了
re: 關于sizeof()的簡單解析 [未登錄] cppexplore 2007-11-16 11:57
@xmli
這是字節對齊問題，baidu、google搜索下 很多資料 不再copy了
re: 【原創】c++ server測試全攻略[未登錄] cppexplore 2007-11-16 11:39
@金慶
呵呵 不好意思 沒說明白
這里的顯式是說能被valgrind直接測試出來了
最終的內存泄漏還是要看穩定性測試的時候 占用的內存百分比不隨時間的增加而增長