Hi Peter, On Sun, Jun 8, 2008 at 1:15 AM, Peter Duniho <[EMAIL PROTECTED]> wrote:
> Maybe it's just because I've been using GC systems more than you have, and > so I've gotten used to thinking about memory allocations in the paradigm > that GC systems impose. I'm starting to realise that this is my barrier. I'm just an Obj-C/Cocoa programmer who never had any objection to version 1 memory management and is a bit alarmed to discover that I can't control the scope of my objects' lifetimes as easily as I could with an autorelease pool. > That's because the root of this problem isn't the > optimizing compiler. It's the fact that garbage collection is being used > alongside other forms of memory management. It's only because there are > things that are allocated outside of the garbage collection system that this > even comes up. Indeed, although I've used several other GC languages before, I've never tried to mix GC with non-GC before. >> The compiler is already in that business -- hence the modifiers >> __strong and __weak. > > Not really. In fact, if anything those are proof that the compiler is _not_ > in the business of memory management. Instead, it provides a way for YOU to > give it information that is used to control memory management. If the > compiler were in the business of memory management, it would infer those > properties itself. I guess what I meant is: the compiler is in the business of telling the GC what it can and cannot collect. >>> and b) there will still be lots of other scenarios that >>> are similar, but not solvable by the compiler. >> >> Could you please elaborate on this? > > I'm surprised I need to. > > But, consider the NSData example we've been using. Suppose that the byte* > in question weren't just used locally, but rather passed to some other data > structure. Even if we "fixed" the compiler so that it didn't optimize away > the variable referencing the "data" object, when that variable goes out of > scope as the method returns, the byte* still would potentially be released, > as the "data" object is. Yes, but this is nothing to do with the discussion at hand. We are talking about the lifetime of the NSData object. This "inner pointer" class of problems existed with autorelease, too, but because the lifetime of autoreleased objects was deterministic, it was easier to handle. > No one said anything about _referencing_ "data". You have to _use_ it in a > way that the compiler _can't_ rearrange. Okay, I think I understand these usages now. Hamish _______________________________________________ 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 [EMAIL PROTECTED]
