Re: More memory allocation questions
Re: More memory allocation questions
- Subject: Re: More memory allocation questions
- From: Ondra Cada <email@hidden>
- Date: Sun, 28 Jul 2002 23:22:16 +0200
On Sunday, July 28, 2002, at 10:02 , Terry Simons wrote:
Firstly, I definitely am making things harder than they need to be. :)
Don't sweat it. With people who are Cocoa newbies, especially those who
are experienced with C++, it's entirely normal ;)
Read stepwise articles. (done)
Read the NSCopying Protocol documentation.
Check out the Foundation Tool template code.
Are there any other Apple documents,
Well, of course -- the very memory management description (I don't
remember where exactly it is, but just search docs), NSObject,
NSAutoreleasePool.
or websites that I should look at in regards to memory management with
Cocoa?
Archives at mamasam, cocoadevcentral, probably many others I don't recall
just now. Nevertheless, as soon as you grok the principles, you find the
memory management surprisingly simple. Therefore, I guess you should not
need to study more.
What exactly is the Apple runtime?
For now, something you don't need to know anything about. (Shortly and
somewhat imprecisely, the code which ensures sending messages.)
Later, you can study the headers in /usr/include/objc -- frankly I don't
know whether the stuff is documented elswhere or not, since for whatever I
needed so far those headers proved sufficient. But *do* please save this
stuff for later -- it is not difficult, but only for someone who is pretty
at home with ObjC behaviour.
Most (all?) of the time an NSAutoreleasePool object is set up for you
every time your program handles an event.
Right, in applications. In tools (=CLI programs without AppKit), you have
to set it yourself (since you interpret "events" -- whatever they look
like in a particular tool -- yourself too).
Autoreleasing an object ( [someObject autorelease] ) does nothing other
than add that object to the NSAutoreleasePool object.
At the end of the event loop, any objects in the NSAutoreleasePool
**object get a "release" message, which decrements their count, and if
the count is equal to 0, they are dealloc'd**.
A "retain" to an object will increment the count of an object, so that if
they are in the autorelease pool when you get access to them, you can
make sure they stay around until you're done with them. (Unless someone
mistakenly sends more release/autorelease messages than they should to
that object).
If you retain an object, then you should release/autorelease it.
...
If you don't autorelease/release objects that you create with alloc/init
then you'll leak memory.
So far, precisely.
It seems that you should always use autorelease, unless you are 100%
certain that nobody else is using a specified object, then release may be
preferable because it will free up resources immediately.
Well... technically speaking with the only information you got in this
list, yeah. Though, the "...keeps until end of this event" mantra is not
quite right anyway; the right one says "keeps until the current pool is
deallocated", and *that* might happen at the same time where you release.
Just to be safely on the clean side: the sprockets example must use
autorelease since *you* (not other code) use the object:
-(void)switchTo:foo {
[bar autorelease]; // if foo==bar ...
bar=[foo retain]; // you use the object here!
}
If you don't alloc/init an object, you shouldn't release it.
Add -copy and -mutableCopy -- they make objects with retain count 1 not
autoreleased, just like alloc/init. Also add the (somewhat obsoleted, but
still used here and there) +new (which is by definition just a shorthand
for alloc/init anyway).
How's that?
Great.
---
Ondra Hada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
_______________________________________________
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.