1.對于STL這樣的態(tài)度的公司或團(tuán)隊(duì)，不乏少數(shù)。其實(shí)，不論從容器還是算法來說，STL提供的容器和算法足夠大部分情況下的使用。boost也同樣好。當(dāng)然，主要還是要能夠掌控他們，否則就如脫韁野馬。好與不好，合適就好。
2.關(guān)于游戲開發(fā)的技術(shù)含量，還是有的。在我的定義里面，游戲開發(fā)其實(shí)還是一種應(yīng)用。所以相對于那些高深的研究來說，還是相對要技術(shù)含量低，特別是在國內(nèi)一把抄的前提下。就服務(wù)器而言，最基礎(chǔ)的是要提供穩(wěn)定的底層，而后隨著人數(shù)的承載量增長，對于服務(wù)器的架構(gòu)設(shè)計要求也是越來越高的。就管理而言，要保證幾十號人工作如一人，項(xiàng)目管理能力同樣重要。
3.關(guān)于內(nèi)存管理，得就事論事，合適就好。先用最普通的內(nèi)存分配方式實(shí)現(xiàn)，如果不合適了再行優(yōu)化。Premature optimization is the root of all evil.
4.如果能夠在設(shè)計最初就劃分好模塊，那再好不過，因?yàn)檫@樣就可以把功能細(xì)分了，功能能細(xì)分了，這樣就能夠把任務(wù)更細(xì)的劃分到每一個實(shí)現(xiàn)人身上。但若一開始無法劃分，那就不要劃分，這樣反倒會束手束腳，那就先實(shí)現(xiàn)，完成后再重構(gòu)。其實(shí)你說的情況不是一個模塊劃分，接口的問題，而是一個高耦合的情況。“高內(nèi)聚，低耦合”這都沒做到，自然的，就更不要談什么模塊和接口了。如果你們能夠達(dá)到這點(diǎn)，就不會亂到一鍋粥了。要堅(jiān)持不斷重構(gòu)，其中的好處，你們越到后面，越能夠體會到。
我這里加載了很多dll，dll會有pdb文件，好像不會卸載。
擦，我現(xiàn)在是相當(dāng)相當(dāng)?shù)耐纯啵?br>非常的想把VS升級上去了。
再怎么減少，還是有操作的，只能說是盡量的減少操作量。因?yàn)楝F(xiàn)在的磁盤型硬盤io操作還是非常非常慢的。這種優(yōu)化是非常收益可觀的。
其實(shí)我現(xiàn)在也是采用的定時保存，開了數(shù)據(jù)庫的連接池。我有經(jīng)常查看數(shù)據(jù)庫的消耗，多半都是消耗在了批量更新上。現(xiàn)在來看，還是可以承受的。
如果你的MySQL能被查詢所拖垮，那你可以考慮下：能否減少查詢的次數(shù)？如果不可行，那是否應(yīng)該要去分表了？
現(xiàn)在的確KV型的NoSQL數(shù)據(jù)庫興起了，但是就我直覺來說，很長時間內(nèi)關(guān)系型的SQL數(shù)據(jù)庫是不大可能被淘汰的。
@zuhd 現(xiàn)在深圳也很冷，光膀子，幾乎沒人敢這么做。
@春秋十二月 有的話你其實(shí)不愛聽，我還是要說。你要有一個好的心態(tài)，怨天尤人的人不可成大事，甚至連生活都有可能一團(tuán)糟。我也時常咒罵自己，這也許你無法理解，但是我要說：你軟弱給誰看？就算別人給了點(diǎn)點(diǎn)的言語上的安慰，又有什么用呢？能幫助你走出困境嗎？能幫你自立自強(qiáng)嗎？不能。或許你沒有碰到過那種絕望卻又要繼續(xù)前行的時候，所以你不能理解。哥們！天行健，君子以自強(qiáng)不息。比你情況糟的人太多了。就想想貝多芬，想想霍金。不要因?yàn)槲艺f得難聽就激憤難平，我不是想做你的人生導(dǎo)師，這是在分享。
對于我這里的博文我有著這樣一個原則思想：轉(zhuǎn)載實(shí)用有用的文章，以備日后查閱；原創(chuàng)簡單實(shí)用的文章，不高談闊論。我堅(jiān)信著我碰到的問題，別人也會碰到，記之共享，至少其他人不會因此走彎路。
用SP可以節(jié)約一點(diǎn)帶寬。不過對于更新數(shù)據(jù)來說，對數(shù)據(jù)庫的消耗確實(shí)是大的。而如果只是查詢，那并不存在任何問題。
網(wǎng)絡(luò)開銷基本上不是問題，現(xiàn)在部署上多半都是同局域網(wǎng)的，千兆網(wǎng)卡，甚至光纖，很難造成太大的影響。
數(shù)據(jù)庫主要IO開銷還是在硬盤上，特別是更新數(shù)據(jù)。用memcached，主要也就是減輕磁盤IO的消耗，緩存在內(nèi)存中，減少對磁盤的操作。
像MySQL這樣級別的數(shù)據(jù)庫，可以把數(shù)據(jù)規(guī)模降低，比如分表這種做法。當(dāng)然，這需要數(shù)據(jù)規(guī)模達(dá)到一定程度。所以我現(xiàn)在還沒有分表。數(shù)據(jù)庫還能承受。
我現(xiàn)在頭疼兩個東西：
1.批量更新；
2.日志的增長。
日志倒還好，勤快點(diǎn)備份清理就好。
批量更新，可以緩存數(shù)據(jù)到內(nèi)存當(dāng)中，以期減少寫入頻率，但是，始終還是要寫入的，這個負(fù)載最終還是無可避免的。
這里有一個開源項(xiàng)目，名字是一樣的，功能上有啥子不一樣，就不知道了。
http://code.google.com/p/luawrapper/
既然能夠想到 “敢問路在前方”，你為何卻看不到這句歌詞的后一句“路在腳下”。
正如你能夠看到貝多芬，卻不能夠看到貝多芬的內(nèi)心強(qiáng)大？
正因?yàn)槿绱耍糯偈鼓氵x擇了軟弱，放棄了強(qiáng)大。
如果你總盯著生活中的倒霉事，會錯過很多好事。----《倒霉愛神》
不要在這里猶如怨婦一般的矯情，怨天尤人。
你以為你這樣就能夠改變一切嗎？
你為什么不慶幸著自己還活著？還有機(jī)會做程序員，還有機(jī)會拿著不到八千塊錢的工資？你為什么不慶幸自己不是流落街頭的流浪漢？
自己內(nèi)心軟弱，你想做給誰看？誰又能可憐你？誰又能幫你擺脫人生的不如意。
人生本來就充滿著這樣那樣的灰度，就這么點(diǎn)事情就失魂落魄的。還好意思拿貝多芬來說事，別人貝多芬至少流芳百世，創(chuàng)作了許多偉大的曲子。你呢？在這里怨天尤人，不思進(jìn)取。
沒口德的罵你：沒用的東西，就這么點(diǎn)事就扛不住了。
配置一個合適自己的編輯環(huán)境，這個是最麻煩的。別的倒還好。不過，順手的編輯環(huán)境靠的是自己慢慢的摸索，如果摸索出來了，之后再配置的話就僅僅是體力活了。
事實(shí)上，我一直都擺脫不了VS，都是在Windows下面編輯好，然后再到非Windows平臺下編譯調(diào)試的。
對于我這等拋棄不了鼠標(biāo)的貨來說，全鍵盤還是頗為不習(xí)慣的。
@小比
那就是別的服務(wù)沒開。這個錯誤，雖然會啟動的時候老報錯，不過基本功能不影響使用。就是啟動的時候看著不舒服而已。
re: 騎行水壺的選擇技巧[未登錄] 楊粼波 2011-11-02 23:48
我買了一個普通的水壺。用著還行。
re: SSH 登錄太慢的解決方法 楊粼波 2011-07-19 20:11
我今天碰到一個問題是，我配置的DNS服務(wù)器，我這里連接不上，所以，系統(tǒng)沒有DNS服務(wù)器可用，那么，既是意味著解析不到DNS。
所以，我發(fā)現(xiàn)，系統(tǒng)啟動的時候，啟動sshd的時候會很慢很慢，至少有一分鐘的停頓。
而且，登陸ssh的時候，也非常非常的慢，這是我從前所未見到過的。
其緣故就是這個DNS解析。
@Orcas
一臺服務(wù)器只需要花費(fèi)一次的錢，外加托管的錢，不多的。
但是程序員的支出是每月的開支。
你要意識到這一點(diǎn)。
re: C++雜談[未登錄] 楊粼波 2011-07-11 21:38
一切遵循木桶效應(yīng)，如果項(xiàng)目中有一兩個水平低的，那么整個項(xiàng)目的質(zhì)量都可能會被這一兩個人所拖累。
如果一個人，掌握不了復(fù)雜的東西。風(fēng)險最小原則，那么就不要使用復(fù)雜的東西，那將會把一切都搞砸掉。
不論是什么語言，什么技術(shù)，在技藝好的人手里，都能玩轉(zhuǎn)自如，而在一個初學(xué)者，一個愚笨者手里，任何東西都會弄得一團(tuán)糟。
c的好處，對我來說，就是可以平鋪直敘，只要設(shè)計好數(shù)據(jù)結(jié)構(gòu)，就可以寫算法了，很簡單。c++這些有oo的語言里面，你卻需要去做一些OO設(shè)計，但是如果設(shè)計好了，那就很舒服了，因?yàn)樗屑?xì)節(jié)都被遮擋住了。
在我學(xué)習(xí)的那么多語言中，各種語言有各種語言的特色特點(diǎn)，同樣也有他們的缺點(diǎn)。語言本身沒有錯，存在的就是有理的。錯的，永遠(yuǎn)都是使用語言的人。
工欲善其事，必先利其器。沒有那把金剛鉆，就不要攬那瓷器活。
這個模板，是在編譯時做了一個類型檢查，可以看做是一個斷言：傳入的參數(shù)必須是數(shù)組，否則編譯不過。
是這樣的。
不過，大多人都走進(jìn)了這樣一個誤區(qū)。不過看起來是挺容易混淆的。
嗯好。
反正不管怎么樣，最優(yōu)的實(shí)現(xiàn)了就行。
Sweep and Prune的話，4000個物體還能夠接受。
我曾經(jīng)做碰撞系統(tǒng)的時候，第一階段Sweep and Prune耗費(fèi)的時間幾乎是微乎其微的。
如果要分離這個業(yè)務(wù)邏輯，我看，在線人數(shù)至少要幾萬以上。因?yàn)椋蛛x意味著，它的計算量已經(jīng)不是單機(jī)能夠承受了。
最多的耗時，還是花費(fèi)在了網(wǎng)絡(luò)群發(fā)上面。
re: 觀察者模式[未登錄] 楊粼波 2011-06-20 14:25
==!那個，大話我也有買，不過束之高閣，還沒看過……
我把幾乎市面上所有的設(shè)計模式的書都買了。哈哈，收藏。
re: 觀察者模式 楊粼波 2011-06-20 12:18
我還是覺得用報刊訂閱講述比較貼切。哈哈哈，這是經(jīng)典的描述。
不過，樓主的講述也很生動。哈哈哈，別有風(fēng)味。
re: TinyXML總結(jié) 楊粼波 2011-06-20 12:14
RapidXML
TinyXML
這兩個都是比較輕量級的。其中RapidXML，boost里面有用到。boost/property_tree里面用到了。因?yàn)椋琑apidXML內(nèi)部自建了一個內(nèi)存池，所以相對來說要比TinyXML要快。實(shí)驗(yàn)證明確實(shí)是如此的。而且，二者之間使用方法上比較相近。
補(bǔ)充一下，在Windows下面可以用纖程。
是一種類似coroutine的實(shí)現(xiàn)。
用coroutine可以實(shí)現(xiàn)。
lua很輕量級；
python相對重一些，性能要比lua稍要差，不過還是很好用的，畢竟OO支持要好點(diǎn)，庫神馬的也多點(diǎn)；
jsp的話，語法接近Java，倒是合適招一些會點(diǎn)Java的人，v8采用的是編譯執(zhí)行的方式，性能還過得去；
Ruby其實(shí)也很不錯，只不過它的GC有點(diǎn)讓人糾結(jié)。
Mono嚴(yán)格意義上不算是一種語言，只能說是一種類似.net的平臺。
Windows的換行方式和UNIX的方式不一樣所導(dǎo)致的。
Windows是CR+LF的方式。
而UNIX的是LF的方式，
而MAC的是CR的方式。
最后一行回車是最簡單的解決方式，我都已經(jīng)保持了這樣的一個習(xí)慣，盡管我現(xiàn)在一直在做Windows下的開發(fā)。
re: GUI庫分塊 楊粼波 2011-05-10 12:23
GUI實(shí)現(xiàn)也就那樣了，都已經(jīng)發(fā)展成熟了。
無需要對架構(gòu)設(shè)計方面花費(fèi)太多心思，CEGUI，Qt，都是比較好的。
GUI主要在堆砌GUI的控件上面，耗時耗力。拋開GUI的控件集，其實(shí)質(zhì)性的東西也沒有多少東西。
GUI核心無非要解決的就是：消息處理、圖形渲染、配置（可編輯）。其中，消息處理和圖形渲染是必須的兩個核心。可編輯，如果時間不允許，不需要也可以，只是體力活比較累人。
@飯中淹
和我想的差不多。
比XML要緊湊一些。
以前看Jabber的時候，它是用XML序列化，不過，空間代價太大了。
版本兼容性，這是一個問題。我現(xiàn)在的做法是完全不兼容。只要是協(xié)議版本不一致，就強(qiáng)制性升級更新。我覺得這是一個簡單有效的方法。如果還要兼容協(xié)議版本，做的事情多得多，這樣就得耗費(fèi)大量的時間在上面，而且對穩(wěn)定性有一定的影響。
@飯中淹
我沒有嘗試過“類型加數(shù)值的序列化和反序列化”，這個的空間不太好吧？會相對多吃點(diǎn)字節(jié)數(shù)吧？
@飯中淹
還有一個，就是數(shù)據(jù)持久化。
嗯。。。。反正是IO神馬的地方都可以用用。
我的服務(wù)器事件系統(tǒng)的一些數(shù)據(jù)有的也是用這個傳遞。
我是從arcemu里面拿出來的，感覺好像和mongos里面的是一樣的。
還有一種利用std::stringstream做序列化的，倒也還可以。
用std::vector可以利用STL的內(nèi)存分配器，這個比較省心。
@finalday
忘記說明了，此種方式只支持POD類型數(shù)據(jù)，這是我描述的缺失。
字節(jié)對齊，這個是可以指定的，問題倒不大，比如windows可以用：
#pragma pack(1)
Google Protocal Buffer使用的是序列化的方式，而且提供了它自己的協(xié)議描述語言，對于跨語言的情況下，是非常好用的。
這個文章，這段代碼是講解如何封包解包的。當(dāng)然，缺點(diǎn)是，無法應(yīng)付變長的情況。這一切都只是為了“簡單”：套接字用的是阻塞的，不考慮非POD數(shù)據(jù)變長數(shù)據(jù)的情況。
數(shù)據(jù)還是放到配置里面的好，比如csv，xml。
放腳本里面可以，但是編輯性不好啊。
做技術(shù)的，實(shí)事求是是最基本的。
不盲目崇拜，也不盲目的否定。
更不能叫罵人身攻擊。
=。=不過，話說現(xiàn)在這個天氣比較燥熱，是容易爆火氣。我最近涼茶度日。
std::vector進(jìn)行一次內(nèi)存分配的成本是很高的，需要銷毀掉原有的內(nèi)存塊，創(chuàng)建一塊新的內(nèi)存塊，然后還有進(jìn)行一次拷貝。啟動的時候，使用std::vector::reserve()進(jìn)行預(yù)先分配，成本將會低上許多，即使是超支了，再分配的次數(shù)也是很微小的。這是一種空間換時間的做法。
像Buffer這種可以預(yù)先知道大致大小的場景，可以使用std::vector::reserve()預(yù)先分配好內(nèi)存塊。而非在使用時實(shí)時的進(jìn)行多次的動態(tài)分配，雖然時間復(fù)雜度不大，但是代價還是是很大的。
std::vector::capacity() 返回vector所能容納的元素數(shù)量(在不重新分配內(nèi)存的情況下）
std::vector::reserve() 設(shè)置Vector最小的元素容納數(shù)量。
做內(nèi)存分配的是STL內(nèi)置的allocator,capacity()本身所取得的是allocator所預(yù)先分配的大小。
vector::push_back導(dǎo)致vector大小增長過程是這樣的，0 -> 1 -> 2 -> 4 -> 8 -> 16 -> 32 ...
既是以2的指數(shù)增長，雖然時間復(fù)雜度是o(1)，但是還是比較費(fèi)，因?yàn)橛袃?nèi)存銷毀，因?yàn)橛袃?nèi)存拷貝，如果是原生數(shù)據(jù)還稍微好一點(diǎn)，如果是struct或者class,這是一個惡夢。
另，std::vector::append()這個方法是不存在的。
@路人甲
我并非惡語相向，而是如此的誤導(dǎo)性的東西，是在誤人子弟。此類型文章是面向初學(xué)者的，如果一個引路者誤導(dǎo)他們，這是一件很糟糕的事情。
還有，0bug是誰？我還真不認(rèn)識。
re: 博客遷移[未登錄] 楊粼波 2011-04-25 14:15
額，我現(xiàn)在木有那個精力學(xué)語言哩……
要不，我也玩玩。
re: 博客遷移 楊粼波 2011-04-25 09:55
怎么去弄Lisp去了？
自己先好好學(xué)一學(xué)STL。
還capacity()機(jī)制，寒……
先仔細(xì)看看std::vector吧，
調(diào)用reserve()才會預(yù)分配內(nèi)存。
這些都是STL的內(nèi)存分配機(jī)制的問題。
自己先多學(xué)點(diǎn)東西吧。
根據(jù)我的觀察，每調(diào)試一次，pdb的句柄就增加一次，調(diào)試多次的話，此解決方案無效，縱使關(guān)閉掉了IDE打開的文件句柄，文件卻無法做寫操作。用VS2003在Windows7上面調(diào)試就是一個巨大的悲劇。
最好的解決方案是：調(diào)試一次，關(guān)閉一次IDE。
re: 被delete難倒了[未登錄] 楊粼波 2011-04-01 15:40
re: 被delete難倒了[未登錄] 楊粼波 2011-04-01 14:39
把struct改為class，然后把數(shù)據(jù)private，測試一次看看。排除客戶代碼應(yīng)用上的錯誤。
當(dāng)然了，也有可能在調(diào)用的時候，被其他地方的錯誤牽連導(dǎo)致這個struct的數(shù)據(jù)被損壞。
如果牽扯到DLL的話，那有可能是exe和dll兩者之間的版本不一致所導(dǎo)致，DLL的導(dǎo)出地址是用的一個，卻不想exe用了另外一個，所以發(fā)生錯誤，這是有可能發(fā)生的。用VS的編譯器，特別是2003，你需要依照以下步驟重編譯：清理全部(包括dll和exe)->重編。
@zzy
這孩子，少見多怪了吧。破解的都這樣，破解需要二進(jìn)制級的修改文件，被殺毒軟件認(rèn)為有毒也是正常的。