Re: GC pros and cons
Re: GC pros and cons
- Subject: Re: GC pros and cons
- From: Kyle Sluder <email@hidden>
- Date: Fri, 26 Jun 2009 17:54:41 -0700
On Fri, Jun 26, 2009 at 5:40 PM, James Gregurich<email@hidden> wrote:
> I really don't get this whole line of reasoning. I don't get why the fact that a system keeps an NSFont around justifies me adding a whole new system to scan memory and look for pointers to determine which ones need to be released.
That wasn't where I was going with that. I was making two distinct
points: 1) You can't depend on any Cocoa object actually getting
released at any time. 2) Garbage collection is a useful facility that
doesn't solve all problems but makes the most common ones much easier
to solve, since you don't have to worry about manual memory
management.
> If the system decides to keep an NSFont around, that is its business. but if I need a hierarchy of my own classes to go away in a well-defined order at a precise time, then I want that control. I don't want a background process deciding at some arbitrary time where the objects are released.
You don't have that control with -retain/-release as it is. The
system might at any point arbitrarily decide to hang on to objects
that you intend to manage yourself. It seems like you're trying to
apply an RAII-like pattern to dealing with Cocoa; Cocoa just doesn't
work this way. The occasions where you need objects to "go away in a
well-defined order at a precise time" should not be handled by memory
management. You should have a separate resource management paradigm
for these sorts of objects, like NSFileHandle (to pick one example)
does.
Cocoa very intentionally does not conflate the concepts of object
lifetime and resource acquisition.
>> The creators of garbage collectors don't consider them to be
>>panaceas. There are a very well known class of problems which GC
>>utterly fails in. There's also a rather large class of problems which
>>can only be solved (that is, solved by a programmer within a normal
>>human lifespan) with some form of automatic garbage collection. The
>>Lisp guys can probably come up with boatloads; after all, they've had
>>since the late 50's.
>
>
> really?
>
> I'd find it interesting to see a list of problems that require a garbage collector to manage the memory. Perhaps you could provide that.
Closures are notoriously hard to implement without some form of
automatic memory management. Forgetting everything announced and
unannounced about upcoming features of ObjC, we have a small version
of this issue right now, when dealing with NSBeginAlertSheet context
pointers.
Also, NSWindowController and NSViewController require special voodoo
to break retain cycles in NIBs. This logic is unnecessary in a
garbage-collected environment.
None of these are insurmountable, to be sure, but they are a lot
easier with garbage collection.
--Kyle Sluder
_______________________________________________
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