{"title":"this Pointer","description":null,"content":"Every non-static member function of a class has a hidden parameter: a pointer to the object the function was called on. That pointer is called `this`, and it can be used explicitly when the implicit version is not enough. This lesson covers what `this` actually is, when typing it is required, the chaining pattern that returns `*this`, the address-comparison technique used in copy and assignment, and a few sharp edges around null calls and `delete this;`.\n\n---\n\n# What `this` Actually Is\n\nInside a member function, `this` is a built-in pointer that points to the instance the function was called on. The compiler generates it; the programmer does not declare it. A call like `cart.addItem(...)` effectively passes `&cart` to `addItem` as a hidden first argument, and inside the function that hidden argument is named `this`.\n\n\n```cpp\n#include \n#include \n\nclass Product {\npublic:\n std::string name;\n double price;\n\n void showAddress() {\n std::cout << name << \" lives at address \" << this << std::endl;\n }\n};\n\nint main() {\n Product mouse{\"Wireless Mouse\", 24.99};\n Product keyboard{\"Mechanical Keyboard\", 89.99};\n\n mouse.showAddress();\n keyboard.showAddress();\n\n std::cout << \"&mouse = \" << &mouse << std::endl;\n std::cout << \"&keyboard = \" << &keyboard << std::endl;\n return 0;\n}\n```\n\n\nThe value of `this` inside `mouse.showAddress()` is exactly `&mouse`. Inside `keyboard.showAddress()` it is exactly `&keyboard`. Same function, two different `this` pointers, because the call site picks which object is current.\n\nThe model:\n\n\n```mermaid\nflowchart LR\n M[\"mouse
(Product)\"]:::cyan -->|call addItem| F[\"addItem(
this = &mouse)\"]:::orange\n K[\"keyboard
(Product)\"]:::cyan -->|call addItem| G[\"addItem(
this = &keyboard)\"]:::orange\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe function body is the same machine code in both calls. The only difference is the hidden `this` argument, which is how the function knows which fields to read.\n\nInside the function, every unqualified mention of a member is implicitly `this->member`. When `showAddress` references `name`, the compiler treats it as `this->name`. Typing `this->` directly is rarely required, but understanding that it is always there clears up a lot of confusion later.\n\n\n```cpp\nvoid Product::showAddress() {\n // these two lines mean the exact same thing\n std::cout << name << std::endl;\n std::cout << this->name << std::endl;\n}\n```\n\n\n---\n\n# When You Actually Need to Type `this->`\n\nMost code never writes `this->` because the implicit version is shorter and reads better. Two situations require it.\n\nThe first is name shadowing. When a constructor or setter takes a parameter with the same name as a member, the parameter wins inside the function body, and the member is hidden. `this->` reaches past the parameter to the member.\n\n\n```cpp\n#include \n#include \n\nclass Customer {\nprivate:\n std::string name;\n std::string email;\n int loyaltyPoints;\n\npublic:\n Customer(std::string name, std::string email, int loyaltyPoints) {\n // without this->, you'd be assigning the parameter to itself\n this->name = name;\n this->email = email;\n this->loyaltyPoints = loyaltyPoints;\n }\n\n void print() const {\n std::cout << name << \" | \" << email << \" | points: \" << loyaltyPoints << std::endl;\n }\n};\n\nint main() {\n Customer alice{\"Alice Tan\", \"alice@example.com\", 240};\n alice.print();\n return 0;\n}\n```\n\n\nForgetting the `this->` here is a silent bug. `name = name;` is legal C++: it assigns the parameter `name` to itself, leaving the member `name` empty. With `-Wself-assign` (on by default with `-Wall` in modern g++), a warning appears, but warnings are not errors. Naming the member `name_` or `m_name` is a common style choice precisely to dodge this trap; using `this->` is the other common fix.\n\nThe second situation is in templates that inherit from a class template. The lookup rules require `this->` to find inherited members. That case appears in the templates chapter. For now, name shadowing in constructors and setters is the practical reason to type `this->`.\n\nWriting `this->name` versus `name` is identical at runtime. The compiler resolves both to the same memory access. The choice is about disambiguating names for the compiler and for human readers.\n\n---\n\n# Returning `*this` for Method Chaining\n\nSometimes several setters on the same object need to be called in one line. The pattern that enables this has each setter return a reference to the current object so the next call can be chained onto the result.\n\n\n```cpp\n#include \n#include \n\nclass Order {\nprivate:\n std::string customer;\n std::string address;\n int itemCount;\n double total;\n\npublic:\n Order& setCustomer(const std::string& name) {\n customer = name;\n return *this;\n }\n\n Order& setAddress(const std::string& addr) {\n address = addr;\n return *this;\n }\n\n Order& setItemCount(int count) {\n itemCount = count;\n return *this;\n }\n\n Order& setTotal(double amount) {\n total = amount;\n return *this;\n }\n\n void print() const {\n std::cout << customer << \" -> \" << address\n << \" | items: \" << itemCount\n << \" | total: $\" << total << std::endl;\n }\n};\n\nint main() {\n Order o;\n o.setCustomer(\"Bob Lee\")\n .setAddress(\"221B Baker Street\")\n .setItemCount(3)\n .setTotal(74.97);\n\n o.print();\n return 0;\n}\n```\n\n\n`return *this;` dereferences the `this` pointer, producing a reference to the current object. The return type `Order&` declares that the function gives back a reference, not a copy. Once those two are wired together, every setter call evaluates to the same `Order` instance, and the next `.setX(...)` keeps working on it.\n\nThe reason this pattern is called **fluent setters** is that the code reads like a small sentence: configure customer, then address, then item count, then total. It is a popular style in builder objects and configuration APIs.\n\nBe careful about the return type. Writing `Order setCustomer(...)` instead of `Order& setCustomer(...)` returns a copy of the object instead of a reference. The chain still compiles, but every link operates on a fresh copy that is thrown away at the end of the expression, so the original `o` never changes. That is a silent bug.\n\n\n```cpp\n// WRONG: returns a copy, chain modifies temporaries\nOrder setCustomer(const std::string& name) {\n customer = name;\n return *this;\n}\n\n// RIGHT: returns a reference, chain modifies the original\nOrder& setCustomer(const std::string& name) {\n customer = name;\n return *this;\n}\n```\n\n\n---\n\n# Comparing Addresses with `this`\n\nSome operations involve two objects of the same class, and the function needs to know whether they are actually the same object in memory. The standard technique is to compare the address of the other object against `this`.\n\n\n```cpp\n#include \n#include \n\nclass Cart {\nprivate:\n std::string customer;\n double total;\n\npublic:\n Cart(const std::string& c, double t) : customer(c), total(t) {}\n\n void copyFrom(const Cart& other) {\n if (&other == this) {\n std::cout << \"Skipping self-copy on \" << customer << std::endl;\n return;\n }\n customer = other.customer;\n total = other.total;\n }\n\n void print() const {\n std::cout << customer << \" | $\" << total << std::endl;\n }\n};\n\nint main() {\n Cart a{\"Alice\", 99.99};\n Cart b{\"Bob\", 49.50};\n\n a.copyFrom(b);\n a.print();\n\n a.copyFrom(a); // same object on both sides\n a.print();\n return 0;\n}\n```\n\n\n`&other == this` asks: \"Is the object passed in the same object the function was called on?\" When the answer is yes, the function can skip the copy entirely, or take a shortcut. For a small struct with simple fields, self-copy is harmless: every field is copied onto itself. The check becomes important when the class manages a resource that gets released before being re-acquired, because a self-copy would release the resource and then try to copy from the released slot.\n\nThis same check shows up in copy-assignment operators, covered in the Operator Overloading lesson later. The basic idea is identical: detect self-assignment so the assignment logic does not corrupt the object.\n\n\n```cpp\n// preview of what an assignment operator looks like\nCart& operator=(const Cart& other) {\n if (this == &other) return *this; // self-assignment guard\n customer = other.customer;\n total = other.total;\n return *this;\n}\n```\n\n\nThe full mechanics of `operator=` belong to its own lesson. For now, the takeaway is that comparing `this` against the address of another object is how a member function detects \"operating on myself\", and that detection is sometimes critical for correctness.\n\nThe address comparison is a single integer compare. There is no measurable runtime cost. The reason to skip self-copy is correctness for resource-managing classes, not performance.\n\n---\n\n# `this` in `const` Member Functions\n\nWhen a member function is declared with `const` after the parameter list, the type of `this` changes. In a non-`const` member function of `Product`, `this` has type `Product* const`: a pointer that cannot be reassigned, pointing to a non-`const` object. In a `const` member function, `this` has type `const Product* const`: the object it points to is also `const`.\n\nThe practical consequence: inside a `const` member function, no member can be modified through `this`, and no non-`const` member function can be called on `this`.\n\n\n```cpp\n#include \n#include \n\nclass Product {\nprivate:\n std::string name;\n int stock;\n\npublic:\n Product(const std::string& n, int s) : name(n), stock(s) {}\n\n void restock(int amount) { // non-const: can modify members\n stock += amount;\n }\n\n int getStock() const { // const: cannot modify members\n // stock = 100; // would not compile here\n // restock(5); // would not compile here either\n return stock;\n }\n\n const std::string& getName() const {\n return name;\n }\n};\n\nint main() {\n Product mouse{\"Wireless Mouse\", 50};\n mouse.restock(10);\n std::cout << mouse.getName() << \": \" << mouse.getStock() << std::endl;\n return 0;\n}\n```\n\n\nInside `getStock()`, the compiler treats `this` as `const Product* const`, so `stock = 100;` would be rejected with an error like `assignment of member 'Product::stock' in read-only object` from g++. That is the const-correctness machinery working as intended: a function that promises not to modify the object cannot break that promise, even by accident.\n\nThe full coverage of `const` member functions, including how they interact with `const` references and overloading, lives in the Encapsulation chapter. For this lesson, the point is that `this` carries the const-ness of the function, and that is why a `const` member function cannot write to fields.\n\n---\n\n# `this` Is Never Null in a Valid Call\n\nA call like `obj.method()` or `ptr->method()` on a valid object makes `this` inside the function point at that object. What happens with a member function call through a null pointer?\n\n\n```cpp\n#include \n\nclass Product {\npublic:\n int stock = 0;\n\n void print() {\n std::cout << \"stock = \" << stock << std::endl;\n }\n};\n\nint main() {\n Product* p = nullptr;\n p->print(); // UNDEFINED BEHAVIOR\n return 0;\n}\n```\n\n\nThe line `p->print()` is **undefined behavior** in C++. The standard says calling a member function through a null pointer makes the entire program ill-defined. The compiler can assume any code reaching the inside of a non-static member function has a valid `this`, and it generates code based on that assumption.\n\nThe observed behavior on real hardware depends on the function. If `print()` only touches members, the access `stock` inside the function expands to `this->stock`, which dereferences a null pointer and typically crashes with a segmentation fault. On some platforms, calling a non-virtual member function that never reads or writes any member can appear to \"work\" because no actual dereference happens. That apparent success is a trap. The behavior is undefined, the compiler can optimize on that assumption, and the program is broken even when it looks fine.\n\n\n```mermaid\nflowchart LR\n A[Product* p = nullptr]:::red --> B[p->print]:::orange\n B --> C[this = nullptr]:::red\n C --> D[Access this->stock]:::red\n D --> E[Crash or
silent corruption]:::red\n\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe rule: **never call a member function on a null pointer**. When a pointer might be null, check it before calling anything on it.\n\n\n```cpp\nif (p != nullptr) {\n p->print();\n}\n```\n\n\nThe mirror of this rule is also useful: inside a non-static member function, do not write `if (this == nullptr)` to defend against null calls. The standard says that branch can never be reached in a well-formed program, and modern compilers will sometimes delete the check entirely as dead code. The right place for the null check is at the call site, not inside the function.\n\n---\n\n# `delete this;` and Why It Is Dangerous\n\nC++ allows a member function to write `delete this;`, which destroys the object the function was called on. It is legal syntax, and a few patterns rely on it, but the requirements are strict enough that it should be treated as a last-resort tool.\n\n\n```cpp\n#include \n#include \n\nclass Session {\nprivate:\n std::string user;\n\npublic:\n Session(const std::string& u) : user(u) {\n std::cout << \"Session started for \" << user << std::endl;\n }\n\n ~Session() {\n std::cout << \"Session ended for \" << user << std::endl;\n }\n\n void logout() {\n std::cout << user << \" logging out\" << std::endl;\n delete this;\n // anything below this line that touches members is UNDEFINED BEHAVIOR\n }\n};\n\nint main() {\n Session* s = new Session{\"Alice\"};\n s->logout();\n s = nullptr; // prevent accidental reuse\n return 0;\n}\n```\n\n\nThe output looks clean, but the requirements that make this code valid are easy to violate:\n\n1. The object must have been allocated with `new` (not on the stack, not as a member of another object, not statically). `delete this;` calls `operator delete`, which only works on `new`-allocated memory.\n2. After `delete this;`, the function must not touch any member of the object, including reading `this` itself. Every field is gone.\n3. After `delete this;` returns to the caller, no other code can use the original pointer. The caller usually sets its pointer to `nullptr`, and any other pointer that aliased the object becomes a dangling pointer.\n4. The object must not be referenced anywhere else in the program. A second pointer holding the same address now points at freed memory.\n\n\n```cpp\nint main() {\n Session a{\"OnStack\"};\n a.logout(); // UNDEFINED BEHAVIOR: not allocated with new\n return 0;\n}\n```\n\n\nThe stack-allocated `Session` in this example cannot be deleted, because `delete` only frees heap memory. When `logout()` runs `delete this;` against a stack address, the program corrupts the heap allocator's internal state and typically crashes immediately or much later, often in unrelated code, which makes the bug hard to debug.\n\nThe performance cost of `delete this;` is the same as any other `delete`: one call into the allocator. The real cost is the cognitive overhead and the risk. Almost every use case for `delete this;` is better served by smart pointers (`std::unique_ptr`, `std::shared_ptr`) or by having the owner of the object call `delete` from outside.\n\nLegitimate uses do exist. Reference-counted objects sometimes call `delete this;` when the count drops to zero. Plug-in systems that hand objects across module boundaries sometimes use it because the caller cannot see the destructor directly. In day-to-day application code, especially when learning C++, skip `delete this;` entirely and let smart pointers manage lifetimes.","pageType":"cpp"}

this Pointer

Get Premium