In c/c++/objectiveC, any uninitialized variables are just that - they contain 'random' data depending on what was in memory at the time.
Uninitialized pointers are extremely dangerous and a very common cause of 'segfault' type bugs.
Uninitialized pointers are extremely dangerous and a very common cause of 'segfault' type bugs.
Eeeeekkkk! Didn't know that - am currently wrestling around with the beast that is cocoa.macos.m so this will be really useful to know.
Ooh, one other thing - I found out that because of the ultra-slick messaging syntax in Objective-C, it isn't compulsary to cast objects down to a lower descendent to call a method/selector that isn't in the parent class - it automagically finds and calls it. ;-)
But for some strange reason, there are a lot of places in cocoa.macos.m that handle each gadget separately and cast the gadget into the corresponding type before calling the exact same selector/method. This results in heaps of switch blocks which can often be replaced by casting as the common parent class, and using that to call the same method/selector anyway. Providing I know 100% that all the objects can respond to that selector (even if I didn't, I could check with the respondsToSelector call), is there any disadvantage to doing it this way? It seems to make for cleaner code and after a few days of testing, I haven't noticed any changes in any of my MaxGUI test program suite. ;-)