Re: Simple instance [[alloc] init] question.

2010-08-30 Thread Kyle Sluder
On Aug 30, 2010, at 9:36 PM, Dave Geering  wrote:

> 
> I apologise. I was going to explain each one in terms of ownership,
> but I couldn't figure out a way to explain how you own something twice
> without talking about reference counts. I should probably refrain from
> replying to the list any time in the morning.

You might follow the static analyzer's lead and call them "references." For 
example, +alloc returns a +1 (ownership) reference. You could then talk about 
gaining another +1 reference through the retain property, and abandoning the 
one received from +alloc.

Ownership is really a characterization of an object's responsibility, so I find 
it awkward to talk about it as if it were a token passed rather than a status 
conferred by said token.

When explaining the memory management rules, though, particularly on the list, 
sticking to Apple's preferred nomenclature is important for keeping the 
narrative clear. To be consistent while following the above rubric, I would say 
"You have violated the memory management rules and created a leak. You became 
the object's owner through obtaining a +1 reference from +alloc and failed to 
follow up on your obligation as owner to release the reference. Instead, you 
have abandoned the initial +1 reference to the void, and created an additional 
one through the implicit -retain in the property setter."

This has the benefit of being able to point to a state of execution and say "at 
this point, foo holds a +2 reference to bar." Coworkers who have been in the 
game much longer are prone to say "foo has a +2 retain count on bar," but for 
the purposes of this list that might confer unwanted approval on inspection of 
-retainCount.

Of course, not being an Apple technical writer I don't know if this passes 
muster with the folks who care the most. ;-)

--Kyle Sluder___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Simple instance [[alloc] init] question.

2010-08-30 Thread Dave Geering
>>> // 1)
>>> self.serialIDs = [[IRMSerialDetailsDO alloc] init];
>>
>> The alloc method allocates an instance with a retain count of 1, and
>> assigning it to the serialIDs property bumps it up to 2. In your
>> dealloc method, you will [hopefully] send it a release message which
>> puts it back at 1, but this means the object still survives (i.e. it
>> is not deallocated).
>>
>>> // 2)
>>> IRMSerialDetailsDO *mySerialIDDO = [[IRMSerialDetailsDO alloc] init];
>>> self.serialIDDO = mySerialIDDO;
>>> [mySerialIDDO release];
>>
>> Here, the alloc creates the instance with a retain count 1, assigning
>> it to the property bumps it up to 2, and the release right afterwards
>> puts it back down to 1. In your dealloc method, you will sent it
>> another release message which puts it at 0, and therefore the instance
>> is deallocated.
>>
>
> This is at best misleading, and illustrates why people are typically 
> discouraged from reformulating the memory management rules.
>

I apologise. I was going to explain each one in terms of ownership,
but I couldn't figure out a way to explain how you own something twice
without talking about reference counts. I should probably refrain from
replying to the list any time in the morning.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Simple instance [[alloc] init] question.

2010-08-30 Thread mmalc Crawford

On Aug 30, 2010, at 6:37 PM, Dave Geering wrote:

>> // 1)
>> self.serialIDs = [[IRMSerialDetailsDO alloc] init];
> 
> The alloc method allocates an instance with a retain count of 1, and
> assigning it to the serialIDs property bumps it up to 2. In your
> dealloc method, you will [hopefully] send it a release message which
> puts it back at 1, but this means the object still survives (i.e. it
> is not deallocated).
> 
>> // 2)
>> IRMSerialDetailsDO *mySerialIDDO = [[IRMSerialDetailsDO alloc] init];
>> self.serialIDDO = mySerialIDDO;
>> [mySerialIDDO release];
> 
> Here, the alloc creates the instance with a retain count 1, assigning
> it to the property bumps it up to 2, and the release right afterwards
> puts it back down to 1. In your dealloc method, you will sent it
> another release message which puts it at 0, and therefore the instance
> is deallocated.
> 


This is at best misleading, and illustrates why people are typically 
discouraged from reformulating the memory management rules.

First, from the original post:
> .h

> @property(nonatomic, release) IRMSerialDetailsDO *serialIDs;
> ...
> .m
> @synthesize mySerialIDDO
> 
This is just wrong.
There is no 'release' keyword for a property declaration, and the name of the 
property in the declaration does not match that in the synthesize statement.

Assuming that the intent was:

.h
@property(nonatomic, retain) IRMSerialDetailsDO * mySerialIDDO;
...
.m
@synthesize mySerialIDDO


then if you set the mySerialIDDO variable using the corresponding accessor 
method, you end up owning the object. It is your responsibility to subsequently 
relinquish ownership in dealloc. Whether or not this results in the object 
being deallocated depends on what other objects may have claimed ownership in 
the interim, and is of no interest to you.

As others have noted, adhering to the memory management rules 
(),
 by convention this results in a memory leak:

self.serialIDs = [[IRMSerialDetailsDO alloc] init];

To address the issue of the second pattern:

> IRMSerialDetailsDO *mySerialIDDO = [[IRMSerialDetailsDO alloc] init];
> self.serialIDDO = mySerialIDDO;
> [mySerialIDDO release];
> 

This is explained in the Your First iOS Application tutorial:



It is, and remains, best practice to avoid using autorelease where possible. 
Autoreleasing objects means they may end up living longer than is strictly 
necessary, and this adds to your application's memory footprint. Not something 
you want on a deive with a constrained amount of memory.

mmalc










___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Simple instance [[alloc] init] question.

2010-08-30 Thread Scott Anguish
Assuming his @property was supposed to be (nonatomic,retain)

We did the release explicitly when doing some sample code on iPhone. We didn’t 
want the autorelease pool to grow.

IRMSerialDetailsDO *mySerialIDDO = [[IRMSerialDetailsDO alloc] init];
self.serialIDDO = mySerialIDDO;
[mySerialIDDO release];

So this wasn’t that far off.

Not sure if it’s still the same suggestion.

Oh David...?


On Aug 30, 2010, at 10:01 PM, Charles Srstka wrote:

> On Aug 30, 2010, at 7:23 PM, Frederick C. Lee wrote:
> 
>> // 1)
>> self.serialIDs = [[IRMSerialDetailsDO alloc] init];
> 
> This is, as mentioned, a leak, although if performance is not an issue, you 
> can still have the simplicity:
> 
> self.serialIDs = [[[IRMSerialDetailsDO alloc] init] autorelease];

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Simple instance [[alloc] init] question.

2010-08-30 Thread Charles Srstka
On Aug 30, 2010, at 7:23 PM, Frederick C. Lee wrote:

> // 1)
> self.serialIDs = [[IRMSerialDetailsDO alloc] init];

This is, as mentioned, a leak, although if performance is not an issue, you can 
still have the simplicity:

self.serialIDs = [[[IRMSerialDetailsDO alloc] init] autorelease];

Charles___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Simple instance [[alloc] init] question.

2010-08-30 Thread Dave Geering
> // 1)
> self.serialIDs = [[IRMSerialDetailsDO alloc] init];


The alloc method allocates an instance with a retain count of 1, and
assigning it to the serialIDs property bumps it up to 2. In your
dealloc method, you will [hopefully] send it a release message which
puts it back at 1, but this means the object still survives (i.e. it
is not deallocated).

> // 2)
> IRMSerialDetailsDO *mySerialIDDO = [[IRMSerialDetailsDO alloc] init];
> self.serialIDDO = mySerialIDDO;
> [mySerialIDDO release];

Here, the alloc creates the instance with a retain count 1, assigning
it to the property bumps it up to 2, and the release right afterwards
puts it back down to 1. In your dealloc method, you will sent it
another release message which puts it at 0, and therefore the instance
is deallocated.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Simple instance [[alloc] init] question.

2010-08-30 Thread Brian Slick
#1 is a leak.

(I'm assuming that "release" is supposed to be "retain" in the property 
declaration)

Brian

On Aug 30, 2010, at 8:23 PM, Frederick C. Lee wrote:

> Which is the preferred method of object allocation & initialization?
> 
> .h
> @property(nonatomic, release) IRMSerialDetailsDO *serialIDs;
> ...
> .m
> @synthesize mySerialIDDO
> 
> ...
> // 1)
> self.serialIDs = [[IRMSerialDetailsDO alloc] init];
> 
> or...
> 
> // 2)
> IRMSerialDetailsDO *mySerialIDDO = [[IRMSerialDetailsDO alloc] init];
> self.serialIDDO = mySerialIDDO;
> [mySerialIDDO release];
> 
> 
> I would assume #1 is the simplest, but I see a lot of #2 .
> 
> Thoughts?
> 
> Ric.
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/brianslick%40mac.com
> 
> This email sent to briansl...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Simple instance [[alloc] init] question.

2010-08-30 Thread Frederick C. Lee
Which is the preferred method of object allocation & initialization?

.h
@property(nonatomic, release) IRMSerialDetailsDO *serialIDs;
...
.m
@synthesize mySerialIDDO

...
// 1)
self.serialIDs = [[IRMSerialDetailsDO alloc] init];

or...

// 2)
IRMSerialDetailsDO *mySerialIDDO = [[IRMSerialDetailsDO alloc] init];
self.serialIDDO = mySerialIDDO;
[mySerialIDDO release];


I would assume #1 is the simplest, but I see a lot of #2 .

Thoughts?

Ric.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com