Re: Autorelease pool questions

FROM : Sven A. Schmidt
DATE : Tue Jan 21 23:38:06 2003

Rakesh,

since none of the gurus has stepped forward yet, I might as well launch
a guess:

NSString is a class cluster and initializing is a bit different in
class clusters, because you get different instances of private
subclasses of the 'front end' class, depending on what kind of
initializer you call.

If you try with NSObject or NSURL in example, you'll get the expected
'1' in both cases.

That's the best I can come up with...

Sven


On Sonntag, Januar 19, 2003, at 09:08  Uhr, Rakesh Pandey wrote:

> Hi All,
>
> Can any one explain:
>
> In my code I create two NSString object like this:
>
> NSString *myString = [[NSSTring alloc] init];
> NSString *myString1 = [[NSString initWithString:@"Rakesh"];
>
> Now I tryt to priont the retain count
>
> NSLog(@"The retainCount for myString = %d \n And thats of myString1 =
> %d",
> [myString retainCount], [myString1 retainCount];
>
> And the results is:
> The retainCount for myString = 2147483647
> And thats of myString1 = 1
>
> I could not understand why is it so ?
>
> Thanks & regards
> Rakesh
> ----- Original Message -----
> From: "Nicholas Riley" <<email_removed>>
> To: "Brian Gilman" <<email_removed>>
> Cc: "Cocoa Dev" <<email_removed>>
> Sent: Monday, January 20, 2003 12:04 AM
> Subject: Re: Autorelease pool questions
>
>

>> On Sun, Jan 19, 2003 at 01:01:23PM -0500, Brian Gilman wrote:
>>

>>>    If all objects are getting placed in this autorelease pool, and
>>> the

> pool

>>> get's released before I return my object out of this method, am I not
>>> sending back a reference to a null object??

>>
>> No.  The runtime does not automatically 'clean up' pointers to
>> deallocated objects, so if you aren't careful you can be sending
>> messages to garbage or to objects of another class.  You're not using
>> references (&var in a C++ declaration), these are real pointers to
>> memory locations with the associated lack of safety.  Setting
>> NSZombieEnabled helps identify these situations by replacing the class
>> of a deallocated object with a 'zombie' that complains if it's
>> messaged.
>>

>>> Or, because I tell the runtime to retain the temporaryObject, this
>>> object's reference count is set to 1 and not collected on the next
>>> clean up cycle?? I may not be using the right terminology here
>>> because I'm new to this stuff so please stick with me on this.

>>
>> The latter, of course.  There are no 'clean up cycles' (e.g. garbage
>> collection passes) in Cocoa; it's relatively determininstic when each
>> object deallocation occurs.  I'm sure several of those articles you
>> were pointed out say this, but just to underscore it:
>>
>> - alloc, retain - increment object's retainCount
>> - release - decrement object's retainCount
>> - autorelease - decrement object's retainCount at some point in the
>>  future
>>
>> - convenience constructors (fooWithBar:), accessors - return objects
>>  which you must retain, to guarantee they stay around once the flow
>>  of control leaves your code (generally function return) or the scope
>>  of the current autorelease pool
>>
>> You're welcome to examine an object's retain count - just send any
>> NSObject the 'retainCount' message and you'll get back a number.
>> OmniObjectMeter will show you the entire retain/release/autorelease
>> history of an object, and if you can explain exactly why each event
>> happens, then you understand Cocoa memory management rules pretty
>> well.
>>

>>>    I'm thinking that an NSAutoReleasePool is something like a

> parameterized

>>> vector that I temporarily stuff objects into. When I use the
>>> statement:
>>>
>>>            NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc]

> init];

>>>
>>>    I'm hinting to the compiler that the objects that I'm about to
>>> use

> are

>>> temporary. Somehow the obj-c runtime sets up a temp memory area for
>>> me

> and

>>> starts allocation memory out of there. And that if I use a
>>> autorelease

> pool

>>> I can tell the pool to retain some of these objects and clean up
>>> others.

>>
>> No.  Autorelease pools do not manage memory allocation; they don't
>> bound the scope of objects which they hold.  They simply hold lists to
>> which object pointers are added when the objects are sent
>> -autorelease, and which send -release to each object in the list when
>> they are deallocated.
>>

>>>    Grrr....I think I need to read more.....

>>
>> Yes, generally better to do that before posting half-formed thoughts
>> on a mailing list read by thousands of people. :)
>>
>> --
>> =Nicholas Riley <<email_removed>> |
>> <http://www.uiuc.edu/ph/www/njriley>
>>        Pablo Research Group, Department of Computer Science and
>>  Medical Scholars Program, University of Illinois at Urbana-Champaign
>> _______________________________________________
>> cocoa-dev mailing list | <email_removed>
>> Help/Unsubscribe/Archives:

> http://www.lists.apple.com/mailman/listinfo/cocoa-dev

>> Do not post admin requests to the list. They will be ignored.

> _______________________________________________
> cocoa-dev mailing list | <email_removed>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.

_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.