Re: Autorelease pool questions
Re: Autorelease pool questions
- Subject: Re: Autorelease pool questions
- From: "Rakesh Pandey" <email@hidden>
- Date: Mon, 20 Jan 2003 01:38:55 +0530
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@hidden>
To: "Brian Gilman" <email@hidden>
Cc: "Cocoa Dev" <email@hidden>
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@hidden> | <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@hidden
>
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@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.