Nil, nil, NULL, NSNull zombie objects, and wild pointers in IOS

One, nil, NSNull, nil, NULL difference

1. Nil
When we assign a value to an object, we generally use object = nil, which means I want to release the object;
Or the object for some reason, after several releases, so the object reference counter is 0, the system will release this memory, this time this object is nil, I call it "empty object". (Note: I emphasize here is "empty object", below I will take it and "value is empty object" against!!! ）
So for this empty object, all operations on retain will cause the program to crash, such as dictionary add key value or array to add new primitives, etc., refer to the following code:

2, NSNull
The difference between nsnull and nil is that nil is an empty object that has completely disappeared from memory, and if we want to express the idea that we need to have such a container but nothing in this container, we use nsnull, which I call "the object with a value of NULL." If you look at the development documentation you will find NSNull this class is inherited nsobject, and there is only one "+ (NSNull *) null;" Class method. This means that the Nsnull object has a valid memory address, so any references to it in the program will not cause the program to crash. The reference code is as follows:

3. Nil
Nil and nil are not strictly limited in use, which means that nil can be used wherever nil is substituted, and vice versa. But from the programmer's Statute we have conventionally represented nil as an empty object, and nil represents an empty class. The reference code is as follows:

4, NULL
We know that object-c originates from C, supports C, and of course differs from C. And Null is the typical C language syntax, which represents a null pointer, the reference code is as follows:
int *ponit = NULL;

Second, wild hands, zombie pointers, zombie objects

Wild Hands

First, to introduce the wild pointer, the definition of a wild pointer in C + + is: The wild pointer is a pointer to the garbage memory, the pointer address is not NULL. If you assign a pointer to null, the pointer is a null pointer and can be interpreted with an if statement. However, for wild pointers, you cannot use an if statement to judge.

The reason why the wild pointers are produced

1) The pointer variable is not initialized. Any pointer is not automatically assigned NULL when it is created, and if it is not initialized, the memory address it points to is indeterminate. Therefore, it should be initialized at the time of creation.

Char *ptr = Null;char *str = (char*) malloc (32);

2) After the pointer is released (free or malloc), it is not set to null and is mistakenly assumed to be a legitimate pointer.

void function (void)  {      char* str = new char[100];      delete[] STR;      Do something      strcpy (str, "dangerous!!");  

3) The pointer operation is outside the scope of the variable.

Class A {public        :        void Func (void) {cout << "Func of Class A" << Endl;}}; void Test (void) {    A *p;    {        a A;        p = &a;    Note the lifetime of a    }    p->func ();        P is "Wild Pointer"}

When the function Test executes the statement p->func (), object A has disappeared, and P is pointing to a, so p becomes the "wild pointer".

Zombie Pointer

A "zombie pointer" is a case of a wild pointer, where the object pointed to by the pointer has been disposed, but the current pointer is not assigned a value of nil.

Zombie Objects

In simple terms, a zombie object is an object that has been disposed of. If you use the object again in your program, you will usually get the following error:

Unrecognized selector sent to instance

Today, I encountered an error like this:

Solution Solutions

You can set the nszombieenabled environment variable in the Xcode scheme page. Click Product-->edit Scheme to open the page, and then tick the Enable Zombie Objects check box. As shown in the following:

The nszombieenabled variable is used to debug memory-related problems and to track the release process of an object. With nszombieenabled enabled, it replaces the default Dealloc implementation with a zombie, which translates the object into a Zombie object when the reference count drops to 0 o'clock. The purpose of a zombie object is that when you send a message to it, it displays a log and automatically jumps into the debugger. When Nszombie is enabled instead of having the app crash directly, an erroneous memory access becomes an unrecognized message to the zombie object. The Zombie object displays the received information and then jumps into the debugger so you can see exactly where the problem is.

Why not turn on zombie object detection by default?

Because once turned on, each time the object is accessed through the pointer, it checks to see if the object pointed to by the pointer is a zombie object. Therefore, it will affect the execution efficiency of the program, it is recommended to close.

Reference:
Http://www.jianshu.com/p/2b44e1c346e7

Http://www.cnblogs.com/tgycoder/p/5661431.html

Nil, nil, NULL, NSNull zombie objects, and wild pointers in IOS