Re: GC pros and cons
Re: GC pros and cons
- Subject: Re: GC pros and cons
- From: James Gregurich <email@hidden>
- Date: Fri, 26 Jun 2009 17:40:58 -0700
On Friday, June 26, 2009, at 04:41PM, "Kyle Sluder" <email@hidden> wrote:
>100% might. Maybe 0% today, and then tomorrow Apple might release an
>update that causes all objects to hang around forever. You don't
>know, and you shouldn't care.
I don't. in practice its not particularly relevant as I can't think of an instance where I made a class' lifecycle dependent on the lifetime of an NSFont (just to use your example).
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.
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.
If you like that, then more power to you.
> 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.
_______________________________________________
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