1. For every a and b which are non-const pointers of the same type, you can do a = b;, right?

  2. Inside non-const member functions the this keyword exists, which is a non-const pointer. So logicaly if b is same type as this you can also do this = b; right?


You cannot do this = b;, because this uses pointer syntax but logically this is a reference!

But why on earth is this syntactically a pointer but logically reference?

Can this weird behavior be corrected in the next C++ standard, by introducing a new keyword, for example me which will be a reference not only logically but also syntactically?

(See also my attempt to solve this here: "Is it a good idea to "#define me (*this)"?")

  • 2
    C++ is quite well designed by quite expert people. It has the (ugly but practical) requirement of being (reasonably) C compatible. Commented Jul 15, 2014 at 10:19
  • 18
    this predates references.. That's why it's a pointer.
    – MSalters
    Commented Jul 15, 2014 at 13:57
  • 4
    why do you say it's "logically a reference" when it's a const pointer? (Not the same as pointer-to-const) Commented Dec 31, 2017 at 21:33

3 Answers 3


this is (like nullptr) a constant pointer; the pointed data is const if and only if this appears in the body of a const member function.

You cannot change a constant pointer, like you cannot change a constant literal like 23.

So assignment to this like

this = p;  // WRONG

is prohibited for the same reasons assignment to nullptr is forbidden:

nullptr = 0; // wrong
  • 6
    Thanks, you are right, good explanation. I am also confusing pointers to const data with const pointers to data. Commented Jul 15, 2014 at 10:10
  • 1
    Hmpf. nullptr is not a pointer, and thus not a constant pointer, but it is a null pointer constant. Just like 0. Commented Aug 26, 2018 at 15:46

this is NOT poorly designed. You almost never have local variables with the same names as class member names. While this construction does occur in constructors for POD or nearly POD objects, the language has a better way of dealing with this. Behold:

#include <stdio.h>

class A {
        A(int m1, int m2) : m1(m1), m2(m2) {}
        int m1;
        int m2;

int main()
    A a(1, 2);
    printf("%d, %d\n", a.m1, a.m2);

I'm sure we can agree this demonstration is full of horrors, but the point is obvious. The constructor has local variables with the same name as members and initializes the members with the same names as local variables. You can run this program and get the output "1, 2".

Also, in C++ we expect that we may declare functions having good parameter names (for hinting) and bad names for the actual implementation. This can even be done for inline functions if we bother to declare them separately rather than bodily in the class definition.

For all of these reasons, a member function rarely needs to access its class explicitly but only its pointer, thus the this keyword is a pointer.

Historical artifact: this was once not const and could be assigned to. This was a bad idea.


One can make an argument that this is a bit clumsy.
Having a self-reference instead would probably feel a bit more natural nowadays:
Its type could then carry slightly more information in it than the type of this can, namely:

  1. Whether the member-function was guaranteed called on an rvalue-reference, and
  2. that it actually always refers to an object.

Still, when C++ finally got references (invented for operator-overloading, I think), the decision on this was already ancient history. And backwards-compatibility is no laughing matter.

Not the answer you're looking for? Browse other questions tagged or ask your own question.