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