Re: GC pros and cons
Re: GC pros and cons
- Subject: Re: GC pros and cons
- From: James Gregurich <email@hidden>
- Date: Thu, 25 Jun 2009 22:37:08 -0700
consistently using the technique pushes the null check to one or two
places....such as when the pointer is alloc'ed.
regardless of whether messaging nil is a problem or not, if nil isn't
a a valid state for a variable, I check it and throw an exception as a
matter of defensive programming. in particular, if a data member is a
pointer that is available via accessor, I put the null check in the
accessor with the accessor returning a reference (rather than a
pointer) to the type. Client code calling the accessor need not worry
about the value being in an invalid state. If the value is in an
invalid state, an exception is thrown and everything cleanly unwinds
and the system can react and cleanly recover.
On Jun 25, 2009, at 10:13 PM, Stephen J. Butler wrote:
On Fri, Jun 26, 2009 at 12:06 AM, James Gregurich<email@hidden
> wrote:
I also take advantage of references in C++ to pass objc objects
around
without having to do null checks all over the place to keep code
resilent.
-(void) passMyObject: (NSObject&) theObj
{
NSLog(@"%@", &theObj);
}
since the function takes a reference, client code knows never to
pass a null
to the function.
Huh? When you call the function, don't you have to eventually do
[something passMyObject:*anObject]? To me, that doesn't eliminate the
nil check, just move it somewhere else.
Also, messaging nil objects isn't a problem. It's only an issue with
the collections.
_______________________________________________
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
_______________________________________________
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