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 18:39:52 -0700
On Fri, Jun 26, 2009 at 6:21 PM, James Gregurich<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.
You can also rely on malloc() returning non-NULL a vast majority of
the time. It's still sloppy not to check for NULL, even if it's just
to call abort().
>> 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.
I'll unfortunately have to leave this one alone for the time being...
perhaps we'll revisit this debate in a few months.
> 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<>.
shared_ptr<> isn't Cocoa, and you still need to participate in Cocoa
memory management.
>>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?
These are memory management primitives. They deal specifically and
only with the memory consumed by objects. Their semantics do not
extend to things like file handles, sockets, or other entities --
system resources or otherwise -- whose lifetimes you are interested
in.
>>Cocoa very intentionally does not conflate the concepts of object
>>lifetime and resource acquisition.
>
> That is an incredibly useful feature of C++.
Welcome to Cocoa, where Resource Acquisition Is Not Initialization.
Sorry, but there really is no debate on this point.
>>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 next article you need to read is about the Funarg Problem:
http://en.wikipedia.org/wiki/Funarg_problem
>>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.
If weak_ptr<> were able to solve all retain cycle problems, we would
use in Objective-C (by simply not calling -retain).
Imagine a NIB that contains a window. On this window lives a text
field. The File's Owner of the NIB is an instance of a custom
NSWindowController subclass (MyWindowController). MyWindowController
has a property that the text field binds to. The window controller
needs to retain the window, and the window retains the text field (by
the transitivity of retaining through the view hierarchy), but then
the text field turns around and retains the window controller again by
the act of binding to it. In all of these situations, the objects are
acting appropriately; none of these relationships can be modeled as a
weak reference. But we still have a retain cycle that we need to deal
with.
--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