Gfrktyl

It is an actual pointer, as the standard specifies it (§12.2.2.1):

In the body of a non-static (12.2.1) member function, the keyword this is a prvalue expression whose value is the address of the object for which the function is called. The type of this in a member function of a class X is X*.

this is actually implicit every time you reference a non-static member variable or member function within a class own code. It is also needed (either when implicit or explicit) because the compiler needs to tie back the function or the variable to an actual object at runtime.

Using it explicitly is rarely useful, unless you need, for example, to disambiguate between a parameter and a member variable within a member function. Otherwise, without it the compiler will shadow the member variable with the parameter (See it live on Coliru).

this always has to exist when you are in a non-static method. Whether you explicitly use it or not, you have to have a reference to the current instance, and this is what this gives you.

In both cases, you are going to access memory through the this pointer. It's just that you can omit it in some cases.

This is almost a duplicate of How do objects work in x86 at the assembly level?, where I comment the asm output of some examples, including showing which register the this pointer was passed in.

In asm, this works exactly like a hidden first arg, so both the member-function foo::add(int) and the non-member add which takes an explicit foo* first arg compile to exactly the same asm.

struct foo {

    int m;

    void add(int a);  // not inline so we get a stand-alone definition emitted

};



void foo::add(int a) {

    this->m += a;

}



void add(foo *obj, int a) {

    obj->m += a;

}

On the Godbolt compiler explorer, compiling for x86-64 with the System V ABI (first arg in RDI, second in RSI), we get:

# gcc8.2 -O3

foo::add(int):

        add     DWORD PTR [rdi], esi   # memory-destination add

        ret

add(foo*, int):

        add     DWORD PTR [rdi], esi

        ret

I use GCC 4.4.3

That was released in January 2010, so it's missing nearly a decade of improvements to the optimizer, and to error messages. The gcc7 series has been out and stable for a while. Expect missed optimizations with such an old compiler, especially for modern instruction sets like AVX.

After compilation, every symbol is just an address, so it can't be a run-time issue.

Any member symbol is compiled to an offset in the current class anyway, even if you didn't use this.

When name is used in C++ it can be one of the following.

• In the global namespace (like ::name), or in the current namespace, or in the used namespace (when using namespace ... been used)


• In the current class


• Local definition, in upper block


• Local definition, in current block

Therefore, when you write code, the compiler should scan each, in a manner to look for the symbol name, from the current block and up to the global namespace.

Using this->name helps the compiler to narrow the search for name to only look for it in the current class scope, meaning it skips local definitions, and if not found in class scope, do not look for it in the global scope.

Here is a simple example how "this" could be useful during runtime:

#include <vector>

#include <string>

#include <iostream>



class A;

typedef std::vector<A*> News; 

class A

{

public:

    A(const char* n): name(n){}

    std::string name;

    void subscribe(News& n)

    {

       n.push_back(this);

    }

};



int main()

{

    A a1("Alex"), a2("Bob"), a3("Chris");

    News news;



    a1.subscribe(news);

    a3.subscribe(news);



    std::cout << "Subscriber:";

    for(auto& a: news)

    {

      std::cout << " " << a->name;

    }

    return 0;

}

since I usually use it every single time I refer to a member variable or function.

You always use this when you refer to a member variable or function. There is simply no other way to reach members. The only choice is implicit vs explicit notation.

Let's go back to see how it was done before this to understand what this is.

Without OOP:

struct A {

    int x;

};



void foo(A* that) {

    bar(that->x)

}

With OOP but writing this explicitly

struct A {

    int x;



    void foo(void) {

        bar(this->x)

    }

};

using shorter notation:

struct A {

    int x;



    void foo(void) {

        bar(x)

    }

};

But the difference is only in source code. All are compiled to same thing. If you create a member method, the compiler will create a pointer argument for you and name it "this". If you omit this-> when referring to a member, the compiler is clever just enough to insert it for you most of the time. That's it. The only difference is 6 less letters in the source.

Writing this explicitly makes sense when there is an ambiguity, namely another variable named just like your member variable:

struct A {

    int x;



    A(int x) {

        this->x = x

    }

};

There are some instances, like __thiscall, where OO and non-OO code may end bit different in asm, but whenever the pointer is passed on stack and then optimized to a register or in ECX from the very beginning doesn't make it "not a pointer".

Your machine does not know anything about class methods, they are normal functions under the hood.
Hence methods have to be implemented by always passing a pointer to the current object, it's just implicit in C++, i.e. T Class::method(...) is just syntactic sugar for T Class_Method(Class* this, ...).

Other languages like Python or Lua choose to make it explicit and modern object-oriented C APIs like Vulkan (unlike OpenGL) use a similar pattern.

"this" can also safeguard against shadowing by a function parameter, for example:

class Vector {

   public:

      double x,y,z;

      void SetLocation(double x, double y, double z);

};



void Vector::SetLocation(double x, double y, double z) {

   this->x = x; //Passed parameter assigned to member variable

   this->y = y;

   this->z = z;

}

(Obviously, writing such code is discouraged.)

if the compiler inlines a member function that is called with static rather than dynamic binding, it might be able to optimize away the this pointer. Take this simple example:

#include <iostream>



using std::cout;

using std::endl;



class example {

  public:

  int foo() const { return x; }

  int foo(const int i) { return (x = i); }



  private:

  int x;

};



int main(void)

{

  example e;

  e.foo(10);

  cout << e.foo() << endl;

}

GCC 7.3.0 with the -march=x86-64 -O -S flag is able to compile cout << e.foo() to three instructions:

movl    $10, %esi

leaq    _ZSt4cout(%rip), %rdi

call    _ZNSolsEi@PLT

This is a call to std::ostream::operator<<. Remember that cout << e.foo(); is syntactic sugar for std::ostream::operator<< (cout, e.foo());. And operator<<(int) could be written two ways: static operator<< (ostream&, int), as a non-member function, where the operand on the left is an explicit parameter, or operator<<(int), as a member function, where it’s implicitly this.

The compiler was able to deduce that e.foo() will always be the constant 10. Since the 64-bit x86 calling convention is to pass function arguments in registers, that compiles down to the single movl instruction, which sets the second function parameter to 10. The leaq instruction sets the first argument (which might be an explicit ostream& or the implicit this) to &cout. Then the program makes a call to the function.

In more complex cases, though—such as if you have a function taking an example& as a parameter—the compiler needs to look up this, as this is what tells the program which instance it’s working with, and therefore, which instance’s x data member to look up.

Consider this example:

class example {

  public:

  int foo() const { return x; }

  int foo(const int i) { return (x = i); }



  private:

  int x;

};



int bar( const example& e )

{

  return e.foo();

}

The function bar() gets compiled to a bit of boilerplate and the instruction:

movl    (%rdi), %eax

ret

You remember from the previous example that %rdi on x86-64 is the first function argument, the implicit this pointer for the call to e.foo(). Putting it in parentheses, (%rdi), means look up the variable at that location. (Since the only data in an example instance is x, &e.x happens to be the same as &e in this case.) Moving the contents to %eax sets the return value.

In this case, the compiler needed the implicit this argument to foo(/* example* this */) to be able to find &e and therefore &e.x. In fact, inside a member function (that isn’t static), x, this->x and (*this).x all mean the same thing.

this is a pointer. It's like an implicit parameter that's part of every method. You could imagine using plain C functions and writing code like:

Socket makeSocket(int port) { ... }

void send(Socket *this, Value v) { ... }

Value receive(Socket *this) { ... }



Socket *mySocket = makeSocket(1234);

send(mySocket, someValue); // The subject, `mySocket`, is passed in as a param called "this", explicitly

Value newData = receive(socket);

In C++, similar code might look like:

mySocket.send(someValue); // The subject, `mySocket`, is passed in as a param called "this"

Value newData = mySocket.receive();