vc2008中，mfc將大幅度地更新。我猜測更新mfc的原因，很可能mfc中的一些**阻礙了vc的進一步發展，不得不加以更新。
我以前曾經提起過，mfc有乙個嚴重違背c++標準的地方：
class h;
class s
}; class h
; h裡包含s的物件，在s裡，為了獲得宿主類h的指標，用自身的this指標減去m_s在h中的偏移量。這就要求乙個類中的子物件必須同宿主物件放在一起 （連續分布），並且固定（偏移量永遠不變）。為了在物件布局上給予編譯器充分的自由，標準規定offsetof只能用於pod。mfc僅考慮在 vc上使用，所以為了方便而僅僅面向vc編譯器編碼。這帶來了移植性的問題。不過，編譯器間的移植性還是小事。現在我們就可以看到mfc的這種做法是搬起 石頭砸自己的腳。
sutter和lippman都不止一次地提到將來vc要能夠不區分託管和本地的記憶體管理。也就是說託管的型別可以在native堆上分配，而 native的型別可以在託管堆上分配。問題來了，由於託管堆上，子物件和宿主物件的存放不是連續的，子物件可能同宿主物件隔著十萬八千里，和成千上萬的 物件。而且子物件可能會在宿主物件的前面。offset也是不確定的。在這種情況下，使用上面的這種**無異於自殺。所以，為了實現託管和本地記憶體管理的 統一，必須放棄offsetof這類畸形**。由此導致了mfc的大幅更新。
另一方面，vc越來越符合標準，而mfc中一些遺留的其他不符合標準的地方，使得編譯器不得不同時應付兩種情況：標準的和非標的。對編譯器著實是個負擔，消除這些非標的東西，反而能夠使得編譯器更加簡單高效。
以上這些都是猜測，實際如何，還需具體看2008的mfc庫**。不管怎麼樣，如果你想要使自己的**依賴於非標準的特性的話，請三思而後行。
blog更新變慢的原因
由於換了工作，一直在黃區。最近學習了fork程序的排程流程，也寫了總結文件。但是無法帶出來。所以，會對更新blog造成一些阻礙 我原本計畫的是乙個月至少更新一篇 只能通過記憶，出了黃區重新再根據開源 寫一遍。目前計畫是這樣的 我先在黃區總結，出了黃區再重寫，發blog。累是累點，不過也能再鞏固一下，...
更新UI放在主線程的原因
1 在子執行緒中是不能進行ui 更新的，而可以立刻更新的原因是 子執行緒 執行完畢了，又自動進入到了主線程，這中間的時間非常的短，讓我們誤以為子執行緒可以更新ui。如果子執行緒一直在執行，則無法更新ui,因為無法進入到主線程。2 程式一開始執行就進入了主線程。3 處理某些資料太過費時，影響使用者互動...
VS2010編譯MFC程式出錯的原因
在已經安裝了vs2008的計算機上安裝vs2010，用vs2010新建乙個mfc程式，編譯都通不過，錯誤如下 1 stdafx.cpp 1 d program files microsoft visual studio 10.0 vc atlmfc include afxglobals.h 375 ...