[absmiths]

Does anyone know why this method would cause a SIGSEGV? This line of code:

[gender addItemWithTitle: "@Select One"];

Every single time causes this error. I checked for a null control, and it is definitely not null. Do I need to do some initialization first? This seems rather inexplicable.

[Uncle Skeleton]

you have your @ and " transposed

also I believe it's safe (but bad style) to send messages to nil. They just get ignored

[Catfish_Man]

Originally posted by Uncle Skeleton:
you have your @ and " transposed

also I believe it's safe (but bad style) to send messages to nil. They just get ignored

Apple added a compiler flag in 10.3 to make stuff faster if you don't do that, so it's probably a good idea not to (f-no-nil-receivers).

[absmiths]

Originally posted by Uncle Skeleton:
you have your @ and " transposed

also I believe it's safe (but bad style) to send messages to nil. They just get ignored

Hey thanks for pointing that out! Now I just have to figure out why I get periodic SIGBUSs.

[absmiths]

Originally posted by absmiths:
Hey thanks for pointing that out! Now I just have to figure out why I get periodic SIGBUSs.

Looks like I got that one solved. My Java objects were being garbage collected while ObjC retained pointers.

[Uncle Skeleton]

Originally posted by Catfish_Man:
Apple added a compiler flag in 10.3 to make stuff faster if you don't do that, so it's probably a good idea not to (f-no-nil-receivers).

Thanks for the tip. Forgive my total lack of knowledge about compilers, but can you explain a little more? Is this flag set automagically if I make sure never to call an object that might be nil? and if so, how would the compiler know this? Would I also have to add specific checks for nil before every method call?

[absmiths]

Originally posted by Uncle Skeleton:
Thanks for the tip. Forgive my total lack of knowledge about compilers, but can you explain a little more? Is this flag set automagically if I make sure never to call an object that might be nil? and if so, how would the compiler know this? Would I also have to add specific checks for nil before every method call?

Compiler flags don't traditionally set themselves (except of course for flags which negate or represent things which are on by default). The reason for the flag is that the compiler writer either (1) couldn't determine absolutely whether this option could be enabled, or (2) could not guarantee backwards compatibility with the flag on, or (3) that this change in some way violates a language convention that purists would complain about and thus must be explicitly enabled. My guess is that ObjC is such a dynamic language that there is no way for the compiler to know without a doubt that an object reference will not be nil. Imagine a compiler trying to determine at compile-time whether all array indexes are valid or not - this is probably very similar - and also happens to be the reason the Java VM always enforces bounds checking whether you need it or not.

Anyway, what this flag really means is that you can continue to send messages to nil, but that you will get catastrophic results instead of the usual benign ones.

[Uncle Skeleton]

how much of a speed difference is it? seems to me the whole point of cocoa is rapid deveopment, not runtime efficiency, and it's worth the slowdown if I need less time to debug. But it's still nice to know what the tradeoffs are before making that decision. (also how would I set that compiler flag?)

[Catfish_Man]

Originally posted by Uncle Skeleton:
how much of a speed difference is it? seems to me the whole point of cocoa is rapid deveopment, not runtime efficiency, and it's worth the slowdown if I need less time to debug. But it's still nice to know what the tradeoffs are before making that decision. (also how would I set that compiler flag?)

Most compiler flags have a checkbox in the build settings in XCode. Since nil receivers are probably a bad idea anyway I can't see this being a bad thing to turn on. It does mean being a bit more careful though, and I doubt the speedup is large.