6

When should retain be used ? I understand that it increments the object references count, so basicly the next release on that object will not call dealloc on it. Ok great, so what ? I read around that it's some kind of convention, that if you care about an object, you retain it. Is there any examples of that out there ? Is that even true ?

EDIT:

I'm not looking for when the debugger tells you to do that or this. So, I looked into this.

To put it in my words, here's an example of a retain usage

  • in your code, you somewhere invoke a method a method that returns an object that you don't own
  • you work with that object
  • then you want to release it => you can't because you're not the owner
  • your solution is to either use copy or retain. If you user retain, then you would get ownership of that object.
  • then to release that object, you either perform 2 release (since ref count is 1+1 when you retain) or directly use dealloc on it

Is that it ? I don't think so because an object can have multiple owner. So for the last point, calling dealloc will really "kill" the object ; but with 2 release, you won't be owner, but the program that created it would still be, therefore the objects is stil alive somewhere (leak ? zombie ?)

Please I'm confused.

Abizern
  • 146,289
  • 39
  • 203
  • 257
Marcel Falliere
  • 1,884
  • 21
  • 39
  • possible duplicate of [Memory Management in Objective-C ](http://stackoverflow.com/questions/106627/memory-management-in-objective-c) – Abizern Dec 15 '10 at 14:05
  • i don't see a need for a downvote on this. upvoted – Bourne Dec 15 '10 at 14:06
  • I'm so confused with retain. I just don't get why one would use it. I tried to express how I would use it in the edit i just did.. – Marcel Falliere Dec 15 '10 at 14:46
  • 1
    Your edit is incorrect: you should never call dealloc directly. And you should also not call two releases. Balance the number of retain and release within a method or class. – Felix Lamouroux Dec 16 '10 at 10:56

4 Answers4

6

All your answers are found in the Memory Management Guide.

EDIT

Following your edit, here's a bit more specific detail:

in your code, you somewhere invoke a method a method that returns an object that you don't own

Because you don't own it you have no control over it's lifetime. It could be released while you are still relying on it being a valid object.

you work with that object

Never sure that it is going to exist.

then you want to release it => you can't because you're not the owner

But why would you want to release it? You don't own the object so you aren't responsible for it's memory management.

It looks as if you want to call release because you think that is how you manage memory, and that the retain is what let's you call it.

Here is the way it should work:

  • You invoke a method that returns an object. If you haven't received this object by callingalloc, new, copy or mutableCopy then accoriding to the Memory Management Guide you don't own the object, so you aren't responsible for managing this memory.
  • In most cases you can assume that you have been passed an autoreleased object. That means that you have no control over it's lifetime. To make sure that it doesn't get released before you are done with it, you call retain on the object. You now own this object and are responsible for calling release on it at some time in the future. It is a beginner's mistake to now be concerned about the retain count on the object. Don't be. All that matters is that you are responsible for calling release on it.
  • You use the object keeping in mind the general memory management paradigm. For example, if you add this object to an NSArray then it will be retained by the array.
  • Once have have done what you need to do with the object, you call release on it. Again. Don't concern yourself with the object's retain count, or what other objects are using this object. All that matters is that you have balanced your calls to retain with an equal number of calls to release.
Abizern
  • 146,289
  • 39
  • 203
  • 257
1

I usually just use retain explicitly when there is a need to and the Xcode debugger tells me what just happened when such a situation arises. Usually for whatever reason (mismanagement on the developer's part or if there is some release going on behind the scenes), you do anything on a released object, you'd get a crash. Just read the log on the console, see the debugger on Xcode when you debug and you figure out usually which object is causing the problem.

Bourne
  • 10,094
  • 5
  • 24
  • 51
0

Marcel, memory management is a crucial point developing iOS Apps. You should consider read the Apple documentation about it as suggested by the other guys.

I can add here some information to try to help you with your needs.

The memory management process with Obj-C is count base. It means any time you 'retain' some object the system improves a counter for this object. For example, if you create a button and 'retain' it, it will have a value 1. If you retain it again, it will have a value 2. To destroy this object completely, you will need to release it twice. Any time an object has a value 0 it will be destroyed.

My personal opinion: If you want to have a good control about the memory management of your app, it's good to explicitly retain and destroy your objects, avoiding autorelease when possible. Again, it's my personal opinion. I like to be aware of the memory process inside my Apps, that's why I prefer to take care of this precisely.

Sure it's not the BEST way, each developer will prefer to use a different approach managing memory.

Again: take some time to read the documentation Abizem suggested you. Sure you will have a better understanding about it.

Trinca
  • 1,606
  • 1
  • 15
  • 17
  • Thanks Trinca. Seems retain has to be used in the same way of css z-index... you want to keep your element in front so you put a big fat value. Is it the same for retain ? You want your object absolutly alive (why? dunno!) so you retain it one or two times... ?? – Marcel Falliere Dec 15 '10 at 14:48
  • 2
    @Marcel Nope! Definitely not. You retain an object when you want to keep it around outside of the current scope and you release an object that you have taken ownership of. You never retain multiple times just to be safe. – kubi Dec 15 '10 at 14:53
  • @Marcel - memory management is something you need to be aware. You don't need to retain an object multiple times, but you need to keep track of how your app is using this object because at any time you will need to destroy it and you must know how to do it. Or, once it's destroyed, when to initialize it again. Remember that it's to maintain your app and the system running in a safe way. – Trinca Dec 15 '10 at 15:00
  • @kubi weel said. What do you think is a good real world example of that ? Do you think, for instance, that `UIViewController` uses retain when for its getters ? In my app, if I say `[[self view]release]`, what will it do ? Is `retain` only for plugin/framework developers ? I miss a good example – Marcel Falliere Dec 15 '10 at 21:21
-1

Check the Objective-C beginners guide for basic usage

bertolami
  • 2,896
  • 2
  • 24
  • 41