{"title":"Pointers and Functions","description":null,"content":"A function that takes or returns a pointer can read and write data owned by its caller, share large objects without copying, or even decide at runtime which other function to call. This chapter covers four pointer-and-function patterns: passing a pointer as a parameter, returning a pointer from a function, taking a pointer to a function itself, and choosing between pointer parameters and reference parameters.\n\n---\n\n# Passing a Pointer to a Function\n\nA function parameter declared as `T*` receives an address. Inside the function, the parameter is a local pointer variable that holds whatever address the caller passed in. Reading or writing through that parameter reaches the caller's object directly, with no copy.\n\nA small e-commerce example: a function that applies a discount to a product in place.\n\n\n```cpp\n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n};\n\nvoid applyDiscount(Product* item, double percent) {\n if (item == nullptr) {\n return;\n }\n item->price = item->price * (1.0 - percent / 100.0);\n}\n\nint main() {\n Product mouse{\"Wireless Mouse\", 24.99};\n\n std::cout << mouse.name << \" before: $\" << mouse.price << std::endl;\n applyDiscount(&mouse, 20.0);\n std::cout << mouse.name << \" after: $\" << mouse.price << std::endl;\n return 0;\n}\n```\n\n\n**Output:**\n\n\n```shell\nWireless Mouse before: $24.99\nWireless Mouse after: $19.992\n```\n\n\n`applyDiscount` takes a `Product*`. The call passes `&mouse`, the address of the local `mouse` variable in `main`. Inside the function, `item` is a separate pointer variable, but it holds the same address as `&mouse`, so `item->price = ...` writes through to the same object that `main` named `mouse`. The change is visible after the call returns.\n\nThree details matter when reading this code:\n\n- The pointer parameter `item` is a copy. Reassigning `item` itself (`item = nullptr;` inside the function) does not affect the caller's pointer.\n- The object the pointer points at is shared. Writing through `item` (`item->price = ...`) does affect the caller's object.\n- A null check at the top is a common defensive pattern, because pointer parameters can carry `nullptr`.\n\nThe same shape applies to a non-class pointer. A function that swaps two stock counts:\n\n\n```cpp\n#include \n\nvoid swapStock(int* a, int* b) {\n int temp = *a;\n *a = *b;\n *b = temp;\n}\n\nint main() {\n int mouseStock = 5;\n int keyboardStock = 12;\n\n swapStock(&mouseStock, &keyboardStock);\n\n std::cout << \"Mouse stock: \" << mouseStock << std::endl;\n std::cout << \"Keyboard stock: \" << keyboardStock << std::endl;\n return 0;\n}\n```\n\n\n**Output:**\n\n\n```shell\nMouse stock: 12\nKeyboard stock: 5\n```\n\n\n`swapStock` takes two `int*`. The dereferences `*a` and `*b` reach the caller's variables, so the swap modifies them directly. Without pointers (or references), a function could not change `mouseStock` and `keyboardStock` from outside.\n\n**Quick Check:** What does this code print?\n\n\n```cpp\n#include \n\nvoid reset(int* p) {\n p = nullptr;\n}\n\nint main() {\n int stock = 10;\n int* ptr = &stock;\n reset(ptr);\n std::cout << (ptr == nullptr ? \"null\" : \"valid\") << std::endl;\n return 0;\n}\n```\n\n\n

Answer

\n\n`valid`. Inside `reset`, `p` is a copy of `ptr`. Setting `p = nullptr` only changes the local copy. The caller's `ptr` still holds the address of `stock`. To clear the caller's pointer, the function would need a `int**` parameter or an `int*&` reference parameter.\n\n

\n\n---\n\n# Returning a Pointer from a Function\n\nA function can also return a pointer. The contract for the caller is \"I'll give you back an address; here's what it points at and how long it stays valid\". That second half is where most return-pointer bugs come from.\n\nTwo situations make returning a pointer safe.\n\nThe first is returning the address of something that already exists outside the function. A search function that returns a pointer into a vector the caller owns:\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 = {\n {\"Wireless Mouse\", 24.99},\n {\"USB Cable\", 7.50},\n {\"Laptop Stand\", 39.00}\n };\n\n Product* found = findByName(catalog, \"USB Cable\");\n if (found != nullptr) {\n std::cout << \"Found \" << found->name << \" at $\" << found->price << std::endl;\n } else {\n std::cout << \"Not in catalog.\" << std::endl;\n }\n return 0;\n}\n```\n\n\n**Output:**\n\n\n```shell\nFound USB Cable at $7.50\n```\n\n\n`findByName` returns the address of an element inside `catalog`. The catalog is owned by `main`, so the element lives until `main` ends. The returned pointer is valid for that entire scope. If the catalog instead disappeared before the pointer was used, the same code would be broken.\n\nReturning `nullptr` for \"not found\" is the convention. The caller checks against `nullptr` before dereferencing.\n\nThe second safe case is returning a pointer to memory allocated with `new` inside the function. The caller then owns the lifetime and must `delete` it later:\n\n\n```cpp\n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n};\n\nProduct* createProduct(const std::string& name, double price) {\n return new Product{name, price};\n}\n\nint main() {\n Product* mouse = createProduct(\"Wireless Mouse\", 24.99);\n std::cout << mouse->name << \" costs $\" << mouse->price << std::endl;\n delete mouse;\n return 0;\n}\n```\n\n\n**Output:**\n\n\n```shell\nWireless Mouse costs $24.99\n```\n\n\nThis works, but it puts the lifetime burden on every caller. Forget the `delete` and the program leaks memory. Throw an exception between the call and the `delete` and the program also leaks. Smart pointers exist to fix this problem, which is why modern code returns `std::unique_ptr` instead.\n\n---\n\n# The Dangerous Case: Returning a Pointer to a Local\n\nReturning the address of a function-local variable is a classic C++ bug. The local goes out of scope when the function returns, but the pointer the caller now holds still points at that memory. Dereferencing it is undefined behavior.\n\n**What's wrong with this code?**\n\n\n```cpp\n#include \n\nint* makeStock() {\n int stock = 42;\n return &stock;\n}\n\nint main() {\n int* p = makeStock();\n std::cout << *p << std::endl;\n return 0;\n}\n```\n\n\n`stock` is a local variable. Its storage sits on the stack inside `makeStock`'s frame. The moment `makeStock` returns, that frame is gone, and the memory is free to be reused by the next function call. The returned pointer `p` is dangling: it holds an address that no longer belongs to a live `int`.\n\nOn some compilers, with no optimization, the program might print `42` because the stack memory hasn't been overwritten yet. On others, or with optimization, it prints garbage or crashes. None of these outcomes are guaranteed; the behavior is undefined.\n\nThe compiler often catches this and prints a warning like:\n\n\n```shell\nwarning: address of stack memory associated with local variable 'stock' returned\n```\n\n\nA warning is not an error. The program still compiles. Treating warnings as errors with `-Werror` is a useful habit for exactly this reason.\n\nThe fix depends on what the caller actually needs:\n\n\n```cpp\n// Option 1: return by value. Cheapest for small types.\nint makeStock() {\n return 42;\n}\n\n// Option 2: have the caller own the storage.\nvoid fillStock(int* p) {\n *p = 42;\n}\n\n// Option 3: allocate on the heap. Caller must delete.\nint* makeStockOnHeap() {\n return new int{42};\n}\n```\n\n\nOption 1 is the usual choice for small types. Option 2 fits when the caller wants the function to populate an existing buffer. Option 3 is where modern code uses smart pointers.\n\nThe same trap appears with local arrays:\n\n**What's wrong with this code?**\n\n\n```cpp\nint* makeCartQuantities() {\n int quantities[5] = {1, 2, 3, 4, 5};\n return quantities;\n}\n```\n\n\n`quantities` is a local array. The array name decays into a pointer to its first element, and that element lives on the stack. Returning the pointer hands the caller a dangling address. The fix is to return a `std::vector` by value, which carries its storage with it.\n\n\n```cpp\n#include \n\nstd::vector makeCartQuantities() {\n return {1, 2, 3, 4, 5};\n}\n```\n\n\nThe vector owns heap-allocated memory and copies (or moves) that ownership into the caller. No dangling, no manual `delete`.\n\n---\n\n# Pointers to Functions\n\nA function is a piece of code that lives at some address in memory. A pointer can hold that address, the same way a pointer can hold the address of a variable. The pointer's type encodes the function's signature: return type and parameter types.\n\nA small example. Two pricing strategies, one pointer that picks between them:\n\n\n```cpp\n#include \n\ndouble regularPrice(double base) {\n return base;\n}\n\ndouble salePrice(double base) {\n return base * 0.80;\n}\n\nint main() {\n double (*pricer)(double) = regularPrice;\n std::cout << \"Regular: $\" << pricer(100.0) << std::endl;\n\n pricer = salePrice;\n std::cout << \"Sale: $\" << pricer(100.0) << std::endl;\n return 0;\n}\n```\n\n\n**Output:**\n\n\n```shell\nRegular: $100\nSale: $80\n```\n\n\n`pricer` is declared as a pointer to a function taking a `double` and returning a `double`. The first assignment makes it point at `regularPrice`. The second reassigns it to `salePrice`. The call site `pricer(100.0)` runs whichever function the pointer currently holds.\n\nThe declaration syntax needs care. The parentheses around `*pricer` are required:\n\n\n```cpp\ndouble (*pricer)(double); // pointer to function returning double\ndouble *pricer(double); // function returning pointer-to-double (different!)\n```\n\n\nWithout the inner parentheses, the declaration parses as a function prototype, not a pointer. The reason: function-call `()` binds tighter than dereference `*`, so `*pricer(double)` reads as \"call `pricer`, then dereference the result\". Wrapping `(*pricer)` flips that grouping.\n\nA `using` alias makes the type readable:\n\n\n```cpp\nusing Pricer = double(*)(double);\n\nPricer current = regularPrice;\ncurrent = salePrice;\n```\n\n\nThe basic syntax above is enough for this chapter.\n\n**Quick Check:** Which of these correctly declares a pointer to a function that takes two `int`s and returns a `bool`?\n\n- A) `bool* compare(int, int);`\n- B) `bool (*compare)(int, int);`\n- C) `bool compare(*int, *int);`\n\n

Answer

\n\n**B.** Option A declares a function that returns `bool*`. Option C is not valid C++ syntax. Only B declares `compare` as a pointer to a function, because the parentheses group `*compare` together.\n\n

\n\n---\n\n# Pointer Parameters vs Reference Parameters\n\nC++ has two ways to give a function access to the caller's object without copying it: a pointer parameter, or a reference parameter. They overlap heavily, and choosing between them is mostly a style decision once the constraints are understood.\n\nThe same function, twice:\n\n\n```cpp\n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n};\n\nvoid applyDiscountPtr(Product* item, double percent) {\n if (item == nullptr) {\n return;\n }\n item->price *= (1.0 - percent / 100.0);\n}\n\nvoid applyDiscountRef(Product& item, double percent) {\n item.price *= (1.0 - percent / 100.0);\n}\n\nint main() {\n Product a{\"Mouse\", 24.99};\n Product b{\"Mouse\", 24.99};\n\n applyDiscountPtr(&a, 20.0);\n applyDiscountRef(b, 20.0);\n\n std::cout << \"Pointer version: $\" << a.price << std::endl;\n std::cout << \"Reference version: $\" << b.price << std::endl;\n return 0;\n}\n```\n\n\n**Output:**\n\n\n```shell\nPointer version: $19.992\nReference version: $19.992\n```\n\n\nBoth functions do the same job. The pointer version takes `Product*`, requires the caller to write `&a`, uses `->` to access members, and needs a null check. The reference version takes `Product&`, lets the caller write `b` directly, uses `.` for members, and has no null check because references cannot be null.\n\nThe differences come down to four properties:\n\n\n| Property | Pointer parameter | Reference parameter |\n|----------|-------------------|---------------------|\n| Can be null | Yes | No |\n| Caller syntax | `f(&x)` (explicit address) | `f(x)` (looks like by-value) |\n| Member access | `p->field` | `r.field` |\n| Can be reassigned | Yes (`p = &y`) | No, bound at initialization |\n\n\nCommon rules:\n\n- Use a **reference** when the parameter must always refer to a valid object. The function says \"give me an object, you can't say `none`\".\n- Use a **pointer** when \"no object\" is a meaningful possibility, or when the function may switch which object it works with mid-stream, or when working with C APIs that already use pointers.\n\nFor the discount example, a reference fits better. There is no sensible meaning for \"apply a discount to no product\". A pointer would force every caller to write `&` at the call site for no benefit, and every implementation to add a null check that has no real failure case.\n\nA reasonable pointer parameter, on the other hand:\n\n\n```cpp\n#include \n\nstruct Product;\n\nvoid logProductOrNothing(Product* item) {\n if (item == nullptr) {\n std::cout << \"No product to log.\" << std::endl;\n return;\n }\n // ... log the product ...\n}\n```\n\n\nHere, \"no product\" is a real state the function is designed to handle. A reference parameter would lie about the contract.\n\nA second, more practical separator: caller-side readability. With a pointer parameter, the call site shows `&` explicitly:\n\n\n```cpp\napplyDiscountPtr(&mouse, 20.0);\n```\n\n\nThat `&` is a visible hint that the function might modify `mouse`. With a non-const reference parameter, the call looks identical to pass-by-value:\n\n\n```cpp\napplyDiscountRef(mouse, 20.0);\n```\n\n\nSome style guides (notably the Google C++ Style Guide, historically) require non-const reference parameters be passed as pointers instead, so the call site always shows when an argument might be modified. Other style guides (and modern Google) accept non-const references freely. There is no consensus; pick a convention and stay consistent within a codebase.\n\nFor read-only parameters, `const T&` is the common form for non-trivial types. It avoids the copy of by-value and still cannot be null. A pointer version (`const T*`) only makes sense when \"no object\" is a real state.\n\n**Quick Check:** A function needs to look up a product in a catalog and return the result. The result might be \"not found\". Should the return type be `Product*` or `Product&`?\n\n

Answer

\n\n`Product*`. A reference cannot represent \"not found\", because references have to be bound to a real object at all times. Returning `Product*` lets the function return `nullptr` when the lookup fails. Modern alternatives include `std::optional` (a value type) or `Product*` (a non-owning pointer). A reference does not fit here.\n\n

\n\n---\n\n# A Worked Example: Updating a Cart Through Functions\n\nPutting the pieces together: a small program that operates on a shopping cart through pointer parameters, with both modifying and read-only access.\n\n\n```cpp\n#include \n#include \n#include \n\nstruct CartItem {\n std::string name;\n double price;\n int quantity;\n};\n\nvoid addItem(std::vector* cart, const std::string& name, double price, int qty) {\n if (cart == nullptr) {\n return;\n }\n cart->push_back({name, price, qty});\n}\n\ndouble totalPrice(const std::vector* cart) {\n if (cart == nullptr) {\n return 0.0;\n }\n double total = 0.0;\n for (const CartItem& item : *cart) {\n total += item.price * item.quantity;\n }\n return total;\n}\n\nCartItem* findItem(std::vector* cart, const std::string& name) {\n if (cart == nullptr) {\n return nullptr;\n }\n for (CartItem& item : *cart) {\n if (item.name == name) {\n return &item;\n }\n }\n return nullptr;\n}\n\nint main() {\n std::vector cart;\n\n addItem(&cart, \"Mouse\", 24.99, 1);\n addItem(&cart, \"USB Cable\", 7.50, 2);\n addItem(&cart, \"Laptop Stand\", 39.00, 1);\n\n std::cout << \"Total: $\" << totalPrice(&cart) << std::endl;\n\n CartItem* cable = findItem(&cart, \"USB Cable\");\n if (cable != nullptr) {\n cable->quantity = 3;\n }\n\n std::cout << \"Total after update: $\" << totalPrice(&cart) << std::endl;\n return 0;\n}\n```\n\n\n**Output:**\n\n\n```shell\nTotal: $86.49\nTotal after update: $101.49\n```\n\n\nThree functions, three pointer patterns:\n\n- `addItem` takes a non-const `std::vector*` and modifies the cart by appending to it.\n- `totalPrice` takes a `const std::vector*` and only reads the cart. The `const` says \"I won't modify what this points at\".\n- `findItem` takes a non-const cart pointer and returns a `CartItem*` into the cart. The caller can modify the found item through the returned pointer, as the `cable->quantity = 3` line does.\n\nThe `findItem` return is a case where returning a raw pointer is justified: the cart owns the items, the pointer is non-owning, and the lifetime is obvious from the structure of the code. If the cart were destroyed or resized between the call and the use of the pointer, the pointer would become dangling. That risk is why this pattern often gets replaced by an index or an iterator in larger codebases.\n\nEvery function checks for `nullptr` at the top. That check is appropriate here because the parameter type is `T*`, which can carry null. If these functions used `T&` references instead, the checks would not exist, and the caller could not pass \"no cart\".\n\n---\n\n# Interview Questions\n\n**Q1: What happens when a function returns the address of a local variable, and why?**\n\nThe local variable lives on the stack and is destroyed when the function returns. The returned pointer holds an address that no longer belongs to a valid object, so it is dangling. Dereferencing it is undefined behavior. The program might appear to print the right value if the stack memory has not been overwritten yet, but the behavior is not guaranteed and often breaks under optimization. The fix is to return by value, have the caller pass in a buffer, or allocate on the heap and document the ownership transfer.\n\n**Q2: When should a function parameter be `T*` instead of `T&`?**\n\nUse `T*` when \"no object\" is a meaningful state the function must handle, when the function may rebind to a different object during its execution, or when interoperating with C APIs that already use pointers. Use `T&` (or `const T&`) when the parameter must always refer to a real object. References communicate \"always valid\" through the type system, while pointers leave that as a runtime check.\n\n**Q3: What is the difference between modifying the pointer parameter inside a function versus modifying what it points at?**\n\nModifying the parameter itself (`p = nullptr;` or `p = &other;`) only changes the local copy of the pointer. The caller's pointer variable is not affected. Modifying what the parameter points at (`*p = 5;` or `p->field = 5;`) does affect the caller's object, because the parameter and the caller's pointer hold the same address and refer to the same memory. To let a function reassign the caller's pointer, the parameter has to be `T**` or `T*&`.\n\n**Q4: Why do function pointer declarations need parentheses around the name?**\n\nThe function-call operator `()` has higher precedence than the dereference `*`. Without the inner parentheses, `int* f(int)` reads as \"function `f` that takes an `int` and returns `int*`\", which is a regular function declaration, not a pointer. Wrapping `(*f)` forces the parser to group the dereference with the name, producing \"pointer to function\" instead. The `using` alias syntax sidesteps the syntactic noise by hiding it inside a type alias.\n\n**Q5: What is the risk of returning a non-owning raw pointer into a container, and how is it usually mitigated?**\n\nThe pointer is only valid while the container element it points at stays put. If the container is destroyed, the element is removed, or the container reallocates (which `std::vector` does on growth), the pointer becomes dangling. Mitigations include returning an index instead of a pointer, returning an iterator and documenting invalidation rules, restricting the pointer's lifetime to a scope where the container cannot change, or wrapping the result in `std::optional` for value semantics. For owning return values, `std::unique_ptr` or `std::shared_ptr` is the modern choice.\n\n---\n\n# Exercises\n\n**Exercise 1:** Write a function `increment(int* p)` that adds 1 to the value pointed to. Call it in `main` to bump a counter from 0 to 3.\n\n**Expected Output:**\n\n\n```shell\nCounter: 3\n```\n\n\n

Solution

\n\n\n```cpp\n#include \n\nvoid increment(int* p) {\n if (p == nullptr) {\n return;\n }\n *p = *p + 1;\n}\n\nint main() {\n int counter = 0;\n increment(&counter);\n increment(&counter);\n increment(&counter);\n std::cout << \"Counter: \" << counter << std::endl;\n return 0;\n}\n```\n\n\n

\n\n**Exercise 2:** What does this code print?\n\n\n```cpp\n#include \n\nvoid rebind(int* p) {\n int local = 99;\n p = &local;\n *p = 50;\n}\n\nint main() {\n int x = 10;\n int* ptr = &x;\n rebind(ptr);\n std::cout << x << std::endl;\n return 0;\n}\n```\n\n\n**Expected Output:**\n\n\n```shell\n10\n```\n\n\n

Solution

\n\nThe parameter `p` is a local copy of `ptr`. Inside `rebind`, `p = &local` only changes the copy; `ptr` in `main` still points at `x`. The assignment `*p = 50` writes to `local`, not to `x`. So `x` is still `10` when `main` prints it.\n\n

\n\n**Exercise 3:** Fix the bug in this function.\n\n\n```cpp\nint* makeMaxStock() {\n int stock = 100;\n return &stock;\n}\n```\n\n\n**Expected Output:** A working function that gives the caller a value of 100 without dangling-pointer behavior.\n\n

Solution

\n\n\n```cpp\n#include \n\nint makeMaxStock() {\n return 100;\n}\n\nint main() {\n int max = makeMaxStock();\n std::cout << \"Max stock: \" << max << std::endl;\n return 0;\n}\n```\n\n\nThe original returns the address of a stack-local variable, which is destroyed on return. For a small built-in type, returning by value is the right fix. The heap version with `new int{100}` also works, but leaves the caller responsible for `delete`.\n\n

\n\n**Exercise 4:** Write a function `findMax(const int* values, int count)` that returns a pointer to the largest element in an array, or `nullptr` if `count` is 0.\n\n**Expected Output:**\n\n\n```shell\nMax: 42\n```\n\n\n

Solution

\n\n\n```cpp\n#include \n\nconst int* findMax(const int* values, int count) {\n if (count == 0 || values == nullptr) {\n return nullptr;\n }\n const int* best = &values[0];\n for (int i = 1; i < count; i++) {\n if (values[i] > *best) {\n best = &values[i];\n }\n }\n return best;\n}\n\nint main() {\n int stocks[] = {5, 12, 42, 7, 30};\n const int* m = findMax(stocks, 5);\n if (m != nullptr) {\n std::cout << \"Max: \" << *m << std::endl;\n }\n return 0;\n}\n```\n\n\n

\n\n**Exercise 5:** Predict the output.\n\n\n```cpp\n#include \n\nvoid modify(int** pp) {\n static int newValue = 77;\n *pp = &newValue;\n}\n\nint main() {\n int original = 10;\n int* ptr = &original;\n modify(&ptr);\n std::cout << *ptr << std::endl;\n return 0;\n}\n```\n\n\n**Expected Output:**\n\n\n```shell\n77\n```\n\n\n

Solution

\n\n`modify` takes a pointer to a pointer. Writing `*pp = &newValue` changes the pointer that `pp` points at, which is `ptr` in `main`. After the call, `ptr` no longer holds the address of `original`; it holds the address of `newValue`, whose value is `77`. Because `newValue` is `static`, its storage outlives the function call, so `ptr` is not dangling.\n\n

\n\n**Exercise 6:** Rewrite the following pointer-based function using a reference parameter instead.\n\n\n```cpp\nvoid double_quantity(int* qty) {\n if (qty == nullptr) {\n return;\n }\n *qty = *qty * 2;\n}\n```\n\n\n

Solution

\n\n\n```cpp\nvoid double_quantity(int& qty) {\n qty = qty * 2;\n}\n```\n\n\nThe reference version cannot be null, so the null check is unnecessary. The caller writes `double_quantity(stock)` instead of `double_quantity(&stock)`. A reference fits when \"no quantity\" is not a meaningful state.\n\n

\n\n**Exercise 7:** Write a function `pick(int choice, double base)` that returns the result of either `regularPrice(base)` or `salePrice(base)` based on `choice` (0 for regular, 1 for sale). Use an array of function pointers to dispatch.\n\n**Expected Output:**\n\n\n```shell\nRegular: 100\nSale: 80\n```\n\n\n

Solution

\n\n\n```cpp\n#include \n\ndouble regularPrice(double base) { return base; }\ndouble salePrice(double base) { return base * 0.80; }\n\ndouble pick(int choice, double base) {\n double (*table[2])(double) = {regularPrice, salePrice};\n return table[choice](base);\n}\n\nint main() {\n std::cout << \"Regular: \" << pick(0, 100.0) << std::endl;\n std::cout << \"Sale: \" << pick(1, 100.0) << std::endl;\n return 0;\n}\n```\n\n\n

\n\n**Exercise 8:** What is wrong with this function, and how would you fix it?\n\n\n```cpp\nint* topThreeStocks() {\n int top[3] = {100, 80, 60};\n return top;\n}\n```\n\n\n

Solution

\n\nThe array `top` is local to the function and is destroyed when the function returns. The returned pointer is dangling. The fix is to return a `std::vector` or `std::array` by value:\n\n\n```cpp\n#include \n\nstd::array topThreeStocks() {\n return {100, 80, 60};\n}\n```\n\n\n`std::array` is a fixed-size container that knows its size at compile time, so the size is part of the return type. The value is copied (or moved) to the caller, with no dangling pointer concern.\n\n

\n\n**Exercise 9:** Write a function `swapPointers(int** a, int** b)` that swaps the two `int*` values its parameters point at. Demonstrate that after calling it, two pointers in `main` have traded which variable each points at.\n\n**Expected Output:**\n\n\n```shell\nBefore: p1=10, p2=20\nAfter: p1=20, p2=10\n```\n\n\n

Solution

\n\n\n```cpp\n#include \n\nvoid swapPointers(int** a, int** b) {\n int* temp = *a;\n *a = *b;\n *b = temp;\n}\n\nint main() {\n int x = 10;\n int y = 20;\n int* p1 = &x;\n int* p2 = &y;\n\n std::cout << \"Before: p1=\" << *p1 << \", p2=\" << *p2 << std::endl;\n swapPointers(&p1, &p2);\n std::cout << \"After: p1=\" << *p1 << \", p2=\" << *p2 << std::endl;\n return 0;\n}\n```\n\n\n`swapPointers` takes pointers to pointers, so it can rewrite the caller's pointer variables. After the swap, `p1` holds the address of `y` and `p2` holds the address of `x`.\n\n

\n\n**Exercise 10:** A team is debating whether `update_price(Product*, double)` should take its first argument by pointer or by reference. List two reasons to pick a reference and one reason to pick a pointer.\n\n

Solution

\n\nReasons to prefer a reference:\n\n1. A product is always required for the update to make sense, so \"no object\" is not a state the function should handle. A reference enforces this at the type level.\n2. The call site reads more cleanly: `update_price(mouse, 19.99)` instead of `update_price(&mouse, 19.99)`. No null check is needed inside the function.\n\nReason to prefer a pointer:\n\n1. If the project's style guide requires non-const reference parameters to be passed as pointers (so the `&` at the call site signals that the argument may be modified), a pointer fits. This is a readability convention, not a correctness one.\n\n

\n\n---\n\n# Quiz","pageType":"cpp"}

Pointers and Functions

Get Premium