> On Dec 2, 2015, at 5:18 PM, Doug Hill <xcodeus...@breaqz.com> wrote:
>
> "Certain other operations are described in this International Standard as
> undefined (for example, the effect of dereferencing the null pointer). [Note:
> this International Standard imposes no requirements on the behavior of
> programs that contain undefined behavior. ]”
Not relevant; I already explained in a previous reply that this does not
dereference a null pointer. You can call nonvirtual methods on NULL pointers
just fine without any runtime issues … just as long as you don’t access any
member variables, of course.
> The problem seems to be that you can make up C++ code that constructs a NULL
> pointer and then crash when you dereference it. My understanding is that the
> C++ spec unequivocally defines this as an error and therefor it shouldn’t be
> happening at all.
It’s not a weird situation at all. Something returns you an object pointer. You
call a method on that object. But the pointer you got happens to be NULL. Ergo,
you’ve just called a method on a NULL pointer.
Widget *w = factory.getCurrentWidget();
Paint *p = w->getPaint();
If the currentWidget is NULL, the second line does this. In some circumstances
it’s useful to be able to handle this — heck, we should be able to agree on
this, since we use this handy behavior of messaging nil in Obj-C all the time.
So Widget::getPaint() could check for this==nil and if so return NULL instead
of crashing.
It’s not a big deal; I’ve adjusted my code not to do this. I was just curious
where this tightening of the standard came from.
—Jens _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
