On 12 Jun 2008, at 15:02, Hamish Allan wrote:
On Thu, Jun 12, 2008 at 6:50 AM, Ashley Perrien
<[EMAIL PROTECTED]> wrote:
NSNumber *myNum;
// Lots of code where I've forgotten to actually do anything with
myNum
results = [myClass someCalculationUsing: myNum];
I'd recommend not declarin
On 12 Jun 2008, at 13:01, Graham Cox wrote:
On 12 Jun 2008, at 5:47 pm, Chris Suter wrote:
Can you give me a counter-example?
Let’s say the function your calling uses one of the following:
-[NSDictionary setObject:forKey:]
-[NSMutableArray addObject:]
Raising an exception is a good respon
On 12/06/2008, at 10:01 PM, Graham Cox wrote:
But maybe the original point is getting lost? You asserted (pardon
the pun) that passing a nil argument was never acceptable
My exact words were: “it’s often not safe to pass nil objects as
arguments” and I stand by that. I raised the point bec
You can use either... I tend to use #include when I'm calling C
libraries and #import when I'm including things that are Objective-C.
It's just my habit but it's really just
a style issue.
On Jun 12, 2008, at 21:37 , William Squires wrote:
I thought ObjC used "#import", not "#include", so th
You can use #import in straight C applications from within Xcode, if
you like. There's also nothing stopping you from using the #include
directive in Objective-C. It's just more work than #import, which
handles include cycles for you.
--
m-s
On 12 Jun, 2008, at 21:37, William Squires wro
I thought ObjC used "#import", not "#include", so that multiple
copies of a header wouldn't appear, but maybe that's just for Cocoa
stuff, and not for "ordinary" C?
On Jun 12, 2008, at 1:05 AM, Jason Coco wrote:
#include
/* ... */
NSNumber *myNum = nil;
// Lots of code where you've forg
On Jun 12, 2008, at 2:29 AM, Graham Cox wrote:
On 12 Jun 2008, at 5:03 pm, Chris Suter wrote:
In the original example, myNum was being passed as a argument
rather than having a message to sent to it and it’s often not safe
to pass nil objects as arguments.
Hmmm... well, what's the functio
On 11 Jun '08, at 10:50 PM, Ashley Perrien wrote:
NSNumber *myNum;
// Lots of code where I've forgotten to actually do anything with
myNum
results = [myClass someCalculationUsing: myNum];
Turn on the "Uninitialized Automatic Variables" warning in your
project's build settings. (Actuall
On Thu, Jun 12, 2008 at 6:50 AM, Ashley Perrien <[EMAIL PROTECTED]> wrote:
> Noob question: I'm putting together a small code library and I'm trying to
> include some error checking in the methods; what I want to protect against
> is the following:
>
> NSNumber *myNum;
>
> // Lots of code where I'
On 2008 Jun, 12, at 0:47, Chris Suter wrote:
On 12/06/2008, at 5:29 PM, Graham Cox wrote:
... implicitly allowing nil, unless it is specifically documented
otherwise.
Can you give me a counter-example?
-[NSDictionary setObject:forKey:]
-[NSMutableArray addObject:]
[These] raise exceptio
On 12 Jun 2008, at 5:47 pm, Chris Suter wrote:
Can you give me a counter-example?
Let’s say the function your calling uses one of the following:
-[NSDictionary setObject:forKey:]
-[NSMutableArray addObject:]
Raising an exception is a good response when a nil argument isn't
appropriate,
On 12/06/2008, at 5:29 PM, Graham Cox wrote:
On 12 Jun 2008, at 5:03 pm, Chris Suter wrote:
In the original example, myNum was being passed as a argument
rather than having a message to sent to it and it’s often not safe
to pass nil objects as arguments.
Hmmm... well, what's the function
I agree with Graham, although I misread the initial question as
well... if the person is passing a garbage pointer, there's really not
much you can do. All you can really do is assert that the object you
expected is not nil.
Why is it unsafe to pass nil? Many API in Cocoa tell you to pass n
On 12 Jun 2008, at 5:03 pm, Chris Suter wrote:
In the original example, myNum was being passed as a argument rather
than having a message to sent to it and it’s often not safe to pass
nil objects as arguments.
Hmmm... well, what's the function it's passed to going to do with it,
other t
On 12/06/2008, at 4:51 PM, Graham Cox wrote:
NSNumber* myNum = nil;
/* stuff */
NSAssert( myNum != nil, @"some error message");
[myClass calc:myNum];
Messages to nil are safe - it will treat your number as having a
value of 0. Thus as long as you initialise it to nil, your code will
Just a note, the NSAssert() Foundation function should only be called
from inside an Objective-C method... if your code is somewhere in an
Object-C class, this is fine, but if you're calling from inside a C-
callback function or another C helper function (since you're creating
a Library, thi
NSNumber* myNum = nil;
/* stuff */
NSAssert( myNum != nil, @"some error message");
[myClass calc:myNum];
Messages to nil are safe - it will treat your number as having a value
of 0. Thus as long as you initialise it to nil, your code will run
without crashing though of course may give i
Yeah, variables you declare in a method (not as instance variables)
are not automatically initialized to 0/NULL/nil for you.
If you try to use an uninitialized variable, it might point to some
left over object in memory, or it might map to nothing at all. It is
totally random.
What is th
#include
/* ... */
NSNumber *myNum = nil;
// Lots of code where you've forgotten to actually do anything with
myNum
assert( myNum != nil );
results = [myClass someCalculationUsing: myNum];
// lots more code
to remove the assertion in the release build, compile with -DNDEBUG
HTH, /jason
Noob question: I'm putting together a small code library and I'm
trying to include some error checking in the methods; what I want to
protect against is the following:
NSNumber *myNum;
// Lots of code where I've forgotten to actually do anything with myNum
results = [myClass someCalculation
20 matches
Mail list logo
