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 18:21:15 -0700
much better response. thanks.
The sarcastic stuff gets old.
On Friday, June 26, 2009, at 05:54PM, "Kyle Sluder" <email@hidden> wrote:
>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.
I certainly can the vast majority of the 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.
ok....but I haven't faced such a problem and don't forsee one.
>
>> 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.
I'm doing exactly that using shared_ptr<>. Maybe there are some cases where cocoa keeps things around beyond my control. but I can get the behavior I want a whole lot of the time by using shared_ptr<>.
>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.
such as shared_ptr and weak_ptr?
>Cocoa very intentionally does not conflate the concepts of object
>lifetime and resource acquisition.
That is an incredibly useful feature of C++.
>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.
I just jumped on wikipedia to educate myself on "Closures," but don't see anything there I couldn't do with shared_ptr and weak_ptr. feel free to point out a specific thing I couldn't easily accomplish on that page with shared_ptr and weak_ptr.
The parent function declares a shared_ptr on the stack and passes copy of it to the lambda function. The parent function can return a copy of the shared_ptr as well to allow client code to keep the object alive beyond the termination of the parent function and the lambda function.
reference: http://en.wikipedia.org/wiki/Closure_(computer_science)
>
>Also, NSWindowController and NSViewController require special voodoo
>to break retain cycles in NIBs. This logic is unnecessary in a
>garbage-collected environment.
that is what weak_ptr<> is for.
_______________________________________________
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