Slick's Definitive Guide To Properties

[JoeApps]

Originally Posted by longst

a great tutorial for new comers, especial for someone like me coming from C# and Java.
I am still not sure I did quite understand with this part
"
The same would be true if a new value gets assigned to the property. Remember, the setter will release (-1) the old value, and the object we created is now the old value. So again we are left with a +1 net retain count, again we do not have any means to communicate with the object, and again it is a leak. And as a double-bonus, if the new object is another alloc/init creation, we're replacing a leaked object with another leaked object.
"

Could you please show me a sample code regarding this part Thank you

"For every "alloc or retain" you should have a "release" and vice-versa."

So just using ivars:
someView = [[UIView alloc] init]; // Alloc message sent.

Using accessors:
self.someView = [[UIView alloc] init]; // Alloc and retain message sent.

So if your project was setup up with:
.h
@property (nonatomic, retain) UIView *someView; //telling accessors to include a retain message using the retain attribute.
.m
@synthesize someView;


Step 1: allocates space for the object and initializes it, then "do stuff with object", then releases it.
someView = [[UIView alloc] init];
"Do stuff with object"
[someView release];

someView was released from the allocated space. But now the ivar points to an empty space that once contained your object because you did not nil out the ivar using someView = nil;


Step 2: accessor which will call a release on the old value in Step 1: and retain the new value we see here
self.someView = [[UIView alloc] init]; // Alloc & Retain *Needs 2 releases sometime in the future

but since the old value in step 1 has already used a release for its alloc, it has long already left the place someView is currently still pointing to.

It will crash because it tries to release something not there!

Remember: someView is different than self.someView

FUN ANALOGY

The cookie monsta tells you to stick your hand out and then put a cookie in it (alloc),
you take a bite(do stuff),
then the cookie monsta takes it away from you because he is the cookie monsta and he does what he wants,
"I DO WHAT I WANT!!!"(release sucka!)
OM NOM NOM!

You don't have a cookie anymore and feel sad and hungry....awwwww.
COOKIE MONSTA DON'T CARE!!!

Cookie monsta come back still looking for the cookie in your hand...Again...
(release sucka!)
...but you don't have anything to give the cookie monsta...
COOKIE MONSTA DON'T CARE!!!

He rears up, opens his mouth, and BITES YOUR ARM OFF! OM NOM NOM NOM!

THE END

- It's a harsh life. lol

[BrianSlick]

Don't crap on my thread, bro.

[JoeApps]

Originally Posted by BrianSlick

Don't crap on my thread, bro.

Ha ha! I promise...I won't crap on your thread.

Anyways, you agree with what I have said? Everyone thinks about things a little differently and I was just giving my view on the subject.

Hope all is well,

[BrianSlick]

What's to agree with? You gave a longer answer to a question that was answered a really long time ago (you seem to like digging through old threads - there are plenty of newer threads that need attention), didn't really answer the question that was asked, didn't really say anything that hasn't already been said in this thread, and in addition to being a lame ripoff of the honey badger, your analogy doesn't really clear things up.

[JoeApps]

Ok. Thanks for the feedback. Didn't know about the honey badger...will have to check that out!

[equiinferno]

Hello everyone, especially Slick,
I've been a lurker for quite a while but I just registered to reply to this thread. It's the ultimate eye-opener. If what you say is true, I have to do some serious overhauling to my code-base. Before I do so, I have two questions:

1) Does all of this still apply with ARC enabled?
Specifically, this pattern:

Figure 13
- (void)viewDidLoad
{
   MyClass *newItem = [[MyClass alloc] init];    // Create it
   [self setMyProperty: newItem];                // Do something with it
   [newItem release], newItem = nil;             // Get rid of it, ASAP
}

?

Im guessing yes, hence my second question:
2) Why does the Leak-Instrument not show any leaks allthough I'm doing everything wrong?
As it seems, I've been wildly mis-using & confusing ivars/properties and doing faux pas like this again and again:
self.anIvarArray = [[NSMutableArray alloc] init];
My apps hardly ever crash on the simulator or while profiling via Instruments (Leaks). They run rather stable. However, I do experience lots of random crashes on devices.

Why don't any of these leaks show in the Leak-Instrument? Do these faux pas produce super stealthy-sneaky leaks that the Leak-Instrument doesn't show??

Thank you very much in advance for your help!!

[BrianSlick]

Originally Posted by equiinferno

1) Does all of this still apply with ARC enabled?
Specifically, this pattern:

Figure 13
- (void)viewDidLoad
{
   MyClass *newItem = [[MyClass alloc] init];    // Create it
   [self setMyProperty: newItem];                // Do something with it
   [newItem release], newItem = nil;             // Get rid of it, ASAP
}

?

If you try doing this code in ARC, you will get an error on the 3rd line because release is not allowed in ARC. So you can remove the 3rd line. Otherwise, it still basically applies.

Since you can't do autorelease in ARC either, then your code below is also acceptable.

Properties in general aren't quite as important under ARC, but IMO are still a good idea to use.

Originally Posted by equiinferno

Im guessing yes, hence my second question:
2) Why does the Leak-Instrument not show any leaks allthough I'm doing everything wrong?
As it seems, I've been wildly mis-using & confusing ivars/properties and doing faux pas like this again and again:
self.anIvarArray = [[NSMutableArray alloc] init];
My apps hardly ever crash on the simulator or while profiling via Instruments (Leaks). They run rather stable. However, I do experience lots of random crashes on devices.

ARC: No problem
Not-ARC: This is a leak.

Also, leaks don't cause crashes, or at least not quickly. It is over-releases that will crash.

[equiinferno]

Slick, thank you for your quick reply!!
Huh, so that means (as I am using ARC throughout all projects) I'm actually not doing anything wrong (at least in that regard).

Properties in general aren't quite as important under ARC, but IMO are still a good idea to use.

Could you please elaborate a bit on this? I'm wondering: Is it worth the effort to make sure that I'm using properties throughout all my projects (couple thousand lines of code)?
I'd be highly interested in a "Slick's Definitive Guide To Properties with ARC enabled" )

[BrianSlick]

Well, read the thread. One of the key points I make here is that properties help with memory management. That's what ARC does, too. So, the importance of that particular aspect of properties is reduced under ARC. But this is not the only thing that properties are good for, so you should continue to use them.

As to whether or not you should rewrite a bunch of code, I can't answer that for you.

[fhsjaagshs]

Very useful. Solved many of my problems.