"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 |