Is it legal C++ to test the this-pointer in a member function?

Question

I have an application involving objects of different class types. The objects are referenced by pointers. A null pointer signifies that the associated object does not exist. Currently the calling codes is cumbersome, because each time it uses a pointer to an object, it tests the pointer value for null, and take some appropriate action it is null. Because the default action to be taken in the case of non-existence depends on the type of object, I would prefer to encode it in the classes for the objects themselves rather than in the calling program. This results in constructions like the following:

class C
{ ... 
  void member_func() //non-virtual !
  { if (this) { do something with the object ... }
    else { take some default action }
  }
  ...
};

Clearly the member function cannot be virtual, because the lookup table does not exist when the object does not exist, and the virtual call would fail. But is this code legal C++ for non-virtual member functions? It seems to work correctly for the compilers I have tried it on, but I am worried about possible non-portability. In the standard I can’t find a clause that either expressly allows or expressly prohibits such constructions.

@StoryTeller: It is undefined behavior to call a member function on a null pointer, so the answer is that it is not well defined. — David Rodríguez - dribeas, Jan 08 '13 at 17:02
Utterly related: http://stackoverflow.com/questions/2474018/when-does-invoking-a-member-function-on-a-null-instance-result-in-undefined-beha — GManNickG, Jan 08 '13 at 18:10

Ivaylo Strandjev · Answer 1 · 2013-01-08T15:11:47.263

12

this will never be null in a member function so the check you perform is useless.

As pointed by Matthieu M. in a comment, if you do something like this in your code:

C* c = 0; 
c->member();

This would cause undefined behavior and that is something bad.

edited Jan 08 '13 at 15:11

answered Jan 08 '13 at 14:59

Ivaylo Strandjev

69,226
18
123
176

3

Or rather, if you do `X* x = 0; x->member();` then you invoke **Undefined Behavior** and all bets are off. – Matthieu M. Jan 08 '13 at 15:00
@MatthieuM. exactly. Thanks for the clarification! Mind if I add this to my answer? – Ivaylo Strandjev Jan 08 '13 at 15:02
I'm pretty sure that undefined behaviour includes such observed outcomes as `this == NULL` ... so it _can_ happen. We're all agreed that you shouldn't do it, but your first sentence is just wrong. – Useless Jan 08 '13 at 15:48
4

@Useless: the point is that *in a program whose behavior is undefined* it doesn't really make sense to conclude that just because `this == NULL` evaluates to true, that `this` "is" null. On that line of deduction you could probably write some code that (on some implementation) makes a value appear to "be" two different things. Nothing is true, everything is permitted, as a dude in a funny cloak once told me. *In a program without UB*, `this` is not null, and it should go without saying that sweeping statements about program behavior apply only to programs whose behavior is defined. – Steve Jessop Jan 08 '13 at 15:50

score 6 · Answer 2 · answered Jan 08 '13 at 15:19

6

As has been pointed out, this can never be a null pointer. If it is, you've already invoked undefined behavior. You could, instead, create a set of overloaded functions, like this:

void DoTheThing(C* cp)
{
    if (cp)
        cp->member_func();
    else
    {
        // take some default action
    }
}

void DoTheThing(B* bp)
{
    if (bp)
        bp->some_other_member_func();
    else
    {
        // take some default action
    }
}

If the function you want to call has the same name in each class, then you could make a static function in each class which performs the default action for that class (all with the same name), and make a template:

template<typname T>
void DoTheThing(T* tp)
{
    if (tp)
        tp->member_func();
    else
        T::default_action()
}

answered Jan 08 '13 at 15:19

Benjamin Lindley

101,917
9
204
274

why can `this` never be null ? I thought in C++, `this` is the implicit first argument of each member function. It is legitimiate to call functions with null pointers as arguments. `this` is only dereferenced when accessing data members: at that point, behavior would become undefined if `this` is null. Merely calling a non-virtual member function should not involve dereferencing of `this`, oder ? – user1958486 Jan 08 '13 at 15:29
@user1958486: As reasonable as your argument sounds, it is just the case that it is undefined behavior. Perhaps it shouldn't be, but it is. Give me a minute and I will get the standard reference. – Benjamin Lindley Jan 08 '13 at 15:35
3

@user1958486: [5.2.5/2] *The expression E1->E2 is converted to the equivalent form (*(E1)).E2* -- So, it does involve a dereference of a null pointer. – Benjamin Lindley Jan 08 '13 at 15:40
4

It's undefined behavior because the standard doesn't dictate the function call mechanism. For example, it's pretty reasonable to assume that it's impossible to make a virtual call via a null pointer. For non-virtual calls I don't think there's any practical reason it *needs* to be UB as opposed to making the call with `this` a null pointer. But like Benjamin says it just is UB, the standard says you can't dereference a null pointer. "`this` is a hidden first parameter" is an analogy to explain how the called code knows what object it was called on, it's not the definition of `this`. – Steve Jessop Jan 08 '13 at 15:43

score 1 · Answer 3 · answered Jan 08 '13 at 15:01

1

Standard-wise, the code is not legal, but it's used in practice (bad practice that is).

In fact, IIRC MFC uses these checks internally.

answered Jan 08 '13 at 15:01

Luchian Grigore

253,575
64
457
625

Can you point to the relevant part of the standard? I was under the impression it's merely undefined. – StoryTeller - Unslander Monica Jan 08 '13 at 15:02
@StoryTeller illegal, yes, – Luchian Grigore Jan 08 '13 at 15:10
MFC can use non-standard code because it comes with the compiler. (If you work at Microsoft and buy the guy in the next room a beer, it is suddenly implementation defined). – Bo Persson Jan 08 '13 at 16:43

Useless · Answer 4 · 2013-01-08T15:24:45.310

Checking whether this == NULL is not a problem. Calling a method through a NULL object pointer is.

If you want to keep the checks somewhere, you could put it in a smart pointer class which can take the appropriate action if the held pointer is NULL. If the "appropriate action" is uniquely determined by the held type, you can use a traits class to specify it.

This way your NULL checks and their logic is kept together, and not mixed into either the caller or the method code.

// specialize this to provide behaviour per held type
template <typename T> struct MaybeNullDefaultAction {
    void null_call() { throw std::runtime_error("call through NULL pointer"); }
}

template <typename T> class MaybeNull: MaybeNullDefaultAction<T> {
    T *ptr;
public:
    explicit MaybeNull(T *p) : ptr(p) {}

    T* operator-> () {
        if (!ptr)
            null_call();
        // null_call should throw to avoid returning NULL here
        return ptr;
    }
};

Unfortunately, I can't see a way to do this without throwing. There's no way to intercept function calls for all methods names, otherwise I'd just return *this from operator-> and do the work in operator().

Unfortunately the appropriate action to take for a null object usuallly depends not only on the type of object, but on the particluar member function that is called. A solution is maybe not to let any of the pointers remain null, but to create a local "empty" instance of the given class whenever the required object does not exist. In some applications, non-existence of the object is not an error, but a common occurrence, in which case solutions involving a `throw` are not always appropriate. — user1958486, Jan 08 '13 at 16:21
@user1958486: It sounds like you need to rethink your approach. Why do you have so many useless null instances hanging around? Maybe wrap those up further. — GManNickG, Jan 08 '13 at 18:12

Werner Henze · Answer 5 · 2020-05-10T19:21:29.570

0

I think it's not allowed to do that. You asked for references to the standard. I believe first thing of interest is 9.3.1 Nonstatic member functions, 1.:

A non-static member function may be called for an object of its class type, or for an object of a class derived (Clause 10) from its class type, using the class member access syntax (5.2.5, 13.3.1.1).

Second let's look at 5.2.5 Class member access, 2.:

The expression E1->E2 is converted to the equivalent form (*(E1)).E2; the remainder of 5.2.5 will address only the first option (dot).

So if E1 is a nullptr, the *E1 will not be allowed. So at least is my guess.

edited May 10 '20 at 19:21

answered Jan 08 '13 at 15:45

Werner Henze

16,404
12
44
69

thanks. This rule does indeed seem to disallow the expression E1->E2 when E1 is null. Conceivably a compiler could implement member fuctions in such a way that they do not behave as expected when called with a null `this` pointer. – user1958486 Jan 08 '13 at 17:03

Is it legal C++ to test the this-pointer in a member function?

5 Answers5

Linked

Related