“测不准原理”在计算机领域的体现

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 堆保存托管包装。在值类型内包装本机类使您可以避免托管堆，但它无法自动回收本机堆内存。引用类型是可在其中包装非常用本机类的唯一可行的托管类型。