摘要: Google Protocol Buffer( 簡(jiǎn)稱 Protobuf) 是 Google 公司內(nèi)部的混合語言數(shù)據(jù)標(biāo)準(zhǔn)，目前已經(jīng)正在使用的有超過 48,162 種報(bào)文格式定義和超過 12,183 個(gè) .proto 文件。他們用于 RPC 系統(tǒng)和持續(xù)數(shù)據(jù)存儲(chǔ)系統(tǒng)。
Protocol Buffers 是一種輕便高效的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)格式，可以用于結(jié)構(gòu)化數(shù)據(jù)串行化，或者說序列化。它很適合做數(shù)據(jù)存儲(chǔ)或 RPC 數(shù)據(jù)交換格式。可用于通訊協(xié)議、數(shù)據(jù)存儲(chǔ)等領(lǐng)域的語言無關(guān)、平臺(tái)無關(guān)、可擴(kuò)展的序列化結(jié)構(gòu)數(shù)據(jù)格式。目前提供了 C++、Java、Python 三種語言的 API。  閱讀全文      摘要: 經(jīng)過上面的比較， 我們可以得出一些結(jié)論：
消息方式的強(qiáng)項(xiàng)是耦合性和擴(kuò)展性，以及監(jiān)控的方便性，個(gè)人感覺比較適合于Server端的規(guī)模應(yīng)用。
接口方式的強(qiáng)項(xiàng)是性能高效以及開發(fā)的方便性， 比較適用于同一進(jìn)程內(nèi)客戶端的小規(guī)模應(yīng)用。

但是大部分時(shí)候， 對(duì)于架構(gòu)師或是公司領(lǐng)導(dǎo)，他們會(huì)更關(guān)注可耦合性和可擴(kuò)展性，所以他們會(huì)傾向于選擇消息方式，盡管有時(shí)可能不是那么適用。
  閱讀全文      摘要: operator new的一些原則：
a. 一般不要重寫全局的operator new, 具體可以參考 不要重載全局 ::operator new
b. 如果重載了operator new, 同時(shí)提供所有版本(plain new, nothrow new, placement new)
c. 成對(duì)的提供new和delete, 即如果重載了operator new, 同時(shí)重載operator delete  閱讀全文      摘要: C++編程規(guī)范...  閱讀全文      摘要: 看到ATL中有3個(gè)類的代碼比較比較重復(fù)，在atlbase.h中，分別是CAutoVectorPtr, CAutoPtr和CAutoStackPtr，他們的功能其實(shí)很類似STL中的autoptr, 但是這里因?yàn)獒槍?duì)不同的分配對(duì)象而用了3個(gè)不同的類，其中CAutoVectorPtr是針對(duì)數(shù)組類型的，CAutoPtr是針對(duì)普通的非數(shù)組類型，而CAutoStackPtr針對(duì)的是_malloca分...  閱讀全文      摘要: 總之，拿著一把刀，庖丁解牛般的剖析語言背后的實(shí)現(xiàn)細(xì)節(jié)，看起來不是那么實(shí)用，但是它能讓你對(duì)語言的理解更深刻。實(shí)際上ATL中大量應(yīng)用上面的技術(shù)，如果沒有對(duì)C++ 對(duì)象模型有比較深刻的理解，是很難深入下去的。  閱讀全文      摘要: 通過上面的分析，我們驗(yàn)證了平時(shí)C++書上關(guān)于各種類型變量存儲(chǔ)區(qū)域的假設(shè)，簡(jiǎn)單來說就是全局變量和靜態(tài)變量會(huì)被編譯到可執(zhí)行文件的數(shù)據(jù)節(jié)(分只讀和可讀寫)中, 非靜態(tài)的局部變量則分配在堆棧(stack)上，而new(malloc)出來的內(nèi)存則分配在堆(heap)上。  閱讀全文      摘要: 通過上面的介紹，相信大家對(duì)程序內(nèi)存有了比較全局的理解，以后大家分析問題，遇到一個(gè)地址，首先要判斷這個(gè)地址分布在哪里:
如果是Image上，那么是在哪個(gè)模塊中，這個(gè)地址是屬于該模塊的代碼段（.text）還是數(shù)據(jù)段(.data)，如果是代碼段，又是屬于哪個(gè)函數(shù)?
如果是Heap上，那么究竟是在哪個(gè)堆里面，是我們new出來的嗎，是在什么時(shí)候new的(new時(shí)堆棧狀況)？
如果是在Stack上，那么究竟是屬于哪個(gè)線程的堆棧，當(dāng)時(shí)線程的堆棧是怎么樣？

總之，程序在內(nèi)存中運(yùn)行，只有你真正理解了內(nèi)存，你才能真正懂計(jì)算機(jī)。  閱讀全文      摘要: 從上面的例子我們可以看到，對(duì)于可變參數(shù)的函數(shù)，有2種東西需要確定，一是可變參數(shù)的數(shù)量， 二是可變參數(shù)的類型，上面的例子中，參數(shù)數(shù)量我們是在第一個(gè)參數(shù)指定的，參數(shù)類型我們是自己約定的。這種方式在實(shí)際使用中顯然是不方便，于是我們就有了_vsprintf, 我們根據(jù)一個(gè)格式化字符串的來表示可變參數(shù)的類型和數(shù)量，比如C教程中入門就要學(xué)習(xí)printf, sprintf等。

總的來說可變參數(shù)給我們提供了很高的靈活性和方便性，但是也給會(huì)造成不確定性，降低我們程序的安全性，很多時(shí)候可變參數(shù)數(shù)量或類型不匹配，就會(huì)造成一些不容察覺的問題，只有更好的理解它背后的原理，我們才能更好的駕馭它。  閱讀全文      摘要: 當(dāng)然，上面幾種DLL對(duì)外暴露接口的方式本質(zhì)上沒有區(qū)別，都是利用PE文件的導(dǎo)出節(jié)來導(dǎo)出數(shù)據(jù)和函數(shù)，但是根據(jù)它們使用方式的不同，對(duì)外部模塊來說還是有很大的區(qū)別，我們的推薦次序依次是:COM方式->導(dǎo)出API函數(shù)方式->導(dǎo)出類方式。  閱讀全文      摘要: 最后簡(jiǎn)單比較下上面3種實(shí)現(xiàn)回調(diào)的方法:
第一種Callback的方法是面向過程的，使用簡(jiǎn)單而且靈活，正如C語言本身。
第二種Sink的方法是面向?qū)ο蟮模贑++里使用較多， 可以在一個(gè)Sink里封裝一組回調(diào)接口，適用于一系列比較固定的回調(diào)事件。
第三種Delegate的方法也是面向?qū)ο蟮模蚐ink封裝一組接口不同，Delegate的封裝是以函數(shù)為單位，粒度比Sink更小更靈活。   閱讀全文      摘要: 在網(wǎng)上關(guān)于窗口視覺效果，有2個(gè)問題被問得最多:
第一個(gè)是如何讓窗口邊框有陰影效果？
第二個(gè)是如何讓窗口控件有半透明效果？
  閱讀全文      摘要: 總的來說DirectUI是趨勢(shì)，而微軟的WPF代表了DirectUI最先進(jìn)的技術(shù)方向，換膚對(duì)于DirectUI來說非常容易。隨著Win7，Win8 的普及，傳統(tǒng)界面庫(kù)的市場(chǎng)會(huì)越來越小，一來因?yàn)橄到y(tǒng)本身已經(jīng)很炫了，二來微軟自己的WPF和Xaml技術(shù)基本上已經(jīng)可以實(shí)現(xiàn)任何想要的效果。當(dāng)然只要XP不消亡，傳統(tǒng)的界面庫(kù)還是有自己的一席之地。  閱讀全文      摘要: 主要特性:
(1)軟件小而高效，使用流暢，設(shè)計(jì)人性化
(2)支持截圖區(qū)域的手工選擇和根據(jù)窗口自動(dòng)識(shí)別選擇
(3)支持矩形，圓形，直線，箭頭，畫筆，文本等注釋工具
(4)支持橡皮擦除功能
(5)無限次數(shù)的撤銷和重做
(6)支持鼠標(biāo)光標(biāo)的截取
(7)支持鼠標(biāo)區(qū)域跟蹤和放大
(8)支持各種圖像文件格式的保存和編輯
(9)支持多顯示器
(10)支持換膚和多語言  閱讀全文      摘要: 做為一名Windows平臺(tái)上的C/C++開發(fā)人員，我們有N個(gè)理由學(xué)習(xí)WinDbg的使用:
有些Bug只有在客戶和QA的機(jī)器上才能重現(xiàn)，我們不可能在他們的機(jī)器上裝一個(gè)VC吧
WinDbg可以讓我們方便的保存和分析Dump文件
WinDbg的調(diào)試功能比VC強(qiáng)大的多，比如它有強(qiáng)大的API斷點(diǎn)和條件斷點(diǎn)
調(diào)試內(nèi)核和驅(qū)動(dòng)，我們只能用WinDbg
用WinDbg可以讓你更深入的理解系統(tǒng)，理解計(jì)算機(jī)，用VC你看到的是自己的代碼，用WinDbg你看到的是整個(gè)進(jìn)程
......
最重要的，微軟用WinDbg開發(fā)和調(diào)試Windows操作系統(tǒng)，它是Windows平臺(tái)上最重要的調(diào)試工具.  閱讀全文      摘要: 經(jīng)常有初學(xué)者詢問如何學(xué)習(xí)Windows編程？

很多人從MFC開始學(xué)習(xí)，結(jié)果常常是一頭霧水，知難而退；也有人毅力堅(jiān)強(qiáng)，熬過了MFC的陣痛期，最后卻是知其然而不知其所以然，并且思維被限制在MFC的框架之中，遇到稍微有點(diǎn)規(guī)模的程序就無從下手了。  閱讀全文      摘要: 那么Windbg分析Dump時(shí)，會(huì)如何推理堆棧過程呢？
如果每個(gè)函數(shù)都是有標(biāo)準(zhǔn)的push ebp, 那么按照ebp遞推就可以了；
否這就只能用其他方法分析，比如看看堆棧里某個(gè)地址是不是函數(shù)返回地址（該地址屬于某個(gè)模塊的代碼段），這樣就可以確定該地址是某個(gè)函數(shù)堆棧楨的起始地址。  閱讀全文      摘要: 今天遇到一個(gè)比較奇怪的crash問題，這里記錄下。這個(gè)crash是由QA設(shè)置了一些不合理的參數(shù)引起的，還好QA當(dāng)時(shí)保存了Dump文件，讓我們可以慢慢分析，從而找出代碼中隱藏的問題。  閱讀全文      摘要: 運(yùn)行庫(kù)，數(shù)據(jù)節(jié)， 代碼節(jié)  閱讀全文      摘要: 這個(gè)DirectUI界面庫(kù)主要參考一個(gè)老外的程序, 支持各種Layout模式,實(shí)現(xiàn)了各種基本控件(SplitBar, PictureBox, Button, Radio, CheckBox, Label, HyperLink, ProgressBar, trackBar, ListBox, Edit, ComboBox, Tab Control, Toolbar, Menu, tree)，支持鍵盤導(dǎo)航，支持Tooltip，支持多語言，支持換膚，支持異形窗口，支持Layered Window, 支持插件2次開發(fā)，支持Alpha通道，支持各種圖像處理。  閱讀全文      摘要: 可以看到無論對(duì)于開發(fā)還是測(cè)試人員，windbg很多時(shí)候可以幫我們快速的定位問題， 如果借助符號(hào)文件，Windbg完全可以實(shí)現(xiàn)比VC IDE更強(qiáng)大的調(diào)試供功能， 并且有時(shí)候我們不需要源代碼，不需要重新編譯，直接就可以通過windbg調(diào)試和解決問題。  閱讀全文      摘要: 正如我們不能確定微軟的Win8 Metro能否成功，我們現(xiàn)在還不能確定這種PC沒落的趨勢(shì)是否會(huì)持續(xù)下去, 新生平臺(tái)究竟會(huì)是曇花一現(xiàn)，還是主流趨勢(shì)? 作為一名技術(shù)人員，有時(shí)候真的很無奈，雖然理論上計(jì)算機(jī)的本質(zhì)和設(shè)計(jì)思想永遠(yuǎn)不會(huì)過時(shí)， 但是你一旦停止了自身對(duì)新技術(shù)的汲取，你可能會(huì)很快被淘汰。
  閱讀全文      摘要: 遠(yuǎn)程線程作為一項(xiàng)"合法"的代碼注入技術(shù)，在windows上被大量使用， 它的本質(zhì)就是把一塊可執(zhí)行代碼寫入到對(duì)方進(jìn)程，然后讓其起運(yùn)行。
一般它的實(shí)現(xiàn)過程是這樣的， 通過VirtualAllocEx在目標(biāo)進(jìn)程分配內(nèi)存空間，然后通過WriteProcessMemory將我們的可執(zhí)行代碼寫入到目標(biāo)進(jìn)程，最后通過CreateRemoteThread讓我們的可執(zhí)行代碼在目標(biāo)進(jìn)稱里運(yùn)行起來。  閱讀全文      摘要: 從理論上來說，Metro開發(fā)也是windows上最新技術(shù)的集合，有C++11的支持，有GPU加速支持的D3D(D2D)引擎，有面向?qū)ο蟮目缯Z言(元數(shù)據(jù)描述)的WinRT類庫(kù)，有通過標(biāo)記(XAML)描述的界面， 而且它是Native的(非托管)，所以性能上也有保障。  閱讀全文      摘要: 我們發(fā)現(xiàn)設(shè)計(jì)模式在Java社區(qū)很流行，但是在C++社區(qū)卻沒有那么被關(guān)注，甚至有點(diǎn)被排斥，究竟是什么原因造成這個(gè)差異的呢？  閱讀全文      摘要: 那么究竟什么時(shí)候適用這種接口方式呢？
我的看法是只有當(dāng)你的模塊是一個(gè)單獨(dú)的子系統(tǒng)，當(dāng)對(duì)外提供功能時(shí)，才可以這么做。這里的子系統(tǒng)不一定要是一個(gè)很大的概念，比如一個(gè)窗口，一個(gè)COM對(duì)象都可以稱為簡(jiǎn)單的子系統(tǒng)，但是它的前提要求是獨(dú)立，對(duì)外，并且最好你可以預(yù)見到以后它的功能會(huì)改變和擴(kuò)充。  閱讀全文      摘要: 可以看到使用第二種實(shí)現(xiàn)我們只存儲(chǔ)了一份字符串圖像數(shù)據(jù)，同時(shí)有保留了圖像的層次和結(jié)構(gòu)屬性，實(shí)現(xiàn)時(shí)包含了很多設(shè)計(jì)模式，比如Template, Decorate, Composite, Facade等，簡(jiǎn)單而高效。
  閱讀全文      摘要: 在寫DirectUI時(shí)有這么一個(gè)需求，就是加載一串XML，如何生成一棵對(duì)應(yīng)的控件樹？  閱讀全文      摘要: 思考一個(gè)優(yōu)秀windows C++ 程序員該有哪些知識(shí)，可最終發(fā)現(xiàn)什么知識(shí)都不能少， 看下圖：

PS: 和同事討論， 其他職業(yè)（比如司機(jī)或是廚師），他們只要學(xué)完基本的技能后就可以一勞永逸了，學(xué)的知識(shí)也比我們少的多，也不用擔(dān)心新技術(shù)的更替。

所以感覺程序員真的挺累， 如果不是出于興趣，注定是干不久的; 付出這么多，工資比其他職業(yè)高一點(diǎn)，其實(shí)并沒賺到什么。

呵呵，不知大家怎么看？  閱讀全文      摘要: Windbg的命令分為標(biāo)準(zhǔn)命令，原命令和擴(kuò)展命令，輸入問號(hào)(?)可以顯示所有的標(biāo)準(zhǔn)命令的幫助信息; 元命令以一個(gè)點(diǎn)(.)開始，輸入.help可以顯示所有的原命令的幫助信息;擴(kuò)展命令以嘆號(hào)(!)開始  閱讀全文      摘要: Lambda, auto, 統(tǒng)一初始化，智能指針，Regex, Random,
function and bind， hash_map…
右值引用和Move語義, 并發(fā)(多線程庫(kù))…發(fā)布  閱讀全文      摘要: 介紹如何讓自己的程序支持Javascript腳本， 并提供一個(gè)簡(jiǎn)單的Demo  閱讀全文      摘要: Win8 Metro 相關(guān)的一些開發(fā)資料  閱讀全文      摘要: widnows下多用戶多桌面的原理  閱讀全文      摘要: 在帖子 "如何判斷一個(gè)C++對(duì)象是否在堆棧上” 中， 又有人提出如何判斷一個(gè)C++對(duì)象是否在堆上。  閱讀全文      摘要: 要解答這個(gè)問題，其實(shí)就是要知道的堆棧的起始地址， 而我們知道堆棧其實(shí)就是一段有相同屬性的內(nèi)存頁(yè)面  閱讀全文      摘要: 新版的QQ在截圖時(shí)加入了窗口自動(dòng)識(shí)別的功能，能根據(jù)鼠標(biāo)的位置自動(dòng)畫出下面窗口的輪廓。今天有人在論壇上問起這個(gè)問題，下面我們來探討這個(gè)功能的實(shí)現(xiàn)原理。  閱讀全文      摘要: 在高效C++編程中看到一個(gè)不錯(cuò)的內(nèi)存池實(shí)現(xiàn)方案，這里共享下，大家看看有什么不足。  閱讀全文      摘要: 引用計(jì)數(shù)在軟件開發(fā)中是一項(xiàng)非常重用的技術(shù)，它可以說是無處不，我們?cè)诓恢挥X中都在和它打交道，比如 Windows上的COM和Handle， Mac上的ref句柄，腳本語言中的垃圾回收技術(shù)。  閱讀全文      摘要: 好我一個(gè)月前看到一個(gè)視頻，這個(gè)演講視頻還比較著名，這個(gè)演講者是Exceptional C++ 和 C++ Coding Standards 的作者，還是ISO C++ 委員會(huì)的Chair，C++/CLI首席架構(gòu)師，還是Microsoft的軟件架構(gòu)師，他叫Herb Sutter，他的這個(gè)演講視頻是 C++ and Beyond 2011上的一次公開演講，題目是——Why C++? （如果你覺得那里的視頻比較慢，你可以看優(yōu)酷上的視頻）（英文聽力好的同學(xué)可以看一樣，因?yàn)槎紱]有中文字幕）  閱讀全文