Re: showing window causes EXC_BAD_ACCESS
Re: showing window causes EXC_BAD_ACCESS
- Subject: Re: showing window causes EXC_BAD_ACCESS
- From: Negm-Awad Amin <email@hidden>
- Date: Mon, 29 Sep 2008 10:08:52 +0200
Am Sa,27.09.2008 um 22:44 schrieb Uli Kusterer:
On 27.09.2008, at 22:13, Michael Ash wrote:
But suddenly you're back to having to think about the global picture
of who owns objects, which is what Cocoa's memory management system
is
supposed to avoid.
Retains and releases should be balanced. This doesn't just means that
they should ultimately be equal in number, it also means that the
same
entity should be doing both. "Release when closed" breaks the
fundamental memory management rules and, as a consequence, makes it
much more complicated to think about how the program works.
You're misunderstanding the purpose of Cocoa's memory management
system: It's not about not having to care who owns what, it's about
not having to worry about shared ownership. There are many cases
(threading and creation of objects come to mind) where ownership is
handed from one object to the other.
In this case, you specify in the NIB that you want your window to
release itself, and you haven't written your outlet in a way that it
retains the window. If you expect your window to not go away when
closed, you're expecting too much.
Hallo Uli, :-)
I think, that you have to keep in mind, that sometimes you have
instances in a nib, which have no retain at all. Simply think of a
stand-alone delegate for an UI-element. It is not retained by the UI-
element (delegates are not retained to avoid retain cycles as you know).
So loading a nib unfortunatly is not balanced. When you think of
loading the nib-objects as instance creation, the mm-rules are broken:
Usually you balance the +alloc with a -retain (some lines later,
sometimes in -dealloc) or an immediate -autorelease. The nib-loader
does not do that. So $somebody has to release the instances, when the
nib is unloaded.
So loading objects through the nib-loader is like a naked +alloc, -
init*.
You can see eht "nib-exception" of mm-rules, when you handle the top-
level objects your own. You probably store them in an array, which
sends a retain to the objects. The first thing you have to do, is to
send a -release to all top-level objects to balance the nib-loaders
+alloc.
So, after all: You have to release top-level objects of the nib
manually, when unloading the nib.
I think, that "release, when closed" is simply a convenient option,
because in many cases you have only a window in the nib and it is the
only object, that has to be released. And usually closing a window
means "unloading the nib" to get the free memory. So in this cases you
have to do nothing in your code, if you checked that option.
That said, I fully agree on one partial point you raised: 'Release
when closed' is dangerous and complicates matters.
Yes. Anyway you should always use a window controller or view
controller to get rid of the problems with nibs and mm.
It should be off by default, and it's very likely that nobody would
miss it.
In this case, you will get a memory leak everytime you simply do not
care about the nib loading. You would always need extra release-code.
Think of a simple about-window. You have an action, let's call it -
showAboutWindow: and load the nib there. If the user closes this
window, it is released automatically. You have to do nothing. And you
do not have to take care about other instances in that nib, because
there are no other instances: 0 lines of code.
(In reality this is not true, because you have to take care, that the
nib is not reloaded. So you have to handle the window close for that
purpose and then can add a -release.)
That said, I don't know what it was originally introduced for. Any
old NeXTies here who know?
longW told me, that there had not been window controllers prior to
10.0 to handle the mm of nib-objects. :-)
view controllers are introduced with 10.5.
So the whole nib-loading mechanism looks a littlebit – eh –
archaeological.
Cheers,
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
Amin Negm-Awad
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden