“測不準原理”在電腦領域的體現

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 堆儲存託管封裝。在實值型別內封裝本機類使您可以避免託管堆，但它無法自動回收本機堆記憶體。參考型別是可在其中封裝非常用本機類的唯一可行的託管類型。