http://topic.csdn.net/u/20090526/08/7cbebc84-6468-4caa-933c-23f7f2f99d93.html?seed=312377267

?

此貼讓我有此感覺：量子物理上講“測不準原理”，這是普世通理，計算機領域也有此現像。你想要速度么？就無法精確。

?

C++的指針問題，永遠也說不完。STL容器與智能指針的不合理搭配，導致的對“值”語義（可安全復制，本體和復本生存期內無構造，無析構）的破壞，容器對像foreach時引發的異常行為。

?

而C#做為一種POOP（Pure OOP），使用“引用”加“堆對像”，使用GC來管理生存期，不再受制于{}，消滅了C++的類似問題。但是效率又是一個問題。

?

GC的意義非同一般啊。

?

http://msdn.microsoft.com/zh-cn/library/ms235267.aspx

從 C++ 托管擴展到 Visual C++ 2008，值類型的語義已發生的更改。

?

不再存在值類默認構造函數

托管擴展和新語法之間的值類型的一個差異是移除了對默認構造函數的支持。這是因為在執行過程的某些情況下，CLR 可以在不調用關聯的默認構造函數的情況下，創建值類型的實例。也就是說，在托管擴展下嘗試支持值類型內的默認構造函數實際上不能得到保證。在不能得到保證的情況下，最好完全刪除支持，而不是使其在應用程序中變得不確定。

這至少不會像最初看起來那樣糟糕。這是因為值類型的每個對象會自動被賦予零值（即，每個類型都初始化為其默認值）。結果是，永不取消本地實例的成員定義。從這種意義上來說，不能定義常用的默認構造函數根本不是一種損失——事實上，如果由 CLR 執行將更為有效。

問題出現在托管擴展用戶定義非常用的默認構造函數時。此時，沒有到新語法的映射。構造函數內的代碼需要遷移到一個命名初始化方法中，然后需要由用戶來顯式調用該方法。

否則，新語法內值類型對象的聲明不會更改。這樣做的缺點是：由于下列原因，值類型對本機類型的包裝具有以下缺陷：

• 不支持值類型內的析構函數。也就是說，無法自動化由對象的生存期結束而觸發的一組操作。

• 本機類只能作為指針包含在托管類型內，然后在本機堆上分配該指針。

我們希望在值類型（而不是引用類型）中包裝小的本機類，以避免雙堆分配：本機堆保存本機類型，而 CLR 堆保存托管包裝。在值類型內包裝本機類使您可以避免托管堆，但它無法自動回收本機堆內存。引用類型是可在其中包裝非常用本機類的唯一可行的托管類型。

總結

以上是生活随笔為你收集整理的“测不准原理”在计算机领域的体现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。