re: 防止程序多開的方法 楊粼波 2011-03-29 10:28
windows系統下，程序防止多開的幾種常見方法：
1)使用FindWindow API函數。
通過查找窗口標題(或/和類名)來判斷程序是否正在運行。如果找到了，表明程序正在運行，這時可退出程序，達到不重復運行的效果；反之表明程序是第一次運行。
這種方法不適用于以下情況，程序的標題是動態變化的、系統中運行了相同標題（或/和類名）的程序
2)Mutex/Event/Semaphore
通過互斥對象/信號量/事件等線程同步對象來確定程序是否已經運行。最常用的函數如：CreateMutexA（注意：QQ堂、QQ游戲大廳就是采用這樣方法來限制程序多開的）
3)內存映射文件(File Mapping)
通過把程序實例信息放到跨進程的內存映射文件中，也可以控制程序多開。
4)DLL全局共享區
DLL全局共享區在映射到各個進程的地址空間時僅被初始化一次，且是在第一次被windows加載時，所以利用該區數據就能對程序進行多開限制。
5)全局Atom
將某個特定字符串通過GlobalAddAtom加入全局原子表(Global Atom Table)，程序運行時檢查該串是否存在來限制程序多開。(該Atom不會自動釋放，程序退出前必須調用GlobalDeleteAtom來釋放Atom)
6)檢查窗口屬性
將某些數據通過SetProp加入到指定窗口的property list，程序運行時枚舉窗口并檢查這些數據是否存在來限制多開。
以上只列舉了最常見的幾種方法，具體應用中可以有n種選擇，或綜合運用多種方法來限制。
#pragma once現在貌似只有VC支持這個宏語句。
不過，我覺得這個比較好，寫著容易，不羅嗦，就是別的編譯器不支持。
Chrome也有這樣的情況發生。
我現在也只有說為了發帖子才用IE那種垃圾貨。
SDL 簡單的音頻視頻庫，是這樣的嗎？
SDL是一個自由的跨平臺的多媒體開發包。
Loki應該描述為：C++模板庫。
ode,bullet 開源的3D物理引擎庫；
2D的物理引擎里面有一個出名的Box2D。
Orge是OGRE吧？Ogre3D算不上中間件，建議自己去查詢下中間件的概念。
sqlite以及Berkeley DB都是：嵌入數據庫編程庫。
不知道這個帖子的意義何在。
后期可以用，維護的時候，因為可以進行自動化的回歸測試。
不過，單元測試不是萬能，但是，能夠保證一些細節的可靠。
哦？這樣的么？
我之前用Windows 7 32位的時候，有的項目會有問題，有的不會，很是奇怪，我估計可能是權限的問題還是怎樣的。
但是，我前幾天換到了64位的操作系統以后，就有問題了，奇了個怪。說實話，讓我每個項目都這樣做，我也很煩。
但是，我現在每調試一次，就要關閉一次工程，這很煩人的。
re: 關于內存數據庫 楊粼波 2011-01-23 19:16
采用何種解決方案，視乎你的需求而定。
合適的就是最好的，
所以，如何去做，是你自己去選擇，
我給你多一個選擇，剩下的就是你自己去選擇了。
它的應用是很廣泛的，不管是在線游戲的領域，還是大型網站的領域里面，比比皆是。
在現在，內存越來越便宜，但是磁盤硬盤IO很慢的情況下，不失為一個良好的解決方案。當然，等到固態硬盤技術普及了之后，可能就不再需要考慮數據庫的IO問題了。
當然，memcache的解決方案也不是萬金油，要想減少數據庫對磁盤的IO操作，那倒是足夠了。
re: 關于內存數據庫 楊粼波 2011-01-21 15:33
memcached
@陳梓瀚(vczh)
你呀，也不能這么偏激，都是為了生計滴。
@Kevin Lynx
我就知道，他們會一個一個的問下去的，所以，先給大家提個醒了。
re: UI中包裹物品排序 楊粼波 2010-12-23 14:17
幾百個,不值一提的數量級.
STL幾乎瞬間搞定.
不管你做什么操作,都會操作背包里面的邏輯數據,只要數據發生改變,數據就臟了.你可以用觀察者模式,去通知UI或者別的需要訂閱的對象.
唉,我從第一行的Hello World,到現在已經快十四年了.
從小霸王,到電子字典,再到PC,哈哈哈哈.
re: UI中包裹物品排序[未登錄] 楊粼波 2010-12-19 11:13
classyk說的對,STL里面有自己實現快排,效率不成問題,而且以包裹如此小的數據規模而言,綽綽有余.
對于防止多次排序,是有很好的辦法的.
你設置一個"可以排序標識符"比如:m_bCanSortBag,
排完序以后,你就設置為false.如果,包裹有變化,你設置為true.
客戶端做一次判定,服務器端再做一次判定,就可以很好的處理了.
re: 女人完美性生活十大原則 楊粼波 2010-09-25 06:04
--!這都被你翻出來了.
--!N年沒有用過php了，
而且現在C++我其實也是用的VS，通過samba操作。
你知道setlocale這個方法的代價有多大么？會帶來什么影響么？
boost::function和boost::bind的使用也是有代價的,
所以，在設計的時候，需要仔細的考量。
vptr雖然也有代價，也不能說一棒子打死的，雖然繼承會產生隱性的耦合，不過在很多場景里面，它是具有它的存在的價值的。
耦合，也并非全然是壞事情。“低耦合”并非是“沒耦合”。
接口，就是創建了一個限制，一個規則。人類社會中，人類不可能脫離限制，脫離規則，那么就是一個混亂的世界。同樣，程序的世界也不可能說沒有限制，沒有規則。
Runnable的設計實際上是非常合理的設計，意圖明顯，結構清晰。
在一個復雜的項目里面，結構清晰，意圖明顯，那真是再好不過的東西了。
re: “三流學校的學生又來了”[未登錄] 楊粼波 2010-08-29 03:48
我想我應該把我中學母校的口號拿出來，與大家共勉：
今日我以校為榮，明日校以我為榮。
我是三流的三流大學畢業的，以我中學母校而言，我進去這樣的大學，母校該為我蒙羞了，要知道我畢業的那所中學，每年都有至少十幾個名牌大學產出，至少一半以上學生都是重本。
不管怎樣，做好最好的自己，三流大學畢業生不可恥，而是做一個三流的自己最可恥。
re: “三流學校的學生又來了”[未登錄] 楊粼波 2010-08-28 02:13
嗯....
其實,我以前有些爛東西發到主頁,
也是被撤掉過的.
re: “三流學校的學生又來了” 楊粼波 2010-08-25 18:14
都好憤青呀.....
我就用的POSIX的，用POSIX的還好吧……
LZ雖然封裝得不是很好，不過至少也是一個學習過程。
還好，比起doxygen,還是很難用的。
支持的標簽還很少，
比如@file @virsion 等等……
需要自己擴展一下才行。
不過，有比沒有好呀。。。。
re: UE的LUA注釋的代碼染色問題 楊粼波 2010-07-06 23:24
UEStudio用著還可以,
支持類圖,還有方法列表.
總的來說用著還可以....
當然,運行調試貌似有點麻煩.
re: 2D游戲引擎的測試程序以及截圖 楊粼波 2010-06-12 18:04
穩妥來說,當然是能不動它里面的東西了.
我是無所謂,這玩意對我來說太透明了.
HGE那種簡單得發慌的東西,
都被我拆得零零碎碎,
雜七雜八的.
re: 2D游戲引擎的測試程序以及截圖 楊粼波 2010-06-11 02:26
--!啥?
re: 找出單向鏈表的倒數第m個元素 楊粼波 2010-06-10 15:25
第二種算法,至少要少訪問鏈表的節點m-1次.
可以直接去profile獲取直觀的時間損耗.
re: 找出單向鏈表的倒數第m個元素 楊粼波 2010-06-10 15:19
我把兩種算法都放出來了,
這個一比較就很明白了.
第一個算法,需要循環鏈表兩次.
第二個算法,只需要循環鏈表一次就足夠了.
另外附上遍歷的概念解釋:
所謂遍歷(Traversal)是指沿著某條搜索路線，依次對樹中每個結點均做一次且僅做一次訪問。訪問結點所做的操作依賴于具體的應用問題。
re: C++程序中嵌入Ruby腳本系統 楊粼波 2010-06-09 14:01
中國急需要性教育,哈哈哈.....
--!這樣子?
汗,是我不解風情了?
呃.....
--!這也不是扭曲自己的設計.
因為如果一個東西是給人用的,那接口簡單明了就OK了.
但是要是分解其原理,
那就不必要做復雜了.
因為接口本身就是為了屏蔽復雜,
而我現在就是要展示接口背后的東西,
顯然的需要化復雜為簡單了^_^
這個類只是用來驗證和講解用的,
沒有必要做那么復雜的設計,那是會讓人閱讀上有些困難的.
任何東西并不是一味的復雜就是好的.
re: 蓋莫游戲引擎-GUI-消息系統 楊粼波 2010-06-08 21:52
用boost::signal足矣.
re: 找出單向鏈表的倒數第m個元素 楊粼波 2010-06-02 21:23
呵呵,我也是做的面試題.
還是這個算法比較符合我的理想中的美學.
re: 找出單向鏈表的倒數第m個元素 楊粼波 2010-06-02 19:30
@R
的確,這塊代碼算起來的確是遍歷了兩遍.
其實在空間上還可以節省掉一個臨時變量的,那就是pFind,可以利用pHead,不過這樣的話,閱讀起來就會讓人誤解.
re: CEGUI的事件系統分析 楊粼波 2010-06-02 10:53
用EA(Enterprise Architect 7.5)畫的.
re: 回憶 楊粼波 2010-06-02 10:12
@saltyshrimp
嘿嘿,謝謝.是不是要唱一曲:廣州歡迎你?
@碧寧
主要是咱這行業太卻穩定性了.
re: 如何在linux下檢測內存泄漏 楊粼波 2010-03-18 14:40
汗，好多年了……
我都忘記了是從哪里轉載到的。
我剛才搜索到原文，
發現竟然和原文都不符。
現在已經補上相關信息。