I think you misunderstood my post, and I used 'release' instead of
'dealloc' which was just lazy of me.
I was responding to Jason's post where he was talking about active
memory management especially on devices where memory is limited. I may
have misunderstood his post entirely but I took it to be talking about
how to actually get memory freed (ie objects deallocated) as soon as
possible and do the most you can to ensure objects you no longer use
are really freed if of course nobody else is using them.
If you use the convenience constructors, they objects hang around
until whatever autorelease pool they happen to have been allocated in
is released, his post advocated one of two methods which were better,
either the direct alloc/init or making your own local autorelease pool
and draining it when you are done in your local routine. Neither of
them absolutely guarantees that an object you created is actually
destroyed when you're finished with it, implementation details can
cause any number of things to happen. However they are both better in
terms of 'active' memory management than convenience constructors and
I think if you want to attempt to actively manage memory as best you
can, the second is better, the local autorelease pool.
You'd think perhaps that alloc/init would give you an object which
really has never been retained by anyone else, but as I said I
remembered a post from a while ago about a complex object which was
alloc/init'ed but ended up still having a retain/autorelease on it, so
it hung around after the author of that post thought it would be gone.
You can never actually totally manage when an object is really,
actually deallocated. Implementation details mean that objects could
have retains on them (either real or from some outer autorelease pool
you have no control over) but if you want to be aggressive about it
and do all you can to maximize the chance objects are actually
deallocated when you personally are done with them it seems to me that
the worst of all worlds is the convenience constructor, in the middle
is alloc/init, and the best shot you can give yourself is to make your
own autorelease pool and retain/release all the objects you want
inside it.
On Sep 17, 2008, at 11:11 PM, Matthew Youney wrote:
Roland,
You really need to start here:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concept
s/ObjectOwnership.html#//apple_ref/doc/uid/20000043
For me, this was the most complicated part of Cocoa and most
different from
other languages. I recommend reading it, printing it, and keeping
it next
to you while coding until it is second nature. Trust me that it is
easier
learning the rules now rather than hunting Zombies (look it up), and
troubleshooting leaky code later on.
There are some fundamental rules that you must follow. Reading all
of this
stuff, it seems quite complicated, however once you learn to "play
by the
rules", it makes good sense.
Enjoy,
Matt
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf
Of Bill
Bumgarner
Sent: Tuesday, September 16, 2008 10:50 PM
To: Roland King
Cc: Cocoa Developers
Subject: Re: NSMutableString question
On Sep 16, 2008, at 7:41 PM, Roland King wrote:
Jason Coco wrote:
NSMutableString *str = [[NSMutableString alloc] Â
initWithCapacity:someAssumedCapacity];
/* do stuff */
[str release];
Is that actually guaranteed to release the string *right now*? I
only ask because I seem to recall a message a couple of months ago
about a more complicated object where it appeared that the
initializer did a retain/autorelease on the object so it ended up in
the autorelease pool before you even got hold of it. That was not an
object obtained from a convenience method either IIRC, it was a
[ [ SomeClass alloc ] initConstructorOfSomeSort ] call.
As far as the caller of -release is concerned, that is guaranteed to
release the string *right now*. I.e. the retain implied by +alloc
will be released.
That is all that it guarantees.
The pattern you describe would be an internal implementation detail.
An odd one, at that. But nothing you, the caller, can really do
anything about safely and without breaking encapsulation.
Unlikely the case with NSMutableString I'd think, but perhaps for
other things.
The local autorelease pool version I'd think is guaranteed to work.
No more so than -release. All -autorelease does is add the object to
the NSAutoreleasePool, which will send -release when it is -drain'ed.
If the instance does something goofy internally or, in the more common
case, if something else holds a -retain, the object will not be
deallocated upon -drain of the autorelease pool.
b.bum
_______________________________________________
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 [EMAIL PROTECTED]
