On 13-Apr-08, at 1:06 PM, Greg Titus wrote:
The big difference is that in Objective-C, trying to send a message
to nil results in a no-op instead of an access violation, so your
defensive C++ practice is actually going to tend to mask those same
errors in Objective-C and make them harder
You want to just leave the pointer alone and turn on NSZombiesEnabled
when you run your app. Then instead of the object on the other end of
the pointer being freed, it'll point to a special zombie class which
will helpfully raise you an exception when you try to send it a
message. This has
On 13-Apr-08, at 2:15 PM, Greg Titus wrote:
You want to just leave the pointer alone and turn on
NSZombiesEnabled when you run your app.
Huh. I'd actually stumbled across NSDebug.h before, but the
documentation at the top
WARNING: Unsupported API.
This module contains material that is
On Apr 13, 2008, at 3:35 PM, Alex Curylo wrote:
OK, then, what would an equivalently useful value to set a released
Objective-C object pointer/ivar to in order to cause any subsequent
access of it to stop the program immediately? 0xDEADBEEF perhaps?
Well.. you could do what Greg said and go
On Sun, Apr 13, 2008 at 5:33 PM, Alex Curylo [EMAIL PROTECTED] wrote:
On 13-Apr-08, at 2:15 PM, Greg Titus wrote:
You want to just leave the pointer alone and turn on NSZombiesEnabled when
you run your app.
Huh. I'd actually stumbled across NSDebug.h before, but the documentation
at
