The embodiment of "Uncertainty Principle" in the computer field

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

 

This post makes me feel this way: in quantum physics, we talk about the principle of uncertainty. This is a universal principle, and this is also true in the computer field. Do you want speed? It cannot be accurate.

 

The pointer problem of C ++ can never be solved. The unreasonable combination of STL containers and smart pointers leads to the destruction of the "value" Semantics (secure replication, no constructor and no destructor during the lifetime of the ontology and replica, abnormal behavior caused by a container like foreach.

 

C # IsPoop(Pure OOP), uses "reference" and "heap object", uses GC to manage the lifetime, no longer subject to {}, and eliminates similar problems of C ++. However, efficiency is a problem.

 

The significance of GC is extraordinary.

 

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

Extended from C ++ hosting to Visual C ++ 2008, the semantics of the value type has changed.

 

No value class default constructor exists

A value type between the managed extension and the new syntaxDifferenceYes removed support for default constructor. This is because in some cases during execution, CLR can create value-type instances without calling the associated default constructor. That is to say, it is not guaranteed to try to support the default constructor in the value type under the managed extension. If no guarantee is available,It is best to delete all supportedInstead of making the appProgramIt becomes uncertain.

This is at least not as bad as it initially looks. This is because each object of the value type is automatically assigned a zero value (that is, each type is initialized to its default value ). The result is,Never cancel member definitions of local instances. In this sense, common Default constructors cannot be defined.It is not a loss at all-- In fact, it will be more effective if executed by CLR.

The problem occurs when the default constructor is very useful for hosting Extended user definitions. At this time, there is no ing to the new syntax. In the constructorCodeYou need to migrate to a naming initialization method, and then you need to explicitly call this method.

Otherwise, the declaration of the Value Type object in the new syntax will not be changed. The disadvantage of doing so is that the value type has the following defects for local packaging due to the following reasons:

• Destructor within the value type is not supported. That is to say, it is impossible to automate a group of Operations triggered by the end of the object's lifetime.

• The local class can only be included as a pointer in the managed type, and then allocated to the local stack.

We want to wrap a small local class in the value type (rather than the reference type) to avoid dual heap allocation: The local heap saves the local type, while the CLR heap saves the hosted packaging. Wrap the local class in the value type so that you can avoid hosting the heap, but it cannot automatically recycle the local heap memory. The reference type is the only viable hosting type in which the native class can be encapsulated.