Re: NSView subclass never gets dealloced?
Re: NSView subclass never gets dealloced?
- Subject: Re: NSView subclass never gets dealloced?
- From: "Erik M. Buck" <email@hidden>
- Date: Fri, 29 Mar 2002 10:37:25 -0600
----- Original Message -----
From: "Brock Brandenberg" <email@hidden>
>
> NSView subclass never gets dealloced?
>
>
I'm seeing the same thing on an NSView subclass and can't figure out
>
what's wrong. If the window is set to releaase on close, the dealloc
>
gets called, but this is not the right thing to do if using the default
>
window controller. You'll get a crash if selecting a menu right
>
afterwards. I think the docs are incorrect too, in that they mention the
>
default behavior for an NSWindow is to release on close, yet IB sets the
>
default to NOT release on close. Again, I'm assuming that it has
>
something to do with the default window controller.
1) NSWindowController releases top level objects in associates nibs. If you
are not using NSWindowController then you must release them yourself.
2) Normal reference counted memory management applies. If you retain a view
and do not correspondingly release it, YOU have created a memory leak and it
is not the frameworks fault.
3) The IB option to release on close exists to support the situation in
which NSWindowController is not used. Using that option in combination with
NSWindowController probably produces too many releases.
>
>
> Pragmatically, if it doesn't get called when the app terminates, then
>
> piscine or not, it won't really matter as the OS will clear up the
>
> memory for you. If this is happening for a number of windows, then it's
>
> more of a problem.
>
>
While it's not the proper place to do so, if you had any files open for
>
debugging or such and were relying on the destructor to clean up, it
>
would not. Memory would be reclaimed by the system, but file closing is
>
one of those undefined behaviors. They probably get closed, but who
>
knows what subsequent EOF errors might happen on reading them.
1) You are right. A view is almost certainly not anyplace that should be
dealing with files. Views may display the content of files. The file
handling is part of a model. It is usually best to keep models separate
from views.
2) The operating system assures that all open files are flushed and closed
when the process that opened them terminates. [This is unlike MS Windows
that leaves files locked when an application dies]. If an application
terminates normally, there is little chance of corrupted files. If an
application crashes in the midst of writing a file, the file will be closed
but will probably be corrupt.
3) To debug these issues, override -retain and -release in your view
subclass. Put break points in the overridden methods. Look to see when the
views is being inappropriately retained and not released.
>
>
Anyone have any better info than the Apple API references?
The Apple API reference is comprehensive on this issue.
>
>
And is this list moderated by anyone from Apple? The lack of sample code
>
for Cocoa is pathetic, as is the lack of examples of proper application
>
of the APIs? Whose working on these docs?
There are copious examples available. If you are not finding them then
something is wrong with the way you are looking. Keep in mind that generic
UNIX API use is not restricted to Apple examples. Look in the millions of
lines of code out there. We can always use more examples and more
documentation. Your specific problem is well understood and solved by many
examples.
>
>
Brock Brandenberg
>
Philosophical note: Many people crave the "automatic" behaviors of C++ such
as "automatic" destructor invocation. Objective-C has a different
philosophy and is deliberately kept simple in order to enable distributed
messaging etc. Not everyone has to love Objective-C or reference counted
memory management. If Objective-C does not fit with your mental model of
how a language should work, then just don't use it. We all have many
choices of language to use. If you like the dynamism of Cocoa and
Objective-C, remember that the cost (or benefit depending on POV) is the
lack of constructors, destructors, stack unwinding exceptions, operator
overloading, template meta programming, etc.
Finally, when reference counting is used with C++, the same issues arise.
Destructors are not called unless an object is deleted, and it won't be
deleted until its reference count reaches zero. If you mishandle reference
counting with C++, the same error results.
_______________________________________________
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.