• 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: Setting pointer to nil
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Setting pointer to nil


  • Subject: Re: Setting pointer to nil
  • From: Ricky Sharp <email@hidden>
  • Date: Tue, 20 Dec 2005 19:30:05 -0600


On Dec 20, 2005, at 6:50 PM, Shawn Erickson wrote:


On Dec 20, 2005, at 3:11 PM, John Stiles wrote:

On Dec 20, 2005, at 3:01 PM, Shaun Wexler wrote:

On Dec 20, 2005, at 2:50 PM, Ricky Sharp wrote:

- (void)setManagedObjectContext:(id)newManagedObjectContext
{
[newManagedObjectContext retain];
[managedObjectContext release];
managedObjectContext = newManagedObjectContext;
}

FWIW, it's usually better & safer to write setters like this:

- (void)setManagedObjectContext:(id)newManagedObjectContext
{
id oldManagedObjectContext = managedObjectContext;
managedObjectContext = [newManagedObjectContext retain];
[oldManagedObjectContext release];
}

Out of curiosity, why? I see that this fixes a race condition, in case you're writing multi-threaded code, but is there more to it than that?

Well either are not really "safe" in a multi-threaded scenario so I don't see a good reason to do it in a way other then what you are doing. I could be missing some nuance....

id oldManagedObjectContext = managedObjectContext;
managedObjectContext = [newManagedObjectContext retain];
[oldManagedObjectContext release];

For example if thread one gets preempted after "id oldManagedObjectContext = managedObjectContext;" and thread two gets past "managedObjectContext = [newManagedObjectContext retain];" before thread one comes around again then you have an over release situation as well as a leak from a now lost reference.

Personally I use an if form (at least before bindings came around since I would sometimes stick in the if block notification, defaults updates, etc.). Again this isn't thread safe.

- (void)setManagedObjectContext:(id)newManagedObjectContext
{
if (managedObjectContext != newManagedObjectContext) {
[managedObjectContext release];
managedObjectContext = [newManagedObjectContext retain];
}
}

All of these patterns are perfectly valid for particular situations. Since I don't do anything multithreaded currently, the original pattern I gave works a-ok for my needs.

Note that Accessorizer allows you specify many patterns as well as whether you want the 'if' check. It can also generate locking code for setters in one of three different ways.

I'm sure you've seen or heard of the excellent read on accessor patterns[1] by mmalc. It illustrates pros/cons of each pattern for various situations.

[1] <http://www.stepwise.com/Articles/Technical/2002-06-11.01.html>

___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden
References: 
 >Setting pointer to nil (From: Jeff LaMarche <email@hidden>)
 >Re: Setting pointer to nil (From: Ricky Sharp <email@hidden>)
 >Re: Setting pointer to nil (From: Shaun Wexler <email@hidden>)
 >Re: Setting pointer to nil (From: John Stiles <email@hidden>)
 >Re: Setting pointer to nil (From: Shawn Erickson <email@hidden>)

  • Prev by Date: Re: Setting pointer to nil
  • Next by Date: RE: XCode and subversion
  • Previous by thread: Re: Setting pointer to nil
  • Next by thread: Re: Setting pointer to nil
  • Index(es):
    • Date
    • Thread