用 BoundsChecker 吧，原理大家都懂但是自己做沒必要（盜版滴）
re: 失眠的夜，瞎想 萬連文 2017-08-09 08:46
長夜漫漫無心睡眠，沒想到晶晶姑娘你～也睡不著覺
re: C++的非侵入式接口 萬連文 2017-07-28 09:43
確實(shí)沒必要在普及這些知識了，時代變了。雖然道理不會變，但是誰有在意這些呢？
re: 非完美的stl 萬連文 2017-07-09 08:02
因?yàn)椴僮飨到y(tǒng) api 沒有標(biāo)準(zhǔn)化，所以語言也很難標(biāo)準(zhǔn)化。C++ 門檻高不符合現(xiàn)代主流開發(fā)模式，所以人就少了，話題也自然少了。不過轉(zhuǎn)戰(zhàn)知乎是為了湊熱鬧嘛？
沒想到鎖搞這么復(fù)雜，多線程的問題可以通過規(guī)劃線程模型來解決，底層的淫巧往往在于無鎖編程。
記憶中是Send/PostMessage返回FALSE表示窗口假死，Chromium源碼中有的。Ghosting是很早就知道了，感覺有遮罩層的意思，方便接管消息做統(tǒng)一的假死處理。
遠(yuǎn)程桌面協(xié)議(RDP) 不知道算不算？
IServiceProvider->IService->IComponent
小模塊更明確直接使用最終的組件，大模塊需要能拿到全局的IServiceProvider以便調(diào)用需要的服務(wù)。總之需要權(quán)衡，度的拿捏是架構(gòu)關(guān)鍵。
re: 博客一周年紀(jì)念貼 萬連文 2013-05-01 15:34
或許展望的第二條已經(jīng)解釋了很多人不繼續(xù)的原因，知道的越多越覺得自己渺小，越不愿去展示--對或錯。或許這不是一種好的現(xiàn)象，但這就是一種事實(shí)，在國內(nèi)。
@蔡東赟
多核編程不是多線程，線程不會給你帶來任何時間的節(jié)省！！！！，只能更長。
時間的優(yōu)化幾乎只有一種可能就是空間。現(xiàn)在多核處理器下又多了一種方式就是多核編程。
多線程只是把一個長處理分片執(zhí)行，并不是也無法節(jié)省時間，如果你打算充分發(fā)揮硬件資源優(yōu)勢，應(yīng)該是多核編程。
不太明白你現(xiàn)在的目的。
這是最典型的濫用技術(shù)案例，總時間顯然單線程要短，第一個試驗(yàn)如果數(shù)據(jù)沒錯就可能是多核的原因。
使用atl的轉(zhuǎn)換
T2CA
不要再制造這些東西了，因?yàn)橐呀?jīng)在那里了。
呃，發(fā)現(xiàn)你的第二種方法已經(jīng)是那樣了，不過沒必要再分配一次CString了吧
男人，每個月總有那么幾天不爽，吐吧吐吧不是罪。很欣賞你的堅(jiān)持，就像曾經(jīng)別人欣賞我的那樣，希望你能比我過得好。
曾經(jīng)某報向我們公司征一字來總結(jié)2012年，想了好久最后用了一個待字；如果上天能給我再來一次的機(jī)會，我會用憋字，非要在憋字上加一個動作，我希望是繼續(xù)憋？
@程旭
最近這幾個月從研究webkit，轉(zhuǎn)向虛擬機(jī)字節(jié)碼，然后有轉(zhuǎn)向IDA OD學(xué)習(xí)，比較閑散自由無目的，但是沒有偷懶就好。
@程旭
工作重點(diǎn)不是這個，正規(guī)的研究寫代碼有個把月，當(dāng)然代碼的設(shè)計相當(dāng)規(guī)范。
@Demon
那個工程剝離出來的不完整，僅僅用于學(xué)習(xí)參考，我也沒有繼續(xù)維護(hù)。
@Demon
這個版本很老了，我自己也記不住，當(dāng)初最遺憾的就是沒有前瞻性，保持跟蹤，不過那樣又會源碼很大不便于學(xué)習(xí)，有利有弊。如果你一時無法接受Chromium那么大工程，可以看xframework好了，小而干凈，學(xué)習(xí)起來更容易掌握。
C++03標(biāo)準(zhǔn)下最推薦的是CSimplePtr<int>::type p(new int);這種
http://en.wikipedia.org/wiki/C%2B%2B0x#Alias_templates 支持c++11可以這樣
貌似只能如此，不必太過糾結(jié)啊
GPU & 后面的圖像處理技術(shù)，如果能借助OS源碼可以，否則看看 chromium未嘗不可
@M77
過獎，回頭一看又發(fā)現(xiàn)幾個不標(biāo)準(zhǔn)的地方，努力遵守Google規(guī)范。
請問這是資本主義的東西還是社會主義的東西，還是可以拿來主義的東西？
@Loaf
其實(shí)我非常少做項(xiàng)目，很多工作時間用來搞這些興趣。
我個人表示對RSS不太了解，有點(diǎn)土鱉。
@路障
看我的Demo，看我的接口，你就會發(fā)現(xiàn)我是怎么做的！！給我點(diǎn)面子唄。
@iunkown
這個我沒有測試過，也沒有考慮過，不過確實(shí)是一種思路，你可以自己確認(rèn)。但是我的方法未嘗不是好方法，不是么？
后來我看了你的東西，覺得就是前面說的毫無章法，無頭蒼蠅。你的那個鏈接我看了，連運(yùn)行一下的心情都木有。
@路障
可以的，我接下來就會講解這部分。這里面有很多技巧，在現(xiàn)有的互聯(lián)網(wǎng)很難找到（甚至幾乎是不可能），因?yàn)樽罱鞣矫婀ぷ鞅容^忙沒有時間，我保證下一篇會詳細(xì)講解。
@christozhou
你是指我的實(shí)現(xiàn)嘛？這個我還沒有查，看看先。
@weolar
呃，是這么打算，自己的項(xiàng)目也在用她，還在繼續(xù)打磨，今天把異步下載然后更新OLE搞定，xml解析也用的expat替換了，哈哈。
@溪流
不對，然后你不是要說那個。。。你是說有什么技巧躲開嗎？
thunk技術(shù)可以躲開，微軟早期的ie內(nèi)核中的dom對象的接口就是采取這種辦法實(shí)現(xiàn)。
@羅
參見
http://www.shnenglu.com/wlwlxj/archive/2012/05/20/175489.html即使嵌入了也無法正常工作，因?yàn)閞ichedit對OLE的支持閹割了，不支持大部分OLE接口，即使支持的接口也并非完全遵守OLE規(guī)范。
1.return路徑太多，不容易排錯
2.CMyWindow* Find(HWND hwnd);我想是應(yīng)該加一個const
3.Add和Remove方法的參數(shù)不對稱，你確信是這樣子嗎？
4.CWindow * pwnd指針前后都有空格是排版導(dǎo)致的嗎？
5.WndIterator為何不用CWindowMap::iterator去定義，名字上有那么大差別，它們表達(dá)的含義真的不是一個事物嗎？
6.RECT rect = { 100, 100, 200, 200 };不好嗎？
因?yàn)槟阏f了“代碼簡潔漂亮”，吸引了我，結(jié)果有點(diǎn)失望。Any Way, 千里之行始于足下。
根據(jù)我目前掌握的，可以研究一下chromium的views框架以及未來某個時間推出的aura(已經(jīng)用于chrome os)。實(shí)現(xiàn)思想上（概念、對象模型）可以借鑒wpf，缺點(diǎn)就是沒有源碼參考。我自己在盤views/aura + windowless richedit + windowless webview(chromium 內(nèi)核)，工作量巨大，還好可以占用工作時間折騰。
FLTK 我5-6年前看過，太輕以至于在那個年代做最簡陋的嵌入式UI都覺得不夠好，盡管如此也值得一看。
@路障
都不是，這方面的內(nèi)容我會在下一篇博客里面提到。
@路障
通知richedit刷新，這樣更容易封裝一些，richedit負(fù)責(zé)獲取ole位置，并判斷是否可見，不可見則做標(biāo)記不再更新直至下次ole的Draw發(fā)生（richedit刷新機(jī)制負(fù)責(zé)）時設(shè)置true；如果可見則進(jìn)行繪制。
re: vcredist與程序發(fā)布 萬連文 2012-08-22 10:01
具體原因是VC運(yùn)行時多個版本之間不完全兼容，尤其是加入manifest后引入的Side By Side規(guī)則，WinSxs下有很多不同小版本的運(yùn)行時。好的開發(fā)模式：
1.統(tǒng)一的開發(fā)環(huán)境統(tǒng)一編譯，即使是不同小版本的VS IDE也可能引起問題。
2.靜態(tài)鏈接CRT MFC等，這個是微軟推薦的方式。
1.對象采用引用計數(shù)
2.對消息機(jī)制進(jìn)行封裝使其更面向?qū)ο?參考chromium的消息框架)
其它的辦法不是很體面、系統(tǒng)。
@ly
GIF表情的 復(fù)制 和 粘帖 實(shí)際上跟注冊關(guān)系不那么大，這個不是重點(diǎn)。研究還在進(jìn)行中，事情多多，幾線作戰(zhàn)力不從心。
@bukebushuo
這個lib一直都有，微軟自己也在大量使用，為什么是明顯缺點(diǎn)？
@Richard Wei
我覺得正如Mac上的Cocoa，windows上趨勢則是WinRT和Xaml
我認(rèn)為這是廢話，因?yàn)镺S就是那么走的。
對于Native應(yīng)用
你說了2個主流的OS，你不屑Linux下的桌面？還是覺得它們不擅長這方面？沒發(fā)展好？不值得你一提？安卓呢？ChromeOS沒做好，就無趨勢可言？
但是3D和2D接口是如此不同以致現(xiàn)時中很難看到他們的統(tǒng)一
請問基于WebKit內(nèi)核的也有一些3D渲染組件啊(具體看 Unity 3D)，甚至原生都能用3D渲染，他們?yōu)槭裁礇]有說很難統(tǒng)一？GPU加速的Native UI，Chromium的aura用于替換早前ChromeOS的Shell，你也可以看看啊。
但是windows上傳統(tǒng)桌面應(yīng)用開發(fā)的減少現(xiàn)在卻是趨勢
是的，沒有人否認(rèn)這個，但是這不妨礙一個人去學(xué)習(xí)，去構(gòu)造屬于自己的樂趣。
初學(xué)者或許可以拿來入門
初學(xué)者學(xué)習(xí)你的東西的時候，你是不是也要告訴他：過時了，沒落了，什么才是主流，潮流！
@Richard Wei
按照你的邏輯，我更愿意相信WebKit+HTML5能勝過WinRT，或者WebRT不是更好？至于你發(fā)的那個所謂的DirectUI源碼，提到的粗燥，倒算是虛心。界面引擎做的好不好，跟用的是不是GDI沒有太大關(guān)系。標(biāo)題是Windows真的沒落了嗎，你去反駁的是我不得不說GDI過時了，你心中的自大可見一斑。
做自己喜歡的事情，計較那么多干嘛呢？自己喜歡除了比撈錢外應(yīng)該算是吊絲的最大樂趣了，不是麼？
re: richedit研究開篇01 萬連文 2012-07-02 17:11
@M77
原生控件不是Windowless，效果有差距。
re: richedit研究02 – 大綱 萬連文 2012-06-24 08:33
@weolar
是這樣的。之所以選擇xml是因?yàn)椴榭戳藂q的剪貼板格式，里面有用到CDATA。JSON現(xiàn)在也是我的首選，xml的整套規(guī)范太大也復(fù)雜，而現(xiàn)在主流的思想是簡單、可組裝。
re: richedit研究02 – 大綱 萬連文 2012-06-15 10:20
@Richard Wei
哦？我沒發(fā)現(xiàn)Win7下有問題，包括我自己的電腦和周邊同事的，如果是缺少DLL能否用依賴工具幫忙查看一下？我懷疑是缺少xmllite.dll，我打算用這個解析xml。
re: richedit研究02 – 大綱 萬連文 2012-06-15 07:23
@春秋十二月
謝謝，建議已經(jīng)采納，其實(shí)我一直想做的更加符合文章編排，只是專注技術(shù)時間再無暇去考慮那些，這或許是一個藉口。