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

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

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

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

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

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

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

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