{"title":"Null Pointers","description":null,"content":"A null pointer is a pointer that holds a special value meaning \"this pointer points at no object\". It's a way to give a pointer a defined, checkable \"empty\" state instead of leaving it pointing at random memory. This chapter covers what a null pointer is, why it exists, how to check for one, and the common bugs that come from forgetting to check before dereferencing.\n\n---\n\n# What a Null Pointer Represents\n\nEvery pointer holds an address. Most of the time, that address belongs to a real object that the program can read or write. But there are situations where a pointer variable exists with no object yet to point at:\n\n- A search function did not find what it was looking for and has nothing to return.\n- A linked list's last node marks the end with a `next` pointer that points at no further node.\n- An order has an optional discount rule, and most orders don't set one.\n- A configuration field is filled in later, so it starts out empty.\n\nFor all of these, the pointer needs a value that means \"I'm not pointing at anything right now\". That value is what a null pointer carries. Reading the pointer or comparing it is fine. Dereferencing it is not.\n\n\n```cpp\n#include \n\nint main() {\n int* p = nullptr;\n\n std::cout << \"Address held by p: \" << p << std::endl;\n\n if (p == nullptr) {\n std::cout << \"p points at nothing.\" << std::endl;\n }\n return 0;\n}\n```\n\n\n**Output (typical):**\n\n\n```shell\nAddress held by p: 0\np points at nothing.\n```\n\n\n`p` is a valid `int*`. It can be copied, returned from a function, stored in a struct, and compared. The only operation that doesn't work is dereferencing it. Writing `*p` when `p` is null is undefined behavior, which on most systems shows up as a segmentation fault. The check `p == nullptr` is the common way to decide whether dereferencing is safe.\n\nThe address printed for a null pointer is implementation-defined. Most compilers print `0`, some print `0x0`, some print `(nil)`. The actual bit pattern is also not required to be all zeros, though on every mainstream platform it is. What the C++ standard guarantees is that a null pointer of type `T*` compares equal to another null pointer of the same type, and unequal to any pointer that points at a real object.\n\n---\n\n# Why Null Pointers Exist as a Distinct Value\n\nA pointer has to hold some address. If a program declares an `int*` and doesn't assign anything, the pointer holds whatever bits were already in that memory location, which is almost certainly not a valid address. Dereferencing it is undefined behavior, and there is no way to tell at runtime whether the address is valid.\n\n\n```cpp\nint* p; // uninitialized: holds garbage\nstd::cout << *p; // undefined behavior, cannot be detected\n```\n\n\nA designated \"no address\" value makes \"empty\" a state the program can check for. With a null pointer, the program can ask \"do you point at anything?\" before trying to dereference. Without it, every pointer variable would either need a real address from creation or risk corruption that cannot be detected.\n\nTwo pointer states then exist as distinct things:\n\n\n| State | What it holds | Can it be detected? |\n|-------|---------------|---------------------|\n| Uninitialized (wild) | Whatever bits were already there | No, looks like any other pointer |\n| Null | A defined sentinel value | Yes, `p == nullptr` |\n| Pointing at a real object | The address of a live object | Yes, but only the program knows which case it's in |\n\n\nA wild pointer is the dangerous case. To the compiler, it looks like any other pointer; there is no runtime tag that distinguishes \"garbage address\" from \"real address\". A null pointer, by contrast, is a known bad state that the program can detect and respond to. That distinction is why the convention is to initialize every pointer either to a real address or to `nullptr`.\n\n\n```cpp\nint* a = &someValue; // points at something real\nint* b = nullptr; // points at nothing, but explicitly\nint* c; // dangerous: holds garbage\n```\n\n\nThe first two are safe to work with. The third is a bug waiting to be triggered.\n\n**Quick Check:** Which of these pointer values can be safely passed to a function that checks `if (p != nullptr) { *p = 5; }`?\n\n- A) `int* a = &someInt;`\n- B) `int* b = nullptr;`\n- C) `int* c;` (uninitialized local)\n\n

Answer

\n\n**A and B.** A is a real address, so the check passes and the dereference is safe. B is null, so the check fails and the dereference is skipped. C is undefined behavior the moment it gets used in any way that depends on its value, because the bits in `c` could form an address that happens to be non-null, and the check would pass and the dereference would corrupt unrelated memory. The check only protects against null, not against garbage.\n\n

\n\n---\n\n# `NULL` and `nullptr`: A Short Note\n\nC++ has two ways to spell \"the null pointer value\": the older `NULL` macro and the newer `nullptr` keyword. They mean nearly the same thing in plain assignments and comparisons, but they behave differently in subtle situations involving overloading and templates.\n\n\n```cpp\nint* a = NULL; // works\nint* b = nullptr; // works, modern form\nint* c = 0; // works, but discouraged\n```\n\n\n`NULL` is a macro defined as either `0` or `((void*)0)`, depending on the compiler. It comes from C and predates C++ function overloading. The result is that `NULL` is essentially an integer in C++ code, which causes problems when the compiler has to pick between overloads. `nullptr`, added in C++11, is a distinct type (`std::nullptr_t`) that only ever matches pointer parameters, never integer ones.\n\nThe practical guidance for new code is to use `nullptr` everywhere. `NULL` and `0` still appear in older codebases. For the rest of this chapter, \"null pointer\" means \"the null-pointer value, however it was spelled\".\n\n---\n\n# Checking for Null Before Dereferencing\n\nThe most important habit when working with raw pointers is to check before dereferencing whenever the pointer could be null. The check is a one-line conditional, and skipping it is a common cause of segmentation faults in C++ code.\n\n\n```cpp\n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n};\n\nvoid printProduct(const Product* item) {\n if (item == nullptr) {\n std::cout << \"(no product)\" << std::endl;\n return;\n }\n std::cout << item->name << \" - $\" << item->price << std::endl;\n}\n\nint main() {\n Product mouse{\"Wireless Mouse\", 24.99};\n Product* p = &mouse;\n Product* nothing = nullptr;\n\n printProduct(p);\n printProduct(nothing);\n return 0;\n}\n```\n\n\n**Output:**\n\n\n```shell\nWireless Mouse - $24.99\n(no product)\n```\n\n\nThe check at the top of `printProduct` is the contract: \"this function accepts a null pointer and handles it explicitly\". Without the check, the call `printProduct(nothing)` would dereference null inside the function and crash.\n\nThree common idioms for the check appear interchangeably:\n\n\n```cpp\nif (p == nullptr) { /* ... */ } // explicit comparison\nif (!p) { /* ... */ } // implicit conversion to bool\nif (p) { /* ... */ } // truthy form\n```\n\n\nThe implicit-bool form works because pointers convert to `bool` automatically: a null pointer is `false`, any non-null pointer is `true`. All three forms compile to the same thing. The explicit form (`p == nullptr`) reads most clearly and is the recommended style for new code, especially when the codebase distinguishes between \"pointer is null\" and \"pointer is valid but the pointed-to value is falsy\".\n\nFor chained pointer access, every step needs a check if any of them could be null. A common scenario: a customer object that has an optional shipping address, and the address has an optional phone number.\n\n\n```cpp\n#include \n#include \n\nstruct Phone {\n std::string number;\n};\n\nstruct Address {\n std::string street;\n Phone* phone;\n};\n\nstruct Customer {\n std::string name;\n Address* shipTo;\n};\n\nvoid printShippingPhone(const Customer* c) {\n if (c == nullptr) {\n std::cout << \"No customer.\" << std::endl;\n return;\n }\n if (c->shipTo == nullptr) {\n std::cout << c->name << \" has no shipping address.\" << std::endl;\n return;\n }\n if (c->shipTo->phone == nullptr) {\n std::cout << c->name << \" has no phone on file.\" << std::endl;\n return;\n }\n std::cout << c->name << \": \" << c->shipTo->phone->number << std::endl;\n}\n\nint main() {\n Phone phone{\"555-0123\"};\n Address addr{\"1 Maple St\", &phone};\n Customer alice{\"Alice\", &addr};\n\n Customer bob{\"Bob\", nullptr};\n\n printShippingPhone(&alice);\n printShippingPhone(&bob);\n printShippingPhone(nullptr);\n return 0;\n}\n```\n\n\n**Output:**\n\n\n```shell\nAlice: 555-0123\nBob has no shipping address.\nNo customer.\n```\n\n\nThree levels of pointer, three null checks. Skipping any of them risks a crash. This kind of step-by-step guarding is a sign that the data model could use a redesign (perhaps with `std::optional`, or with required fields instead of pointers), but in legacy code it is the unavoidable shape.\n\n**Quick Check:** What does this code print?\n\n\n```cpp\n#include \n\nint main() {\n int* p = nullptr;\n if (p) {\n std::cout << \"valid\" << std::endl;\n } else {\n std::cout << \"null\" << std::endl;\n }\n return 0;\n}\n```\n\n\n

Answer

\n\n`null`. A null pointer converts to `false` in a boolean context, so `if (p)` evaluates to false and the `else` branch runs. The output is `null`.\n\n

\n\n---\n\n# What Happens When a Null Pointer Is Dereferenced\n\nDereferencing a null pointer is undefined behavior. The C++ standard does not say what happens; it leaves the outcome entirely up to the compiler, the operating system, and the runtime conditions. On modern platforms, the most common outcome is a crash, but that is a courtesy of the operating system, not a guarantee of the language.\n\nA minimal example. This program will crash on every mainstream platform:\n\n\n```cpp\n#include \n\nint main() {\n int* p = nullptr;\n std::cout << *p << std::endl; // undefined behavior\n return 0;\n}\n```\n\n\n**Typical output (Linux):**\n\n\n```shell\nSegmentation fault (core dumped)\n```\n\n\n**Typical output (macOS):**\n\n\n```shell\nSegmentation fault: 11\n```\n\n\n**Typical output (Windows):**\n\nA dialog about the program stopping working, or a stack trace in a debugger.\n\nThe reason a crash happens on these platforms: address `0` (and a small range around it) is mapped as inaccessible by the operating system. Any attempt to read or write at that address triggers a CPU fault, which the OS turns into a signal that terminates the process. This is a safety net, not a feature of C++.\n\nWhere this gets dangerous is on platforms or in situations where address `0` is readable. Some embedded systems map valid hardware registers at address `0`. Some optimizers, having proved that a pointer is null, can delete entire blocks of code that would only execute if the pointer were non-null. Both cases produce behavior that looks nothing like a clean crash.\n\nA subtle case: dereferencing a null pointer to access a member can sometimes appear to \"work\" if the access is only computing an address, not actually touching the memory.\n\n\n```cpp\n#include \n\nstruct Product {\n int stock;\n};\n\nint main() {\n Product* p = nullptr;\n Product* q = &p->stock; // computes nullptr + offset of stock\n std::cout << \"Address: \" << q << std::endl;\n return 0;\n}\n```\n\n\nThis is still undefined behavior, even though no memory is read. Some compilers print a small offset like `0x4`. Others optimize the expression away entirely. The program might not crash, but the language standard makes no promises about what it produces. Treat any operation that starts with a null pointer dereference as broken.\n\n---\n\n# Common Bugs from Null Pointer Dereference\n\nA handful of patterns produce most null-dereference bugs in C++ code. Each one has a recognizable shape and a known fix.\n\n### Bug 1: Forgetting to Check After a Lookup\n\n\n```cpp\n#include \n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n};\n\nProduct* findByName(std::vector& catalog, const std::string& target) {\n for (Product& p : catalog) {\n if (p.name == target) {\n return &p;\n }\n }\n return nullptr;\n}\n\nint main() {\n std::vector catalog = {{\"Mouse\", 24.99}};\n Product* found = findByName(catalog, \"Keyboard\");\n\n // BUG: no null check\n std::cout << found->name << std::endl; // crash\n return 0;\n}\n```\n\n\nThe function `findByName` returns `nullptr` when the search misses. The caller forgets to check. The dereference `found->name` reads through a null pointer and crashes.\n\n**Fix:** Check the return value before using it.\n\n\n```cpp\nif (found != nullptr) {\n std::cout << found->name << std::endl;\n} else {\n std::cout << \"Not found.\" << std::endl;\n}\n```\n\n\n### Bug 2: Dereferencing Before Assignment\n\n\n```cpp\n#include \n\nint main() {\n int* p;\n if (p == nullptr) {\n std::cout << \"null\" << std::endl;\n } else {\n *p = 5; // undefined behavior either way\n }\n return 0;\n}\n```\n\n\nThe pointer is uninitialized, not null. The check `p == nullptr` might pass or fail depending on what garbage happened to be in the variable's bits. The check does not protect against a wild pointer.\n\n**Fix:** Initialize the pointer at the point of declaration.\n\n\n```cpp\nint* p = nullptr;\n```\n\n\nNow the check works as intended, and the dereference is correctly skipped.\n\n### Bug 3: Forgetting That Allocation Can Return Null\n\nThe `new` operator throws `std::bad_alloc` on failure by default, so most modern C++ code does not return null. But `new (std::nothrow)` and C-style `malloc` both return null on failure.\n\n\n```cpp\n#include \n#include \n\nint main() {\n int* buffer = (int*)std::malloc(1000000000000ULL * sizeof(int));\n buffer[0] = 42; // crash if malloc returned nullptr\n std::free(buffer);\n return 0;\n}\n```\n\n\nThe allocation request is huge enough to fail. `malloc` returns `nullptr`. The next line dereferences null.\n\n**Fix:** Check the return value of any allocation function that can return null.\n\n\n```cpp\nint* buffer = (int*)std::malloc(size * sizeof(int));\nif (buffer == nullptr) {\n std::cerr << \"Out of memory.\" << std::endl;\n return 1;\n}\n```\n\n\nFor C++, `new` with the throwing behavior is the default, and it never returns null. The check is only needed when explicitly opting out with `std::nothrow` or when calling into C APIs.\n\n### Bug 4: A Member Function Called on a Null Pointer\n\n\n```cpp\n#include \n#include \n\nstruct Customer {\n std::string name;\n void greet() { std::cout << \"Hello, \" << name << std::endl; }\n};\n\nint main() {\n Customer* c = nullptr;\n c->greet(); // undefined behavior\n return 0;\n}\n```\n\n\nCalling a member function through a null pointer is undefined behavior, even if the function does not access any members. The `this` pointer inside the function is null, and any subsequent member access dereferences it.\n\nA confusing wrinkle: this code might appear to \"work\" if the function does not actually touch `*this`. Some compilers will let it run without raising an error. The language standard still calls it undefined behavior, and an optimizer is free to assume that `this` is never null and remove related checks.\n\n**Fix:** Check the pointer before calling any member function.\n\n\n```cpp\nif (c != nullptr) {\n c->greet();\n}\n```\n\n\n### Bug 5: Mixing Up Null Pointers and Empty Containers\n\n\n```cpp\n#include \n#include \n\nint main() {\n std::vector* cart = nullptr;\n if (cart->empty()) { // crash\n std::cout << \"Empty cart.\" << std::endl;\n }\n return 0;\n}\n```\n\n\nA null `std::vector*` is not the same as an empty `std::vector`. A null pointer does not point at a vector at all, so calling any method on it is undefined behavior. The check `cart->empty()` is meant to ask \"is the vector empty?\", but it first has to access the vector through `cart`, and there is no vector to access.\n\n**Fix:** Check the pointer first, then the contents.\n\n\n```cpp\nif (cart == nullptr || cart->empty()) {\n std::cout << \"Empty cart.\" << std::endl;\n}\n```\n\n\nBetter yet, design APIs so that a missing cart is represented by an empty cart, not by a null pointer. Then the check goes away entirely.\n\n---\n\n# Where Null Pointers Show Up in Real APIs\n\nSeveral standard-library and OS-level APIs use null pointers as a signal. Recognizing the pattern makes it easier to know when a check is required.\n\n\n| API | Returns null when |\n|-----|-------------------|\n| `std::map::find(...)` | Not directly; returns iterator. End iterator is the sentinel, not nullptr. |\n| `std::string::data()` | Never (always non-null for non-empty strings; `nullptr`-equivalent for some old impls of empty strings) |\n| `std::fopen(...)` | The file could not be opened |\n| `std::malloc(...)` | The allocation failed |\n| `dlopen(...)` (POSIX) | The library could not be loaded |\n| `getenv(\"VAR\")` | The environment variable is not set |\n| Tree/graph traversal: `node->left`, `node->next` | The current node has no child/successor |\n\n\nThe standard C library leans on null pointers heavily because C does not have references or exceptions. Modern C++ code often uses `std::optional`, exceptions, or `std::expected` (C++23) for the same job, but legacy and C-style APIs still return `nullptr` to signal \"not available\".\n\nFor tree and linked-list traversal, the null pointer at the end of a chain is not a bug; it's the structure's terminator. Code that walks these structures has the null check baked into its loop condition:\n\n\n```cpp\nstruct Node {\n int value;\n Node* next;\n};\n\nvoid printList(const Node* head) {\n while (head != nullptr) {\n std::cout << head->value << \" \";\n head = head->next;\n }\n std::cout << std::endl;\n}\n```\n\n\nThe loop continues as long as `head` is not null. When the last node's `next` is null, the loop ends. This is the canonical use of null pointers as data, not as an error signal.\n\n**Quick Check:** A function `parseInt(const char* text)` returns an `int` on success. How should it signal \"parsing failed\"?\n\n- A) Return `0`\n- B) Return `nullptr`\n- C) Take a `bool*` out-parameter and set it on success/failure\n- D) Take an `int*` out-parameter, return `bool`, and use the return for success/failure\n\n

Answer

\n\n**D** (or `std::optional` in modern C++). Option A overloads a legitimate result with a failure code. Option B does not compile, because the return type is `int`, not a pointer. Option C is awkward. Option D is the C-style answer that disambiguates success from result. `std::optional` is the modern equivalent that avoids the out-parameter entirely.\n\n

\n\n---\n\n# Defensive Habits for Code That Uses Raw Pointers\n\nA few rules cover most of the bug surface.\n\n- **Initialize every pointer at declaration.** Either to an address (`int* p = &x;`) or to `nullptr`. Never leave a pointer variable unassigned.\n- **Check before dereferencing whenever the pointer could be null.** This includes return values of search functions, optional fields in structs, and any pointer that comes from an external source.\n- **Set pointers to `nullptr` after a delete.** If the pointer might be checked later, this prevents a use-after-free from looking like a valid dereference.\n- **Prefer references for parameters that cannot be null.** A `T&` parameter cannot carry null. This pushes the \"can this be missing?\" question to the type system, where the compiler can enforce it.\n- **Use `std::optional` or `std::expected` when \"missing\" is a meaningful value-level state.** These types make the absent case impossible to ignore at the call site, because the type forces a check before access.\n- **In ownership-bearing APIs, use smart pointers.** A `std::unique_ptr` or `std::shared_ptr` carries ownership and can still be null, but the destructor handles cleanup and reduces the surface for use-after-free.\n\nNone of these eliminate null pointers entirely. They reduce the places where a forgotten check can cause a crash.\n\n---\n\n# A Worked Example: Looking Up a Customer with Null Handling\n\nA program that finds a customer in a small list and prints their email. The lookup might fail; the customer might not have an email on file.\n\n\n```cpp\n#include \n#include \n#include \n\nstruct Email {\n std::string address;\n};\n\nstruct Customer {\n int id;\n std::string name;\n Email* contactEmail;\n};\n\nCustomer* findCustomer(std::vector& list, int id) {\n for (Customer& c : list) {\n if (c.id == id) {\n return &c;\n }\n }\n return nullptr;\n}\n\nvoid printContact(std::vector& list, int id) {\n Customer* c = findCustomer(list, id);\n if (c == nullptr) {\n std::cout << \"Customer \" << id << \" not found.\" << std::endl;\n return;\n }\n if (c->contactEmail == nullptr) {\n std::cout << c->name << \" has no email on file.\" << std::endl;\n return;\n }\n std::cout << c->name << \": \" << c->contactEmail->address << std::endl;\n}\n\nint main() {\n Email aliceEmail{\"alice@example.com\"};\n\n std::vector customers = {\n {1, \"Alice\", &aliceEmail},\n {2, \"Bob\", nullptr},\n };\n\n printContact(customers, 1);\n printContact(customers, 2);\n printContact(customers, 99);\n return 0;\n}\n```\n\n\n**Output:**\n\n\n```shell\nAlice: alice@example.com\nBob has no email on file.\nCustomer 99 not found.\n```\n\n\nTwo pointer chains, two null checks, three outcomes. `findCustomer` returns null when the id is unknown, so the first check catches a missing customer. `contactEmail` is a pointer field that is null when no email is on file, so the second check catches a customer who exists but has no contact. Both null states are part of the data model, not bugs. Without them, the data model would need a different shape: an \"is set\" flag next to every optional field, a default empty email object that callers have to distinguish from a real one, or `std::optional` in place of the raw pointer.\n\n---\n\n# Interview Questions\n\n**Q1: What is the difference between a null pointer and an uninitialized pointer?**\n\nA null pointer holds a defined sentinel value that compares equal to `nullptr`. It can be checked, and dereferencing it produces a defined failure (undefined behavior, which on most platforms is a segmentation fault). An uninitialized pointer holds whatever bits happened to be in its memory location, which may or may not look like a real address. The check `p == nullptr` cannot tell an uninitialized pointer from a real one, so the only safe approach is to initialize every pointer at the point of declaration.\n\n**Q2: Why is dereferencing a null pointer undefined behavior rather than a guaranteed crash?**\n\nC++ aims to allow efficient compilation across many platforms, including embedded systems where address `0` may map to real memory (such as a hardware register). The standard cannot promise a crash because the runtime conditions differ. Treating the operation as undefined behavior lets the compiler assume that any dereferenced pointer is non-null, which enables optimization, but it also means the program might crash, print garbage, or appear to work depending on the platform and the optimizer.\n\n**Q3: When should a function return a pointer instead of a reference, given the possibility of null?**\n\nReturn a pointer when \"no value\" is a meaningful and expected outcome the caller must handle, such as a search function whose target may not be in the data. Return a reference when the function always has a real object to return. The reference enforces the \"always valid\" contract at the type level. In modern C++, `std::optional` is often preferred over pointer return for value-type results, because it avoids the null-pointer pitfall while still expressing the \"missing\" case.\n\n**Q4: How does `nullptr` differ from `NULL` in C++?**\n\n`nullptr` (C++11) is a keyword of type `std::nullptr_t` that only converts to pointer types. `NULL` is a preprocessor macro defined as either `0` or `((void*)0)`. In overloaded function lookup, `NULL` often matches integer parameters instead of pointer ones, producing surprising bugs. `nullptr` always matches pointer overloads. For everyday code, use `nullptr`.\n\n**Q5: A coworker says \"this code is fine because we always check for null before dereferencing\". What other failure modes does that check not protect against?**\n\nThe null check does not protect against:\n\n- Uninitialized pointers that happen to look non-null.\n- Dangling pointers that hold the address of a destroyed object.\n- Pointers into a container that has since been resized or destroyed.\n- Use-after-free, where the memory has been deallocated but the pointer still holds the address.\n- Race conditions where another thread modifies the pointer between the check and the dereference.\n\nA null check guards only against the specific case of \"the pointer is exactly equal to null\". Many bugs in raw-pointer code come from one of the other categories above.\n\n---\n\n# Exercises\n\n**Exercise 1:** Write a program that declares an `int*`, initializes it to `nullptr`, and prints either \"valid\" or \"null\" depending on whether it points at something.\n\n**Expected Output:**\n\n\n```shell\nnull\n```\n\n\n

Solution

\n\n\n```cpp\n#include \n\nint main() {\n int* p = nullptr;\n if (p == nullptr) {\n std::cout << \"null\" << std::endl;\n } else {\n std::cout << \"valid\" << std::endl;\n }\n return 0;\n}\n```\n\n\n

\n\n**Exercise 2:** Predict the output.\n\n\n```cpp\n#include \n\nint main() {\n int* p = nullptr;\n std::cout << (p ? \"true\" : \"false\") << std::endl;\n\n int x = 10;\n p = &x;\n std::cout << (p ? \"true\" : \"false\") << std::endl;\n return 0;\n}\n```\n\n\n**Expected Output:**\n\n\n```shell\nfalse\ntrue\n```\n\n\n

Solution

\n\nA null pointer converts to `false` in a boolean context, so the first print is `false`. After `p = &x`, the pointer holds a real address and converts to `true`, so the second print is `true`.\n\n

\n\n**Exercise 3:** Fix the bug.\n\n\n```cpp\n#include \n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n};\n\nProduct* find(std::vector& list, const std::string& name) {\n for (Product& p : list) {\n if (p.name == name) {\n return &p;\n }\n }\n return nullptr;\n}\n\nint main() {\n std::vector catalog = {{\"Mouse\", 24.99}};\n Product* found = find(catalog, \"Keyboard\");\n std::cout << found->name << std::endl;\n return 0;\n}\n```\n\n\n**Expected Output:**\n\n\n```shell\nNot found.\n```\n\n\n

Solution

\n\n\n```cpp\nint main() {\n std::vector catalog = {{\"Mouse\", 24.99}};\n Product* found = find(catalog, \"Keyboard\");\n if (found != nullptr) {\n std::cout << found->name << std::endl;\n } else {\n std::cout << \"Not found.\" << std::endl;\n }\n return 0;\n}\n```\n\n\n`find` returns `nullptr` when the name is not in the catalog. The caller has to check before dereferencing.\n\n

\n\n**Exercise 4:** Write a function `safePrint(const std::string* s)` that prints the string if the pointer is not null, and prints `(empty)` if it is. Call it with both a valid pointer and a null one.\n\n**Expected Output:**\n\n\n```shell\nHello\n(empty)\n```\n\n\n

Solution

\n\n\n```cpp\n#include \n#include \n\nvoid safePrint(const std::string* s) {\n if (s == nullptr) {\n std::cout << \"(empty)\" << std::endl;\n return;\n }\n std::cout << *s << std::endl;\n}\n\nint main() {\n std::string greeting = \"Hello\";\n safePrint(&greeting);\n safePrint(nullptr);\n return 0;\n}\n```\n\n\n

\n\n**Exercise 5:** A linked-list node looks like this:\n\n\n```cpp\nstruct Node {\n int value;\n Node* next;\n};\n```\n\n\nWrite a function `length(const Node* head)` that returns the number of nodes in the list, using a null check in the loop condition.\n\n**Expected Output:**\n\n\n```shell\nLength: 3\n```\n\n\n

Solution

\n\n\n```cpp\n#include \n\nstruct Node {\n int value;\n Node* next;\n};\n\nint length(const Node* head) {\n int count = 0;\n while (head != nullptr) {\n count++;\n head = head->next;\n }\n return count;\n}\n\nint main() {\n Node c{30, nullptr};\n Node b{20, &c};\n Node a{10, &b};\n\n std::cout << \"Length: \" << length(&a) << std::endl;\n return 0;\n}\n```\n\n\nThe loop relies on the last node's `next` being `nullptr` to terminate. This is the canonical use of a null pointer as data.\n\n

\n\n**Exercise 6:** What's wrong with this code, and how would you fix it?\n\n\n```cpp\n#include \n\nint main() {\n int* p;\n if (p == nullptr) {\n std::cout << \"null\" << std::endl;\n } else {\n *p = 42;\n }\n return 0;\n}\n```\n\n\n

Solution

\n\n`p` is uninitialized, not null. The check might pass or fail depending on what bits happen to be in `p`'s memory. The fix is to initialize `p` at declaration:\n\n\n```cpp\nint* p = nullptr;\n```\n\n\nNow the check correctly detects the null state and the dereference is skipped.\n\n

\n\n**Exercise 7:** A struct represents an order with an optional discount pointer:\n\n\n```cpp\nstruct Discount {\n double percent;\n};\n\nstruct Order {\n double subtotal;\n Discount* discount;\n};\n```\n\n\nWrite a function `finalTotal(const Order& order)` that returns the subtotal minus the discount, or the subtotal unchanged if the discount pointer is null.\n\n**Expected Output:**\n\n\n```shell\nOrder 1 total: $90\nOrder 2 total: $50\n```\n\n\n

Solution

\n\n\n```cpp\n#include \n\nstruct Discount {\n double percent;\n};\n\nstruct Order {\n double subtotal;\n Discount* discount;\n};\n\ndouble finalTotal(const Order& order) {\n if (order.discount == nullptr) {\n return order.subtotal;\n }\n return order.subtotal * (1.0 - order.discount->percent / 100.0);\n}\n\nint main() {\n Discount tenPercent{10.0};\n Order o1{100.0, &tenPercent};\n Order o2{50.0, nullptr};\n\n std::cout << \"Order 1 total: $\" << finalTotal(o1) << std::endl;\n std::cout << \"Order 2 total: $\" << finalTotal(o2) << std::endl;\n return 0;\n}\n```\n\n\n

\n\n**Exercise 8:** Why is this idiom safe even though it dereferences a pointer without a check?\n\n\n```cpp\nvoid processProduct(const Product& item) {\n std::cout << item.name << std::endl;\n}\n```\n\n\n

Solution

\n\nThe parameter is a reference (`const Product&`), not a pointer. References cannot be null in well-formed C++ code. The caller has to provide a real object, and the function body can rely on `item` being a valid `Product`. No null check is needed inside the function.\n\n

\n\n**Exercise 9:** Predict the output and explain.\n\n\n```cpp\n#include \n\nstruct Customer {\n int id;\n void greet() { std::cout << \"Hello, customer \" << id << std::endl; }\n};\n\nint main() {\n Customer* c = nullptr;\n c->greet();\n return 0;\n}\n```\n\n\n

Solution

\n\nThe behavior is undefined. Calling a member function through a null pointer passes `nullptr` as the `this` pointer. Inside `greet`, the access to `id` dereferences `this`, which is null, so the program will most likely crash with a segmentation fault on a modern platform. Some optimizers may also delete the call entirely after deducing that `this` cannot be null in well-formed code. Either way, the output is not predictable, and the code should never be written this way.\n\n

\n\n**Exercise 10:** Rewrite this function so that the missing-value case is encoded in the type system instead of via a null pointer.\n\n\n```cpp\nconst std::string* findEmail(int customerId);\n```\n\n\n

Solution

\n\n\n```cpp\n#include \n#include \n\nstd::optional findEmail(int customerId);\n```\n\n\n`std::optional` is empty when no value is present and holds a string when one is. The caller checks with `has_value()` or uses `value_or(default)`. The compiler enforces the check before access (through `operator*` or `value()`), so forgetting to check is harder than with a raw pointer. The function no longer needs to return a pointer at all.\n\n

","pageType":"cpp"}

Null Pointers

Get Premium