CppExplore

挑選log模塊的時(shí)候 我還是喜歡方便格式化輸出的類printf方式，就象ace的log方式，iostream方式的進(jìn)行格式化輸出太不方便了

祝福！
加油！！

敬佩一切成功人士

原創(chuàng) 不錯(cuò)！！ 這年頭 做什么都不容易

多多發(fā)些經(jīng)驗(yàn) 心得啊

絕對(duì)正解
另外再加一條：工作時(shí)間不要瀏覽和工作無關(guān)的blog， just like this. 呵呵

@秦歌
呵呵 多多交流啊！

昨晚上的文章怎么消失了啊

呵呵 “浮士德” 想起大一的時(shí)光 陽光明媚的下午 去學(xué)校的閱覽室 坐在靠窗的位置看這本書 雖說整體是部悲劇 我還是喜歡里面上進(jìn)的句子 從另一個(gè)層面上來看 它更象勵(lì)志小說。 不過那書真是厚啊 拿著象筆記本一樣沉

@LouixG
（1）這個(gè)問題不敢妄言，多核下編程重來沒有接觸過。不知道這種各個(gè)cpu的分配，是在編譯期間由編譯器完成的，還是在運(yùn)行期間由額外的硬件決定把指令分配給某個(gè)cpu的？這種多核下的編程，值得探討的問題就多了，尤其這種在一個(gè)線程內(nèi)的數(shù)據(jù)被分配到多個(gè)cpu，如果真有這種情況，估計(jì)以后會(huì)有語言層面的東西支持。不同線程分配不同的cpu，這個(gè)到還好。
（2）這個(gè)例子的高性能我絲毫不懷疑，通過字節(jié)對(duì)齊提高性能。其實(shí)標(biāo)準(zhǔn)庫函數(shù)也是這么做的。不過這個(gè)例子沒意義啊，直接使用庫函數(shù)就好。

@搞笑
這樣說就不對(duì)了 文章寫出來 大家share下 目的是互補(bǔ)長(zhǎng)短 互相交流 互相進(jìn)步
@笨笨
從本文中例子來說 這種“優(yōu)化”，可讀性更好，更好維護(hù)。的確是正確的。這種差異不是算法的造成的，是開始設(shè)計(jì)的不合理。另，我的建議真的不是無聊的建議 ：）。
@LouixG
(1)展開循環(huán)的點(diǎn)滴性能不是問題
（2）多線程模型的目的一般系統(tǒng)設(shè)計(jì)層面的吧，主要是提高系統(tǒng)的吞吐能力，這種問題上的性能遠(yuǎn)遠(yuǎn)談不上
（3）后面的問題帶來移植性的問題，非底層的關(guān)鍵算法 也不會(huì)有人去做這種優(yōu)化
@夢(mèng)在天涯
blog里的文章真是多啊

@me
廢話真多。。。。。。

第一種方式比較奇怪啊，感覺毫無意義啊

增加功能的角度有adapter模式
隔離的角度有proxy模式

第二種是典型的接口

linux/unix下最強(qiáng)大的開源內(nèi)存檢測(cè)工具是valgrind

根本原因要看編譯器 優(yōu)化 后的匯編代碼
重構(gòu)代碼的出發(fā)點(diǎn)是可讀性 可維護(hù)性 不是優(yōu)化
系統(tǒng)性能依賴于設(shè)計(jì)階段 之后就是關(guān)鍵算法 性能工具檢測(cè)的性能瓶頸處了

@xmli
這是字節(jié)對(duì)齊問題，baidu、google搜索下 很多資料 不再copy了

@金慶
呵呵 不好意思 沒說明白
這里的顯式是說能被valgrind直接測(cè)試出來了

最終的內(nèi)存泄漏還是要看穩(wěn)定性測(cè)試的時(shí)候 占用的內(nèi)存百分比不隨時(shí)間的增加而增長(zhǎng)