vc2008中，mfc將大幅度地更新。我猜測(cè)更新mfc的原因，很可能mfc中的一些代碼阻礙了vc的進(jìn)一步發(fā)展，不得不加以更新。
我以前曾經(jīng)提起過，mfc有一個(gè)嚴(yán)重違背c++標(biāo)準(zhǔn)的地方：
class H;
class S
{
public:
x() {
H* pThis=this-offsetof(m_s, H);
...
}
};
class H
{
S m_s;
};
H里包含S的對(duì)象，在S里，為了獲得宿主類H的指針，用自身的this指針減去m_s在H中的偏移量。這就要求一個(gè)類中的子對(duì)象必須同宿主對(duì)象放在一起
（連續(xù)分布），并且固定（偏移量永遠(yuǎn)不變）。為了在對(duì)象布局上給予編譯器充分的自由，標(biāo)準(zhǔn)規(guī)定offsetof只能用于pod。mfc僅考慮在
vc上使用，所以為了方便而僅僅面向vc編譯器編碼。這帶來了移植性的問題。不過，編譯器間的移植性還是小事。現(xiàn)在我們就可以看到mfc的這種做法是搬起
石頭砸自己的腳。
sutter和lippman都不止一次地提到將來vc要能夠不區(qū)分托管和本地的內(nèi)存管理。也就是說托管的類型可以在native堆上分配，而
native的類型可以在托管堆上分配。問題來了，由于托管堆上，子對(duì)象和宿主對(duì)象的存放不是連續(xù)的，子對(duì)象可能同宿主對(duì)象隔著十萬八千里，和成千上萬的
對(duì)象。而且子對(duì)象可能會(huì)在宿主對(duì)象的前面。offset也是不確定的。在這種情況下，使用上面的這種代碼無異于自殺。所以，為了實(shí)現(xiàn)托管和本地內(nèi)存管理的
統(tǒng)一，必須放棄offsetof這類畸形代碼。由此導(dǎo)致了mfc的大幅更新。
另一方面，vc越來越符合標(biāo)準(zhǔn)，而mfc中一些遺留的其他不符合標(biāo)準(zhǔn)的地方，使得編譯器不得不同時(shí)應(yīng)付兩種情況：標(biāo)準(zhǔn)的和非標(biāo)的。對(duì)編譯器著實(shí)是個(gè)負(fù)擔(dān)，消除這些非標(biāo)的東西，反而能夠使得編譯器更加簡(jiǎn)單高效。
以上這些都是猜測(cè)，實(shí)際如何，還需具體看2008的mfc庫(kù)代碼。不管怎么樣，如果你想要使自己的代碼依賴于非標(biāo)準(zhǔn)的特性的話，請(qǐng)三思而后行。