much better response. thanks. The sarcastic stuff gets old.
On Friday, June 26, 2009, at 05:54PM, "Kyle Sluder" <kyle.slu...@gmail.com> 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
