{"title":"Function Parameters","description":null,"content":"Parameters are the inputs that let one function handle many cases. Without them, every variation of a task would need its own function: one to add a wireless mouse to a cart, another for a USB cable, another for a notebook. With parameters, a single `addToCart` function works for any product. This lesson covers what parameters are, the difference between the names in the function signature and the values at the call site, type matching, naming conventions, and how `const` on a parameter keeps a function from quietly editing its own copy of an input.\n\n---\n\n# What a Parameter Is\n\nA parameter is a named placeholder inside a function definition. When the function is called, the caller supplies a value, and that value flows in through the parameter. The function uses the parameter like a regular local variable for the duration of the call.\n\nHere's a function that prints a welcome line for a customer. Without parameters, it could only ever greet one name.\n\n\n```cpp\n#include \n#include \n\nvoid greetCustomer(std::string customerName) {\n std::cout << \"Welcome back, \" << customerName << \"!\" << std::endl;\n}\n\nint main() {\n greetCustomer(\"Priya\");\n greetCustomer(\"Marcus\");\n greetCustomer(\"Hiroshi\");\n return 0;\n}\n```\n\n\nThe same function handles three different greetings. `customerName` is the parameter. Each call passes a different string in, and the function does its job with whatever value it received.\n\nA function with parameters is a template for behavior. The body says \"do this thing with these inputs,\" and the inputs change every time the function runs. That single idea is what makes functions reusable instead of one-off scripts.\n\n---\n\n# Formal Parameters vs Actual Arguments\n\nThese two terms get used loosely, but they refer to two different things, and the distinction shows up in compiler error messages all the time.\n\n- A **formal parameter** is the name declared inside the function's parameter list. It lives in the function definition.\n- An **actual argument** (often just called an argument) is the value the caller passes at the call site. It lives wherever the function is being called from.\n\nIn the code below, `productId` and `quantity` are formal parameters. `42` and `3` are the actual arguments.\n\n\n```cpp\n#include \n\nvoid addToCart(int productId, int quantity) {\n std::cout << \"Added \" << quantity\n << \" of product #\" << productId\n << \" to cart.\" << std::endl;\n}\n\nint main() {\n addToCart(42, 3);\n return 0;\n}\n```\n\n\nThe compiler matches arguments to parameters strictly by position: the first argument becomes the value of the first parameter, the second argument becomes the second parameter, and so on. There's no name-based matching at the call site in C++. If you write `addToCart(42, 3)`, the function has no way to know whether `42` was meant for `productId` or `quantity`; it just takes what's there in order.\n\n\n```mermaid\nflowchart LR\n A[Call site
addToCart 42, 3]:::cyan --> B[Argument 1: 42]:::orange\n A --> C[Argument 2: 3]:::orange\n B --> D[Parameter
productId]:::green\n C --> E[Parameter
quantity]:::green\n D --> F[Function body
uses productId
and quantity]:::teal\n E --> F\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe diagram shows what happens when `addToCart(42, 3)` runs. The two arguments flow into the two parameters by position, and then the body executes with `productId = 42` and `quantity = 3`.\n\nA small but important note on terminology: in casual conversation people say \"parameter\" and \"argument\" almost interchangeably, and even some books do. The C++ standard is precise about it, and so are compiler error messages, so it helps to keep the distinction in mind. When the compiler says \"too many arguments to function `addToCart`,\" it means you passed more values at the call site than the function declares parameters.\n\n---\n\n# Zero, One, and Many Parameters\n\nA function can declare any number of parameters, including zero. The parameter list lives between the parentheses in the function header, and parameters are separated by commas. Each parameter needs a type and a name.\n\nA function with no parameters takes no input. Its job is fixed and doesn't vary call to call.\n\n\n```cpp\n#include \n\nvoid printHeader() {\n std::cout << \"===== ORDER SUMMARY =====\" << std::endl;\n}\n\nint main() {\n printHeader();\n return 0;\n}\n```\n\n\nThe empty parentheses are required even though there are no parameters. You can also write `void printHeader(void)` (a C-style hold-over), but plain `()` is the modern convention.\n\nA function with one parameter takes a single input.\n\n\n```cpp\n#include \n#include \n\nvoid printPrice(double price) {\n std::cout << \"$\" << std::fixed << std::setprecision(2) << price << std::endl;\n}\n\nint main() {\n printPrice(19.99);\n printPrice(4.49);\n return 0;\n}\n```\n\n\nA function with multiple parameters takes several inputs. Each one is declared independently with its own type and name.\n\n\n```cpp\n#include \n#include \n\nvoid printCartLine(std::string itemName, int quantity, double price) {\n double lineTotal = quantity * price;\n std::cout << std::fixed << std::setprecision(2)\n << itemName << \" x \" << quantity\n << \" @ $\" << price\n << \" = $\" << lineTotal << std::endl;\n}\n\nint main() {\n printCartLine(\"Wireless Mouse\", 2, 24.99);\n printCartLine(\"USB Cable\", 1, 8.50);\n return 0;\n}\n```\n\n\nThree parameters, three arguments per call, matched by position. Each parameter has its own type: `std::string`, `int`, `double`. C++ doesn't require parameters to share a type, and mixing types is the normal case.\n\nThere's no hard limit on parameter count, but past four or five parameters a function gets hard to call correctly. The order matters, and a long list invites swapping arguments by accident. When you find yourself wanting six or seven parameters, the usual fix is to group related parameters into a struct.\n\n---\n\n# Parameter Naming\n\nParameter names live inside the function body, so they don't have to match anything outside. The names are for the human reading the function, not for the compiler. That said, good names make the function self-documenting, and bad names make it a guessing game.\n\nTwo principles to follow:\n\n- **Describe what the value means, not what its type is.** Prefer `quantity` over `qty` or `q` or `intVar`. The type is already in the declaration.\n- **Use the same style as the rest of the codebase.** C++ has no enforced casing rule, but most modern codebases use `camelCase` for parameters (`customerName`, `productId`, `unitPrice`). Some use `snake_case` (`customer_name`). Pick one and stick with it.\n\nCompare these two versions of the same function:\n\n\n```cpp\n// Version 1: opaque\nvoid f(int a, double b, int c) {\n std::cout << a << \" \" << b << \" \" << c << std::endl;\n}\n\n// Version 2: clear\nvoid printOrderLine(int productId, double unitPrice, int quantity) {\n std::cout << productId << \" \" << unitPrice << \" \" << quantity << std::endl;\n}\n```\n\n\nBoth compile. Both produce the same output. The first one forces a reader to step into the body, figure out what `a`, `b`, and `c` mean, and remember the order. The second one tells you everything you need to know from the signature alone.\n\nFunction declarations (the ones in header files, before the definition) are allowed to omit parameter names entirely:\n\n\n```cpp\nvoid addToCart(int, int); // legal, but unhelpful\n```\n\n\nThe compiler accepts this because the types are enough to match calls. Don't write declarations this way. The name is the only documentation a caller gets when reading a header, and stripping it out forces them to dig into the implementation.\n\n---\n\n# Type Matching and Implicit Conversions\n\nThe compiler checks that every argument is compatible with the type of the parameter it's being matched to. If the types match exactly, the value is copied straight in. If they don't match but the compiler knows how to convert one to the other, it applies an implicit conversion before the call.\n\nA clean exact match:\n\n\n```cpp\n#include \n\nvoid shipItems(int quantity) {\n std::cout << \"Shipping \" << quantity << \" items.\" << std::endl;\n}\n\nint main() {\n int count = 5;\n shipItems(count); // int passed to int parameter, no conversion\n return 0;\n}\n```\n\n\nWhen types differ but a conversion is well-defined, the compiler inserts it automatically. Numeric conversions are the most common case: `int` to `double`, `double` to `int`, `char` to `int`, and so on.\n\n\n```cpp\n#include \n#include \n\nvoid printPrice(double price) {\n std::cout << std::fixed << std::setprecision(2) << \"$\" << price << std::endl;\n}\n\nint main() {\n int wholeDollars = 25;\n printPrice(wholeDollars); // int 25 converts to double 25.0\n return 0;\n}\n```\n\n\nThe argument is an `int`, the parameter is a `double`, and the compiler promotes `25` to `25.0` before the call. This direction (`int` to `double`) is safe because every representable `int` fits in a `double` without loss for typical values.\n\nThe other direction is where things get risky. Going from `double` to `int` is a **narrowing conversion**, and it silently drops the fractional part.\n\n\n```cpp\n#include \n\nvoid addToCart(int productId, int quantity) {\n std::cout << \"Product \" << productId\n << \", quantity \" << quantity << std::endl;\n}\n\nint main() {\n double partialQuantity = 2.7;\n addToCart(42, partialQuantity); // double 2.7 becomes int 2\n return 0;\n}\n```\n\n\nThe compiler accepts the call (often with a warning under `-Wall` or `-Wconversion`), but the value `2.7` becomes `2` before it reaches the body. The caller probably meant something different. This is the kind of bug that survives code review because the call site looks reasonable.\n\n\n> **INFO**\n>\n> **Cost:** Implicit numeric conversions are essentially free at runtime; the cost is correctness, not performance. A `double` to `int` narrowing or an unsigned-to-signed mismatch can change values without warning unless you compile with `-Wall -Wconversion`.\n\n\nThe narrowing problem also shows up between integer types of different widths:\n\n\n```cpp\n#include \n\nvoid recordPurchase(int amount) {\n std::cout << \"Recorded amount: \" << amount << std::endl;\n}\n\nint main() {\n long bigAmount = 5000000000; // 5 billion, fits in long\n recordPurchase(bigAmount); // truncated to int, value changes\n return 0;\n}\n```\n\n\nOn a typical 64-bit system, `long` is 64 bits and `int` is 32 bits, so `5000000000` won't fit in an `int`. The value gets truncated, and the printed result is some nonsense like `705032704`. The compiler usually warns, but the program still runs and produces a wrong answer.\n\nTwo habits cut down on conversion bugs:\n\n- Match types deliberately when you write the parameter list. If a function counts items, the parameter is `int` (or `std::size_t` if it could exceed `INT_MAX`). If it represents money, it's `double` (or a fixed-point type in real code).\n- Turn on conversion warnings (`-Wall -Wconversion`) and treat them as errors during development.\n\n---\n\n# Argument Order and Readability\n\nBecause C++ matches arguments to parameters strictly by position, the order of the parameter list is part of the function's contract. Swapping two arguments at the call site is a bug the compiler can rarely catch.\n\n\n```cpp\n#include \n#include \n\nvoid applyDiscount(double price, double percent) {\n double finalPrice = price * (1.0 - percent / 100.0);\n std::cout << std::fixed << std::setprecision(2)\n << \"Final price: $\" << finalPrice << std::endl;\n}\n\nint main() {\n applyDiscount(80.0, 10.0); // price=80, percent=10\n applyDiscount(10.0, 80.0); // oops, swapped\n return 0;\n}\n```\n\n\nBoth calls compile because both arguments are `double`. The first one applies a 10% discount to an $80 item ($72). The second one accidentally applies an 80% discount to a $10 item ($2). The function did exactly what it was told. The bug is at the call site, but the parameter order made it easy to write.\n\nA few patterns help here:\n\n- **Put the most important parameter first.** For `applyDiscount(price, percent)`, the price is the thing being discounted, so it leads.\n- **Group related parameters together.** A function like `setShippingAddress(name, street, city, zip)` reads left to right.\n- **Avoid two adjacent parameters of the same type unless their order is obvious.** A signature like `void copy(int* src, int* dst)` is asking for trouble.\n\nWhen two adjacent parameters share a type and the order isn't obvious, named-argument workarounds help readability:\n\n\n```cpp\n#include \n\nvoid formatPrice(double value, const std::string& currencyCode) {\n std::cout << currencyCode << \" \" << value << std::endl;\n}\n\nint main() {\n double amount = 49.99;\n std::string currency = \"USD\";\n\n // Local variables document the role of each argument:\n formatPrice(amount, currency);\n\n return 0;\n}\n```\n\n\nStoring the values in well-named local variables before the call gives the reader a label even if the parameter list itself is ambiguous. This isn't a language feature, just a discipline that prevents most order-related mistakes.\n\nThe signature uses `const std::string&` for the currency code, which is a topic the next lesson on pass-by-reference covers in depth. For the rest of this lesson, focus on the parameter list rather than the reference syntax.\n\n---\n\n# All Examples Here Pass by Value\n\nEvery parameter in this lesson takes the argument **by value**, which means the function gets its own copy of the data. Writing to the parameter inside the body changes only that local copy, not the caller's variable.\n\n\n```cpp\n#include \n\nvoid addOne(int quantity) {\n quantity = quantity + 1;\n std::cout << \"Inside function: \" << quantity << std::endl;\n}\n\nint main() {\n int cartCount = 5;\n addOne(cartCount);\n std::cout << \"After function: \" << cartCount << std::endl;\n return 0;\n}\n```\n\n\n`cartCount` is still `5` after the call. The function received a copy of `cartCount`, added one to the copy, and discarded it when the function returned. The caller's variable was never touched.\n\nThat's the default model for C++ parameters, and it's the only one this lesson uses. Pass by reference and pass by pointer let a function read or modify the caller's original variable, but they have their own syntax (`int&` or `int*`) and their own trade-offs, which the next lesson covers.\n\nFor now, the takeaway is simple: when you call a function with a plain parameter type like `int` or `double` or `std::string`, the function works on a copy. The caller's variable is safe from being clobbered.\n\n\n> **INFO**\n>\n> **Cost:** Passing built-in types like `int` and `double` by value is as cheap as a register copy. Passing a `std::string` or a `std::vector` by value is not free, because the entire container's contents get copied. The next lesson covers when to switch to a reference to avoid the copy.\n\n\n---\n\n# Using `const` on a Parameter\n\nHere's a subtle thing about pass-by-value: even though writing to the parameter doesn't affect the caller, you can still modify the local copy. Sometimes that's useful (you want to use the parameter as a working variable), but more often it's a source of confusion. A reader looking at a long function might think a parameter still holds its original value when, halfway through, it doesn't.\n\nAdding `const` in front of a value parameter prevents the function body from writing to it. The parameter becomes read-only inside the function.\n\n\n```cpp\n#include \n\nvoid addToCart(const int productId, const int quantity) {\n // productId = 99; // compile error: assignment of read-only parameter\n\n std::cout << \"Adding \" << quantity\n << \" of product \" << productId << std::endl;\n}\n\nint main() {\n addToCart(42, 3);\n return 0;\n}\n```\n\n\nTrying to write `productId = 99` inside the body would fail with `error: assignment of read-only parameter 'productId'`. The function is now contractually bound (to its own author) not to modify either parameter.\n\nThis `const` applies only inside the function body. It doesn't change the caller's experience at all. Both of these declarations behave identically from the outside:\n\n\n```cpp\nvoid addToCart(int productId, int quantity); // caller sees no difference\nvoid addToCart(const int productId, const int quantity); // caller sees no difference\n```\n\n\nSome C++ style guides recommend marking every value parameter `const` to make the function's intent explicit. Others say it's clutter for built-in types and that the convention should be reserved for cases where the body is long enough that re-assignment would actually be confusing. Both positions are defensible; pick the one your team agrees on.\n\nWhere `const` on a value parameter genuinely earns its keep is in functions that take large structs or strings and want to signal \"I'm only reading this.\" Even there, modern C++ usually pairs `const` with a reference (`const std::string&`) to avoid the copy. The plain `const T` form (without the `&`) is the one this lesson is about.\n\n\n```cpp\n#include \n#include \n\nvoid logPurchase(const std::string customerName, const double amount) {\n // The body cannot accidentally overwrite customerName or amount.\n std::cout << customerName << \" purchased $\" << amount << std::endl;\n}\n\nint main() {\n logPurchase(\"Priya\", 49.99);\n return 0;\n}\n```\n\n\nThis version of `logPurchase` still copies the string and the double (it's pass-by-value), but the `const` keeps the function body honest. The reader knows, from the signature alone, that nothing inside is going to silently re-assign `customerName` partway through.\n\n---\n\n# A Worked Example: Discounts and Currency\n\nPutting several of the ideas above into one small program. The function `applyDiscount` takes a price and a percent, and returns the discounted amount. `formatPrice` takes a value and a currency code and prints it. Both functions use clear parameter names, `const` on inputs they don't intend to modify, and pass-by-value for everything.\n\n\n```cpp\n#include \n#include \n#include \n\ndouble applyDiscount(const double price, const double percent) {\n return price * (1.0 - percent / 100.0);\n}\n\nvoid formatPrice(const double value, const std::string currencyCode) {\n std::cout << currencyCode << \" \"\n << std::fixed << std::setprecision(2)\n << value << std::endl;\n}\n\nint main() {\n double cartTotal = 129.95;\n double discountPercent = 15.0;\n\n double finalPrice = applyDiscount(cartTotal, discountPercent);\n\n formatPrice(cartTotal, \"USD\");\n formatPrice(finalPrice, \"USD\");\n\n return 0;\n}\n```\n\n\nA few things to notice in this program. The parameter names in `applyDiscount` (`price`, `percent`) tell the reader what each input represents, so the caller knows the first argument is the thing being discounted and the second is the rate. The `const` on each parameter signals that the function won't mutate its local copies. And the call site passes the cart total first and the discount second, matching the declaration order.\n\nIf you swapped the arguments at the call site (`applyDiscount(discountPercent, cartTotal)`), the function would happily compute `15.0 * (1.0 - 129.95 / 100.0)`, which produces a wildly wrong negative number. Type matching alone isn't enough; argument order has to be right too.\n\n---\n\n# Common Mistakes\n\nA short list of the parameter-related mistakes that show up most often in beginner code, and how to spot them.\n\n\n| Mistake | Symptom | Fix |\n|---|---|---|\n| Mixing up argument order | Function returns wrong values for \"obvious\" inputs | Use clearly-named local variables for each argument; double-check the signature |\n| Passing a `double` to an `int` parameter | Fractional part silently dropped | Match types exactly, or convert explicitly with `static_cast` so the intent is visible |\n| Writing to a parameter expecting the caller to see the change | \"Why didn't my variable update?\" | Pass-by-value never modifies the caller; use pass-by-reference when modification is the goal |\n| Naming parameters with single letters | Reader has to read the whole body to understand the function | Use meaningful names like `productId`, `quantity`, `price` |\n| Long parameter lists (six or more) | Easy to swap arguments by accident | Group related parameters into a struct (covered in the Structs section) |\n\n\nEvery one of these stems from treating the parameter list as a detail rather than as the function's public contract. Parameters are the first thing a caller reads, and often the only documentation they get.\n\n---\n\n# Summary\n\n- A parameter is a named placeholder in the function definition; an argument is the value supplied at the call site. They're matched strictly by position.\n- A function can declare zero, one, or many parameters. Each parameter has its own type and name.\n- Parameter names live inside the function body and should describe what the value represents, not its type.\n- The compiler applies implicit conversions to make arguments fit parameter types. Narrowing conversions (`double` to `int`, `long` to `int`) silently change values and are a common source of bugs.\n- Argument order matters, especially when adjacent parameters share a type. Clear names and intuitive ordering prevent most swapped-argument mistakes.\n- All examples in this lesson pass arguments by value, so the function works on a copy and the caller's variable is unchanged.\n- Adding `const` in front of a value parameter prevents the function body from reassigning it. The caller sees no difference; it's a discipline for the function's author.\n\nIn the next lesson, we'll look at the other half of a function's contract: how a function sends a value back to its caller.","pageType":"cpp"}

Function Parameters

Get Premium