@春秋十二月
我們的一個(gè)服務(wù)有1W QPS，數(shù)據(jù)變更時(shí)latency會(huì)幾十倍波動(dòng)，用了這個(gè)后latency再也不波動(dòng)了
@xxoo
"即，string內(nèi)有一個(gè)指針，指向?qū)嶋H的字符串位置，這個(gè)位置前面有一個(gè)_Rep結(jié)構(gòu)，其內(nèi)保存了字符串的長(zhǎng)度、可用內(nèi)存以及引用計(jì)數(shù)。"
re: 淘寶分布式配置管理服務(wù)Diamond Kevin Lynx 2014-10-14 13:23
@zuhd
diamond本身作為服務(wù)器不會(huì)太多的。
re: Muduo源碼閱讀 Kevin Lynx 2014-05-05 19:38
@Enic
就vim，tag都沒用
re: 休閑手游服務(wù)器集群擴(kuò)展思考 Kevin Lynx 2013-10-07 21:40
期待發(fā)出更多的經(jīng)驗(yàn)。
re: node.js手游服務(wù)器調(diào)研 Kevin Lynx 2013-10-07 21:38
我記得node.js有個(gè)包裝了websocket的庫(kù)（不支持websocket的會(huì)有模擬）
ps,
http://socket.io/ socket.io
re: 使用Lisp搭建獨(dú)立博客 Kevin Lynx 2013-07-15 10:02
@bb_cn@163.com
貌似客服還是很速度的啊。。。窮，沒有服務(wù)器
re: 使用Lisp搭建獨(dú)立博客 Kevin Lynx 2013-07-09 13:27
@bb_cn@163.com
實(shí)在不會(huì)提交個(gè)ticket給客服。我沒有續(xù)費(fèi)，現(xiàn)在服務(wù)器停了
re: 使用Lisp搭建獨(dú)立博客 Kevin Lynx 2013-07-08 11:28
@bb_cn@163.com
網(wǎng)頁(yè)上進(jìn)管理系統(tǒng)，就可以看到裝什么系統(tǒng)
@春秋十二月
cppblog抽風(fēng)了，博客后臺(tái)有文件列表，點(diǎn)過去沒有。
re: 傳遞Lua函數(shù)到C/C++中 Kevin Lynx 2013-04-24 20:00
@fy
謝謝有價(jià)值的回復(fù)。
距離這篇博客的寫作時(shí)間太久了，我只能簡(jiǎn)單說明下。實(shí)際上我們項(xiàng)目中最后使用的方式是@thelONE在評(píng)論中提到的方法。即，在lua中直接傳遞函數(shù)對(duì)象（全局函數(shù)、局部函數(shù)、匿名函數(shù)），C/C++中先通過luaL_ref將這個(gè)函數(shù)對(duì)象建立索引并保存進(jìn)注冊(cè)表，在luaL_unref之前，這個(gè)函數(shù)對(duì)象由于存在“引用”所以不會(huì)被垃圾回收。那么，程序里就可以保存luaL_ref這個(gè)索引值。當(dāng)要調(diào)用這個(gè)函數(shù)時(shí)，就根據(jù)該索引從注冊(cè)表中取出（大概是lua_gettable）。實(shí)際操作你可以自己查查。這種方式感覺上效率應(yīng)該會(huì)高不少，對(duì)于腳本方的使用也更自由。但是有個(gè)嚴(yán)重的問題，就是當(dāng)我們進(jìn)行效率檢查時(shí)，定位腳本不太容易，因?yàn)镃/C++這邊沒有有效的方式去標(biāo)識(shí)一個(gè)lua函數(shù)對(duì)象（當(dāng)然后面還是使用了些其他方法，例如使用debug庫(kù)獲得函數(shù)對(duì)象的位置信息）。
@test
繼承不一定會(huì)使用到多態(tài)
re: 像寫函數(shù)式語(yǔ)言代碼一樣寫C++ Kevin Lynx 2012-08-02 09:31
@fzy
thanks，眼神真好！
有很多根據(jù)rst或markdown之類的標(biāo)記語(yǔ)言直接生成整個(gè)HTML站點(diǎn)的工具。很多程序庫(kù)的網(wǎng)站都是這樣干的。
https://github.com/search?q=static+site&type=Everything&repo=&langOverride=&start_value=1
re: 使用Github Page來寫博客 Kevin Lynx 2012-05-03 15:35
@路過
這尼瑪都知道。。。你誰(shuí)啊
@haha
偶爾域名會(huì)得不到解析貌似，godaddy的域名服務(wù)器會(huì)偶爾被墻
@mhsy2003
1. thanks
2. google code是非常想支持的，在沒有RSS的情況下，也希望可以通過google API之類去獲取
3. 顯示自己的動(dòng)態(tài)我會(huì)盡快加上。
@布拉德比特
你輸入的地址是啥?
ps，你的博客地址可以獲取啊：http://www.bradbit.com/blog/
re: 靜態(tài)庫(kù)中全局變量的初始化問題 Kevin Lynx 2011-11-07 09:46
@溪流
解決辦法就是換成常規(guī)方法：顯示初始化。
不知道可不可以直接繪制在桌面DC上，而不用創(chuàng)建一個(gè)桌面那么大的對(duì)話框？
@thircese
大概是因?yàn)樵谌址秶鷥?nèi)也能寫下a = func()這樣的語(yǔ)句。分號(hào)雖然能作為區(qū)分，但在很簡(jiǎn)單的語(yǔ)法分析算法中，是希望由最開頭的token來確定后面跟的是什么樣的語(yǔ)法。在具體實(shí)現(xiàn)時(shí)：
if (tok == TK_FUNCTION) 就可以簡(jiǎn)單地知道是函數(shù)定義，而不是在掃描完函數(shù)名、參數(shù)列表、括號(hào)后發(fā)現(xiàn)還有分號(hào)，才能確定是函數(shù)調(diào)用，這多少會(huì)加大實(shí)現(xiàn)的復(fù)雜度
re: 傳遞Lua函數(shù)到C/C++中 Kevin Lynx 2011-05-08 19:36
@thelONE
有沒有做過這方面的測(cè)試？
re: MMO游戲?qū)ο髮傩栽O(shè)計(jì) Kevin Lynx 2011-05-03 19:37
@楊粼波
這倒提醒我了。還真是不方便編輯。
re: MMO游戲?qū)ο髮傩栽O(shè)計(jì) Kevin Lynx 2011-05-03 18:05
@飯中淹
我們這回策劃將編寫大量腳本。瞬間在策劃組掀起了學(xué)習(xí)Lua的熱潮。整體架子的發(fā)展路線，和你說的差不多。程序這邊僅提供底層功能實(shí)現(xiàn)。
re: MMO游戲?qū)ο髮傩栽O(shè)計(jì) Kevin Lynx 2011-05-03 16:06
@飯中淹
話說你把你們的服務(wù)器整成全部配置驅(qū)動(dòng)的；而我們?cè)谙蛉磕_本驅(qū)動(dòng)靠近。
re: MMO游戲?qū)ο髮傩栽O(shè)計(jì) Kevin Lynx 2011-05-03 13:57
@lin_style
復(fù)雜性和可維護(hù)性不僅體現(xiàn)在本項(xiàng)目，一般一個(gè)團(tuán)隊(duì)的下個(gè)項(xiàng)目就是在上個(gè)項(xiàng)目的基礎(chǔ)上改。所以希望把這些游戲相關(guān)的東西盡量獨(dú)立出來。理想情況下是到了下個(gè)項(xiàng)目可以直接通過移除一部分模塊添加一部分模塊即可。
當(dāng)然，如你所說，確實(shí)存在度的把握問題。我現(xiàn)在是打算把基礎(chǔ)屬性（例如坐標(biāo)）寫死，或者通過本文的機(jī)制在程序里添加；其他屬性（主要是戰(zhàn)斗屬性、什么中毒抗性啊、暴擊傷害比率啊）放在腳本或配置里擴(kuò)展。
但是如果是做引擎，這些包裝則是必須的了。
ps. 因?yàn)樵趫F(tuán)隊(duì)里某部分代碼可能會(huì)在時(shí)間線上由不同的人修改，盡早地提出一種明顯的規(guī)則，可以約束后面的人不至于隨意而為。如果一開始就在Player類里塞功能，早期可能沒問題，不過隨著項(xiàng)目進(jìn)展，后面的人極有可能模仿前人的做法，最終就會(huì)導(dǎo)致不斷地在Player里加功能代碼。膨脹由此而來。
re: MMO游戲?qū)ο髮傩栽O(shè)計(jì) Kevin Lynx 2011-05-03 12:11
@飯中淹
Linux下的chrome看沒有什么骷髏頭啊。。- -|
re: MMO游戲?qū)ο髮傩栽O(shè)計(jì) Kevin Lynx 2011-05-03 12:03
@lin_style
基本上是。雖然邏輯不一定復(fù)雜，可能僅僅是大量功能的堆積。但其維護(hù)性肯定不好。回憶一下當(dāng)你剛接手熟悉一個(gè)項(xiàng)目代碼時(shí)，看到一個(gè)巨類時(shí)的感覺。
re: MMO游戲?qū)ο髮傩栽O(shè)計(jì) Kevin Lynx 2011-05-02 20:36
@so
加了個(gè)“繼續(xù)閱讀”指向我那個(gè)獨(dú)立博客。- -| 你都要在這里留言。
re: 多重繼承和void*的糗事 Kevin Lynx 2011-05-01 18:43
@lin_style
沒完全懂你意思。是討論使用方法？還是討論底層實(shí)現(xiàn)？
re: 多重繼承和void*的糗事 Kevin Lynx 2011-05-01 17:34
@dutor
正解。robj = (Bottom*) vobj;會(huì)做偏移。如果Bottom單繼承自Right，會(huì)出什么詭異問題？
@lin_style
如果這樣做，就等同于用匯編去操作vptr。
我是過來當(dāng)和事佬的。飯那篇帖子后的留言我沒來得及看到。飯叔叔我N多年以前就算認(rèn)識(shí)。vczh算是CPPBLOG老面孔。我覺得這完全是個(gè)誤會(huì)。彼此之間對(duì)對(duì)方意思的完全誤解。vczh文章中的態(tài)度也算中肯。我覺得大家完全可以熄火和解。倒是vczh和飯的文章后的馬甲留言讓人生厭，完全的謾罵。
re: 【簡(jiǎn)單的字符串模版匹配】 Kevin Lynx 2011-04-29 19:51
@飯中淹
不要跟連名字都不敢留的人一般見識(shí)。
re: 博客遷移 Kevin Lynx 2011-04-25 15:33
@楊粼波
瞎折騰有時(shí)候是挺累。
re: 傳遞Lua函數(shù)到C/C++中 Kevin Lynx 2011-04-25 13:19
@oo
這句話是欠妥，3Q。不過，因?yàn)樵赾/c++里沒有映射Lua函數(shù)的類型，所以沒有辦法把傳入的print取出來。這無(wú)法滿足回調(diào)的需求。
re: 博客遷移 Kevin Lynx 2011-04-25 10:51
@楊粼波
業(yè)余愛好:D Lisp很酷
re: 博客遷移 Kevin Lynx 2011-04-24 22:17
@溪流
都是老面孔了 :D
@expter
我指的是你文章里的test沒有static Obj obj這句。
最后一個(gè)例子代碼有點(diǎn)問題吧？可以讓編譯器將部分警告視為錯(cuò)誤。
00411405 add esp,4 ;Call test 函數(shù)時(shí)將壓入棧數(shù)據(jù)
準(zhǔn)確的說這條語(yǔ)句是恢復(fù)堆棧，因?yàn)橹暗膒ush 1。默認(rèn)的cdecl調(diào)用約定是調(diào)用者平衡堆棧。
win32匯編里約定eax作為返回值寄存器。
@笨笨
不是我總結(jié)的，貌似是<Inside C++ object model>里有這么一句話。"when it's necessary"
基本上，就是“當(dāng)需要的時(shí)候”，就會(huì)被生成。
re: 被delete難倒了 Kevin Lynx 2011-03-30 17:50
@dizhu
問題確實(shí)可能出在其他地方。
@陳梓瀚(vczh)
- -| 我用工具自動(dòng)生成的。。。多謝提醒。
re: 如何書寫權(quán)威的程序庫(kù)頭文件 Kevin Lynx 2011-03-17 18:11
- -| 別人那樣寫是有原因的。尤其是跨平臺(tái)代碼（導(dǎo)致各種宏）、開源代碼（導(dǎo)致各種版權(quán)注釋）、避免名字沖突的庫(kù)代碼（導(dǎo)致符號(hào)前綴）。。。
@求幫助~
看你學(xué)的是哪門腳本語(yǔ)言。一般較為流行的腳本語(yǔ)言都有大量的文檔、教程、書、庫(kù)、開源代碼，例子怎么會(huì)少？除非你用的是百度，連語(yǔ)言的官方網(wǎng)站都沒找到。
@月下圓舞曲
貌似vs默認(rèn)帶的STL實(shí)現(xiàn)是不帶內(nèi)存池實(shí)現(xiàn)的，它的allocator就是個(gè)malloc的包裝。可以試著把SGI里的那個(gè)allocator拿出來，這個(gè)allocator算是比較高效的小塊內(nèi)存池。鑒于STL本身在構(gòu)造容器時(shí)就支持自定義的allocator，所以要適配進(jìn)vs默認(rèn)的STL應(yīng)該不困難。
re: 用lisp開發(fā)博客客戶端 Kevin Lynx 2011-03-14 13:18
@Louis
閱讀Lisp代碼主要是通過代碼縮進(jìn)來識(shí)別語(yǔ)句關(guān)系，如果是通過括號(hào)那根本沒法閱讀。在RECL下（也就是交互模式下）輸入語(yǔ)句我喜歡一行輸下去，所以那個(gè)輸入環(huán)境能有括號(hào)匹配（例如CLISP輸入")"時(shí)就會(huì)做點(diǎn)提示）就是個(gè)不錯(cuò)的功能。SBCL默認(rèn)沒有。
全部同意。尤在函數(shù)長(zhǎng)度限制和功能單一方面，是應(yīng)該大大注意的。