1

I set in my interface.h a property as

@porperty(nonatomic, retain) *foo;

If i don't use this ivar in my implementation should I release it in dealloc ?

DD_
  • 7,230
  • 11
  • 38
  • 59
FR Chalaoux
  • 31
  • 2
  • 2
    Yes, you should - something outside your object may have set it to some object. –  May 14 '13 at 07:36
  • 1
    You should use ARC in your projects its way better in memory management – Ahmed Z. May 14 '13 at 07:46
  • @AhmedZ. no, it isn't better. – justin May 14 '13 at 08:00
  • (that's not to say it's *worse*. just pointing out that it is not factual and merely a statement of preference. It should read: "You should use ARC in your projects because I like it way better" or "You should look into ARC because it has the potential to simplify your program's memory management and abstracts a common source of problems". Reference counting isn't such a complex concept -- it worked for many years before GC and ARC were available, but it was a common source of frustration for people new to the concepts and conventions. MRC can actually be a good deal faster than ARC.) – justin May 14 '13 at 08:14
  • @justin nycly elaborated. MRC...? – Ahmed Z. May 14 '13 at 08:21
  • ARC is good as it saves time.. but Non ARC really teaches you how to handle your memory.. which is its goodness :) – Ahmed Z. May 14 '13 at 08:23
  • @AhmedZ.: Manual Retain Count opposed to Automatic Retain Count (ARC) – Antzi May 14 '13 at 08:23
  • oh got it now. MRC = Non ARC environment. Thanks @Antzi – Ahmed Z. May 14 '13 at 08:25
  • @AhmedZ. ARC = Automatic Reference Counting (i.e. compiler adds reference count operations). MRC = Manual Reference Counting (i.e. writing reference count operations where necessary). "MRC" isn't an official acronym; just a commonly used one which appeared after ARC. – justin May 14 '13 at 08:35
  • 1
    and although *I* still do my own reference counting, I think ARC is the right choice for the typical app/team. – justin May 14 '13 at 08:42
  • @H2CO3, if I release something that is not retain this should cause a problem ? – FR Chalaoux May 14 '13 at 10:52
  • @FRChalaoux Yes. You don't release `weak` and `assign` properties. That's one reason I prefer setting the poperty to `nil` instead of releasing the backing ivar: the setters will **always** do the correct memory management step, but programmers won't. –  May 14 '13 at 11:03
  • @H2CO3, but if really no one retained my object counter will decrease to '-1', could it be a problem ? – FR Chalaoux May 14 '13 at 13:06
  • @FRChalaoux No. An alive object's reference count is not 0, it's 1. –  May 14 '13 at 13:06
  • @H2CO3, you mean my object is not still alive ? – FR Chalaoux May 14 '13 at 13:08
  • @H2CO3, You mean my property/synthesize keywords do not create my object thus I do not need to decrease its counter if no get have be been done !? – FR Chalaoux May 14 '13 at 13:19
  • @FRChalaoux No, I don't mean that, but read Apple's memory management guide, everything is clearly explained in there, and I'm getting tired explaining this. –  May 14 '13 at 13:21
  • @H2CO3, I know this book but "Education is art of repetition", and I had a great pleasure to discuss with you, dear 'coach'. Bye. – FR Chalaoux May 14 '13 at 13:57

2 Answers2

2

Yes:

- (void)dealloc
{
    // Other release code
    [_foo release];

    [super dealloc];
}

EDIT: Thanks to @borrrden for the tip about avoiding setters during dealloc.

trojanfoe
  • 120,358
  • 21
  • 212
  • 242
  • 3
    It is recommended not to use "self" in the dealloc method (for possible KVO problems) and instead to just release (and nil if you want to) the backing variable. – borrrden May 14 '13 at 07:39
  • @borrrden Can you please provide a source for this recommendation. My understanding is that you let the setter do the work for you, which means it must be invoked using `self`. – trojanfoe May 14 '13 at 07:41
  • @trojanfoe [Is there any problem using self.property = nil in dealloc?](http://stackoverflow.com/questions/5621139/is-there-any-problem-using-self-property-nil-in-dealloc), just have a look. ( its a new piece of info for me too) – DD_ May 14 '13 at 07:47
  • 1
    @trojanfoe The link from MicRO shows a source :). That understanding you have is true in general, *except* in init and dealloc. The setter will take care of releasing the current value before retaining the new one. In dealloc though, the new value is nil so it doesn't retain the new value (thus all that is left is releasing the old one). – borrrden May 14 '13 at 07:50
  • @trojanfoe KVO isn't the only reason. this illustration may help: http://stackoverflow.com/questions/5932677/initializing-a-property-dot-notation/5932733#5932733 – justin May 14 '13 at 08:46
  • Why use _foo and not foo when you release it ? – FR Chalaoux May 14 '13 at 10:55
  • @FRChalaoux because `[self.foo release]` is errnoneous - getters do a `- retain - autorelease` on the ivar. –  May 14 '13 at 11:01
  • @borrrden I disagree. Directly manipulating an ivar is not any better than setting the property to `nil`. And yes, I'm aware of the rant you linked, and I don't find it reasonable. –  May 14 '13 at 11:01
  • @ H2CO3, any reference on "getters do a - retain - autorelease on the ivar" ? – FR Chalaoux May 14 '13 at 13:14
  • @H2CO3 That "rant" is quotes from the official Apple documentation...for another thing a subclass could have overridden the setter to do who knows what. – borrrden May 14 '13 at 15:04
-1

yes you should release

for release you can write like this :

- (void)dealloc
{
    // other release stuff

     if(foo != nil)
    {
       [foo release];

       foo = nil;
    }
    [super dealloc];
}
Ushan87
  • 1,608
  • 8
  • 15
Shaik Riyaz
  • 11,204
  • 7
  • 53
  • 70