1

Can I call a non-static, non-virtual method of a class from a null pointer? The member function would then test if this==nullptr, and return immediately if it's true.

I know it will work in most cases, but is this a guaranteed result? That way, I can ensure null pointer exceptions never happen, and avoid testing for null pointers in many places of the caller code. That's for compactness, I'm not going to do that right now, but I'm curious to know if any standard will guarantee this to work...

Thanks!

galinette
  • 8,896
  • 2
  • 36
  • 87
  • no, it's guaranteed undefined behavior. – Luchian Grigore Jun 21 '13 at 14:55
  • 2
    Why do we vote someone down who provides a well articulated question? Asker wants to know about undefined behavior and is asking about it, it is even phrased distinctly from the propose possible duplicate. – Sqeaky Jun 21 '13 at 15:15
  • Article: Still Comparing "this" Pointer to Null? - http://www.viva64.com/en/b/0226/ –  Dec 12 '13 at 17:05
  • @Sqeaky - Plus, its 2014 and the standards have been revised. So the previous answers may not even apply. Its classic [Could we please be a bit nicer to new users?](https://meta.stackexchange.com/questions/9953/could-we-please-be-a-bit-nicer-to-new-users) with a bit of "I know more than you" sprinkled on top. – jww Sep 09 '14 at 11:00

4 Answers4

4

Dereferencing a nullptr is Undefined behavior. Period!
Whether it works or not on one particular implementation is irrelevant, the behavior is not guaranteed.

Alok Save
  • 202,538
  • 53
  • 430
  • 533
  • 2
    I like the authority :) – rectummelancolique Jun 21 '13 at 14:59
  • Although I agree with your answer, and the question was about "guaranteed" behavior: in real life it works some time, and if you have to deal with some code which relies on such things (or more complicated cases of UB), there are a lot of details after the "Period!"... – anxieux Jun 21 '13 at 15:51
  • That's stating. Please cite your references! Otherwise trusting the answer is not guaranteed. – galinette Jun 21 '13 at 16:51
  • @galinette: That is the most common and basically known Undefined behavior use case. If you don't know this basic fact, then you are in dire need of a good book. And No I am not going to summon the holy standard for such a trivial case. – Alok Save Jun 21 '13 at 17:48
  • @anxieux: Once UB occurs the behaviors are undefined from the perspective of the standard so there is no point trying to find meaningful conclusion to it especially when there is no mention of specific compiler implementation. – Alok Save Jun 21 '13 at 17:50
0

The standard expliticly mentions dereferencing NULL pointer as undefined behavior. Using opearator -> dereferences the pointer to left.

So you're okay only in case if your implementation defined some behavior for the case, as it is a possibility (though I never encountered it in real life yet).

(I hope you understand that observing something is not the same as being defined.)

Balog Pal
  • 16,195
  • 2
  • 23
  • 37
0

always avoid calling a null pointer, you would usually end up with a core dump

aah134
  • 860
  • 12
  • 25
  • I will definitely avoid it... In fact, knowing the mechanisms of member functions ('this' is just passed as a hidden first argument to an otherwise static function), I was just wondering how the behavior is defined in the standard. – galinette Jun 21 '13 at 16:53
0

There are interesting answers here: When does invoking a member function on a null instance result in undefined behavior?

Also, the standard gives no hint about the mechanism for calling member virtual functions. It is usually done by just passing 'this' as a hidden function argument, which will in practice not dereference the pointer and work. However, it seems possible to implement even non-virtual function with a vtable, which in this case would crash.

Interestingly, a Microsoft function relies on this behavior :) http://msdn.microsoft.com/en-us/library/d64ehwhz%28v=vs.80%29.aspx

Community
  • 1
  • 1
galinette
  • 8,896
  • 2
  • 36
  • 87