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 19:24:33 -0700
On Friday, June 26, 2009, at 06:39PM, "Kyle Sluder" <email@hidden> wrote:
>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().
ummm. my system doesn't fail if cocoa keeps an object around longer than I expect.
>shared_ptr<> isn't Cocoa, and you still need to participate in Cocoa
>memory management.
I can write cocoa code in C++ quite easily. I also participlate in cocoa memory manage by calling release in my deleter. It all works just fine.
It is indeed true that I am counting on Apple and any 3rd party libs to get their retains and releases right. That is something I can live with. If I spot a bug in their stuff, I'll just have to deal with it.
>
>>>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.
hehe. oh yes they do. You can put any TYPE you want in shared_ptr<>. If you want to put a posix file descriptor in it, just use close() as the custom deleter. works great. In fact, I guard SQLite db handles with shared_ptr.
Here is how you do it:
std::string tmpDbName("test.db");
sqlite3* tmpDbPtr = NULL;
boost::shared_ptr<sqlite3> tmpDbSPtr;
int tmpResult = sqlite3_open_v2(tmpDbName.c_str(), &tmpDbPtr, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE | SQLITE_OPEN_NOMUTEX, statVSNamePtr);
if(tmpResult != SQLITE_OK)
{
//handle error
return;
}
tmpDbSPtr.reset(tmpDbPtr, sqlite3_close);
this code is completely exception safe and won't leak the db handle under any circumstances.
>
>>>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.\\
look at the code snippet I just provided and tell me that this use of RAII is not useful for guarding ANY resource...cocoa or otherwise.
>
>>>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
I'll do that later tonight.
>If weak_ptr<> were able to solve all retain cycle problems, we would
>use in Objective-C (by simply not calling -retain).
heh. THAT will cause a crash if the object has already been released.
but I can call weak_ptr.lock() to get shared_ptr instance. If that shared_ptr instance is non-null, then the ptr still exists and I have a lock on it that prevents it from being released from under me...and weak_ptr/shared_ptr is safe to use across threads.
I'm telling you. this mechanism works great. I'm already using this in a pretty big commercial application that is multithreaded.
>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.
ok. I'll work with your scenario....
window controller keeps a weak_ptr<> to window.
windows keeps a shared_ptr<> to window controller.
text field keeps a weak_ptr<> to window.
window keeps a shared_ptr<> to text field.
text field keeps a weak_ptr<> to window controller.
release the window and everything cascades from there. You could also put window controller in charge rather than window.
keep in mind...this is in theory. I as a 3rd party developer don't have access to the internals of the binding mechanism in cocoa to rewrite it to use weak_ptr. BUT it could be done without cycles and completely safely with shared_ptr & weak_ptr in theory. That said, the pieces that are under my control, I'd write the references that way and hope Apple has its act together. If I can observe or deduce that Apple has created a strong reference between two components I don't control, then I would use weak_ptr to go the opposite direction. Based on the work I've done, I'm confident in claiming that I could avoid "monster" bugs in a large evolving codebase by consistent use of shared_ptr & weak_ptr with cocoa.
_______________________________________________
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