Re: Protecting singleton objects from releasing
Re: Protecting singleton objects from releasing
- Subject: Re: Protecting singleton objects from releasing
- From: Dietrich Epp <email@hidden>
- Date: Mon, 17 Feb 2003 22:11:48 -0800
On Sunday, Feb 16, 2003, at 08:33 US/Pacific, publiclook wrote:
I'm curious. Do those of you who advocate protecting programmers from
over releasing objects also install signal handlers to catch
dereferences of NULL pointers ? How do you handle that ? What is the
correct application behavior when a NULL (or erroneous) pointer is
dereferenced ? Did you catch that I just slipped the (or erroneous)
in? Guess what you have if you over release objects.
When you dereference NULL, there's nothing you can really do about it.
When you go splat in free'd space though, there are environment
variables you use that can help you out. Double free can be caught, no
problem, with an environment variable. It's saved me a lot of
debugging time in the past because I'm not perfect, and the language
isn't smart enough to manage its own memory.
On Monday, Feb 17, 2003, at 15:49 US/Pacific, publiclook wrote:
[snipped convoluted example]
The whole point is that the code for setting and getting a FuBar
instance variable should not need to know if all arguments to the set
method are singletons. there might be lots of different classes that
conform to the <FuBarProtocol> protocol. The memory management rules
are the SAME whether I am dealing with singleton or not. This is a
good thing. This reduces coupling between separate design elements.
This code is completely harmless with respect to the singleton nature
of the object being stored.
If all kinds of special log statements are added to -release, I will
get log messages when releasing is perfectly fine and I won't get any
special messages when an object is erroneously released.
The point is that releasing too many times is a bug whether the object
being released is a singleton or not. Releaseing an object the
correct number of times is NOT an error regardless of whether the
object being released is a singleton or not.
What IS an error is deallocating a singleton. If error reporting is
needed, it is in the -dealloc method of the singleton. Even there, a
log statement is not the right thing. This is a serious error that
needs an NSAssert() because the application is probably going to crash
later.
Read the Apple docs, for <NSObject>'s -retainCount.
For objects that never get released (that is, their release method
does nothing), this method should return UINT_MAX, as defined in
<limits.h>.
Seems to me like a negligible amount of work that can prevent more more
work later. You 'real programmers' can spend as much time as you like
in gdb. Although my personal programming style is significantly more
paranoid than most =)
_______________________________________________
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.