• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Garbage collector vs variable lifetime
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Garbage collector vs variable lifetime


  • Subject: Re: Garbage collector vs variable lifetime
  • From: Quincey Morris <email@hidden>
  • Date: Sat, 7 Jun 2008 11:19:33 -0700


On Jun 7, 2008, at 04:34, Michael Ash wrote:

Actually I think that it is about the char * pointer, and this bug
should be considered an NSData bug rather than a compiler bug or a GC
bug. The fact that it's really a design bug in NSData rather than
something that can be easily fixed definitely makes it worse, but
doesn't really change the location of the fault.

After obsessing about this some more, I think I might have come to much the same conclusion. The issue of whether the lifetime of a variable *should* be identical to the scope of the variable seems irresolvable, since there's no specification in control of the compiler's behavior AFAIK.


Going back to:

	NSData*data = ...
	const unsigned char* bytes = [data bytes];
	for (...) {
		... = bytes [i];
	}

Since 'data' is not referenced in or beyond the loop, we don't care whether the NSData object gets garbage collected away or not after the 'bytes' assignment is made (so we don't care if the compiler shortens the variable lifetime), so long as the memory pointed to by 'bytes' doesn't disappear too.

The consequence of this should be either:

(a) [data bytes] must promise to return a collectable object (so that the 'bytes' reference keeps it alive), or

(b) [data bytes] must lock (pseudo-retain) something internally (possibly just 'data' itself) and be matched with an unlock (pseudo- release) method.

(Maybe there's a 3rd option, but I can't think of it. Your custom allocator suggestion is more or less equivalent to (b), I think.)

Case (a) would be nice for programmers, but I assume it isn't implemented that way now for reasons of performance. Case (b) is annoying to use, especially if you went to a GC-app to avoid worrying about retain/release, but at least it's safe if coded correctly.

Since [data bytes] is neither (a) nor (b) right now, I'd suggest that the defect is in the NSData API. Personally, I'd prefer (a), since I never assumed anything about the performance of NSData allocations anyway.


_______________________________________________

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


  • Follow-Ups:
    • Re: Garbage collector vs variable lifetime
      • From: "Michael Ash" <email@hidden>
References: 
 >Garbage collector vs variable lifetime (From: Quincey Morris <email@hidden>)
 >Re: Garbage collector vs variable lifetime (From: Bill Bumgarner <email@hidden>)
 >Re: Garbage collector vs variable lifetime (From: Ricky Sharp <email@hidden>)
 >Re: Garbage collector vs variable lifetime (From: Bill Bumgarner <email@hidden>)
 >Re: Garbage collector vs variable lifetime (From: Antonio Nunes <email@hidden>)
 >Re: Garbage collector vs variable lifetime (From: Ken Thomases <email@hidden>)
 >Re: Garbage collector vs variable lifetime (From: Bill Bumgarner <email@hidden>)
 >Re: Garbage collector vs variable lifetime (From: Ken Thomases <email@hidden>)
 >Re: Garbage collector vs variable lifetime (From: "Michael Ash" <email@hidden>)

  • Prev by Date: Re: 3rd Party Nonsense (was Re: Regular Expressions?)
  • Next by Date: Re: Learning Cocoa with RubyCocoa (was Regular Expressions)
  • Previous by thread: Re: Garbage collector vs variable lifetime
  • Next by thread: Re: Garbage collector vs variable lifetime
  • Index(es):
    • Date
    • Thread