Object-C learning notes: Memory Management

Roughly record the memory management mechanism of Object-C, and mark it in a confused place. I hope that later learning will solve the problem.

Manual release and reference count:
Familiar with the development of windows, the reference count should be no stranger. Any "object" (can be a class instance or a resource) maintains a variable internally, called a counter. when an object is initially converted into 1, any reference to this object will add one to the counter, and the same unreference will reduce the counter by one. When the counter value is 0, the object will be destroyed. The reference count allows a resource (object) to be used in multiple places. The scenario class only needs to care about when the resource is required and when it is not required.
Use the following functions to manage the lifetime of an object in object-C:
Retain-> counter plus one
Realse-> subtract one from the counter
Note that when the counter is 0, the dealloc of the object is automatically called, which is the destructor.

Code

  @ Interface Engine: nsobject
@ End

@ Implementation engine
@ End

@ Interface car: nsobject
{
Engine  * Engine;
}
@ End

@ Implementation car
  -  (  Void  ) Setterengine: (Engine  *  ) Newengine
{
[Newengine retain];
[Engine release];
Engine  =  Newengine;
}

  -  (  Void  ) Dealloc
{
Nslog (  @" Car is dealloced  "  );
[Super dealloc];
}
@ End

  Int  Main (  Char  Argc,  Char  *  Argv []) {

Car  *  Acar  =  [[Car alloc] init];
Engine  * Engine  =  [Engine  New  ];
[Acar setterengine: Engine];
[Engine release];

[Acar release];

  Return     0  ;
} 

 

Object ownership
Because the objects in object-C are all new, there is no stack object like C ++ (I don't know if it is like this, I am wondering ..), If autorelease or GC is not used, the lifetime management of all objects must beProgramComplete it by yourself. Here we will record the programming usage mentioned in Basic Object-C programming. After the engine in main (scenario) is assigned to the car, it will be useless and it will be immediately release, note that the use of setter functions requires retain newengine first, and then release the old engine. The sequence cannot be wrong. If newengine = oldengine, the engine will be destroyed first.

Automatic release of autorelease
In this case, it is indeed quite tiring to manually manage the reference count. Another method provided in object-C is autorelease. It is easy to use. It generates an automatic release pool and throws all the objects you do not want to manually manage to release the pool destructor or call drain, the objects in it are associated with a release, done...
If you do not want to write it, write a few notes:
1. The new alloc copy object does not use autorelease by default. Other functions, such as initwithstring, use autorelease by default.
2: It is said that the app kit will generate the autoreleasepool by default. You do not need to generate the pool by yourself. You should check it later.Code.
3: It is also said that in the message loop of the app kit, an autoreleasepool is generated before each message is processed, and the pool is eliminated after the message is processed.
4. Do not use autorelease on the iPhone... I am confused about this. Is it the impact of performance...

GC usage
Well, I have to admit that GC has never been well studied, and the GC mechanism of Object-C is not very clear about anything. The usage is the same, and the object is only new, you only need to manage the pointer. You just need to write down nil:
A: This is only object-c2.0, not what version can be used.
2: To use GC, you need to set it in xcode. After all the memory management functions are completed, the function will become invalid. It is probably always precompiled.
3: Do not use GC in the iPhone. This is what the author calls in object-C basic programming. Don't come to me...