Re: dealloc for cleanup versus freeing memory
Re: dealloc for cleanup versus freeing memory
- Subject: Re: dealloc for cleanup versus freeing memory
- From: John Stiles <email@hidden>
- Date: Mon, 6 Aug 2007 11:56:35 -0700
On Aug 6, 2007, at 11:48 AM, Bill Bumgarner wrote:
On Aug 6, 2007, at 11:42 AM, John Stiles wrote:
Your points are well articulated, but I still see this as
defeating the point of retain counts.
If your object is designed to hold a reference to a "scarce
resource" like a file handle, and it's being retained by three
different points in the code, it seems like a bad idea to me for
one point in the code to decide "OK, we're done now, let's wrap it
up" and just close the file. What about the other two places in
the code that were using the object? If they still hold a retain
on the object, they have every reason to expect a working file
handle, right?
In general, "OK, we're done now, let's wrap it up" would be
packaged into some kind of a notification or managed by some kind
of a manager.
You are correct in that, in this very simple case, the retain/
release/autorelease mechanism more or less works.
The problem is that as soon as you get even slightly more complex,
you are screwed for the reasons I outlined in my message. Order
dependencies, late resource release due to autorelease pools and
threading issues will become a nightmare.
C++ has the concept of uncopyable objects—make the copy-construct/
assignment constructors private and unimplemented, and you'll get an
error at build time if you try to copy it. (Boost has a mechanism for
automatically declaring an object uncopyable as well.)
I wonder if ObjC needs the concept of unretainable objects—i.e., "we
are managing this object's lifetime via a notification system, not
retain counts, so don't even bother retaining this since it won't
work." Hmm... I suppose you could always implement -retain and have
it NSAssert or something.
_______________________________________________
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