{"title":"Default Arguments","description":null,"content":"A default argument is a value the compiler supplies for a parameter when the caller doesn't provide one. It lets a single function serve many call sites cleanly, so simple cases stay short and full-control cases still work. This lesson covers the syntax, the right-to-left rule, where defaults belong (declaration vs definition), how call resolution picks them, the ambiguities that can show up when defaults meet overloading, and when to pick defaults over overloads.\n\n---\n\n# Why Default Arguments Exist\n\nFunctions often have a \"usual\" value for one or more parameters. Currency is almost always USD. Discount percent for a flash sale is almost always 10. Whether an order is expedited is almost always `false`. Without defaults, every caller has to spell out every argument, or a pile of overloads all forward to the same underlying logic.\n\nThe problem without defaults. Consider a function that formats a price for display.\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nstd::string formatPrice(double value, std::string currency, int decimals) {\n std::ostringstream out;\n out << currency << \" \" << std::fixed << std::setprecision(decimals) << value;\n return out.str();\n}\n\nint main() {\n std::cout << formatPrice(19.99, \"USD\", 2) << std::endl;\n std::cout << formatPrice(2499.5, \"USD\", 2) << std::endl;\n std::cout << formatPrice(0.5, \"USD\", 2) << std::endl;\n return 0;\n}\n```\n\n\nEvery call repeats `\"USD\"` and `2`. The call sites read worse than they should. The information that matters (the price) is buried at the start of a longer argument list. With defaults, the same function can be called three ways: with just the price, with a different currency, or with a different precision.\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nstd::string formatPrice(double value, std::string currency = \"USD\", int decimals = 2) {\n std::ostringstream out;\n out << currency << \" \" << std::fixed << std::setprecision(decimals) << value;\n return out.str();\n}\n\nint main() {\n std::cout << formatPrice(19.99) << std::endl;\n std::cout << formatPrice(19.99, \"EUR\") << std::endl;\n std::cout << formatPrice(19.99, \"JPY\", 0) << std::endl;\n return 0;\n}\n```\n\n\nSame function, three different call shapes. The common case is short. The full-control case is still available. That's the reason default arguments exist.\n\n---\n\n# Basic Syntax\n\nA default argument is written with `=` after the parameter declaration, inside the parameter list.\n\n\n```cpp\nvoid applyDiscount(double price, double percent = 10.0);\n```\n\n\nThe function `applyDiscount` takes two parameters. `price` has no default, so every caller must supply it. `percent` has a default of `10.0`, so callers can omit it.\n\nA complete example:\n\n\n```cpp\n#include \n\nvoid applyDiscount(double price, double percent = 10.0) {\n double discount = price * (percent / 100.0);\n double finalPrice = price - discount;\n std::cout << \"Original: $\" << price\n << \", Discount: \" << percent << \"%\"\n << \", Final: $\" << finalPrice << std::endl;\n}\n\nint main() {\n applyDiscount(50.0);\n applyDiscount(50.0, 25.0);\n return 0;\n}\n```\n\n\nThe first call passes only the price, so `percent` takes the default value `10.0`. The second call passes both, so the default is ignored. The function body has no idea which case it's in; the compiler patches the missing argument at the call site, not inside the function.\n\nThe default expression can be a literal (`10.0`, `\"USD\"`, `false`), a `const` variable visible at the call site, or a function call whose result the compiler uses as the argument. The most common case by far is a plain literal.\n\n---\n\n# The Right-to-Left Rule\n\nOnce a parameter has a default value, every parameter to its right must also have a default. The rule exists because of how the compiler matches arguments to parameters: positionally, left to right. If a parameter in the middle had a default but the one after it didn't, the compiler couldn't tell which argument the caller meant to skip.\n\nThis is fine:\n\n\n```cpp\nvoid placeOrder(int customerId, bool expedited = false);\nvoid formatPrice(double value, std::string currency = \"USD\", int decimals = 2);\nvoid createUser(std::string name, std::string email, bool isPremium = false);\n```\n\n\nThis is not:\n\n\n```cpp\n// Error: 'expedited' has a default but 'customerId' does not, and 'customerId' is to its right\nvoid placeOrder(bool expedited = false, int customerId);\n```\n\n\n`g++` rejects this with:\n\n\n```shell\nerror: default argument missing for parameter 2 of 'void placeOrder(bool, int)'\n```\n\n\nThe compiler doesn't say \"the order is wrong.\" It says the parameter after the defaulted one is missing a default, because that's literally the rule it's checking.\n\nA slightly subtler example. Consider a function that creates a new product entry with a name, a price, an optional category, and an optional stock count. Giving `category` a default but leaving `stockCount` without one produces an invalid declaration.\n\n\n```cpp\n// Invalid\nvoid addProduct(std::string name, double price, std::string category = \"General\", int stockCount);\n```\n\n\n`g++` reports the same error: parameter 4 is missing a default. The fix is to either give `stockCount` a default too, or remove the default from `category` and force every caller to supply both.\n\n\n```cpp\n// Valid: defaults flow to the right\nvoid addProduct(std::string name, double price, std::string category = \"General\", int stockCount = 0);\n```\n\n\nEvery caller must supply `name` and `price`. They can stop there, or add `category`, or add both `category` and `stockCount`. They cannot skip `category` and provide `stockCount`, because there's no way to write that call in C++.\n\n---\n\n# Where Defaults Go: Declaration vs Definition\n\nThis is the rule that causes the most confusion. **Defaults belong in the declaration (the prototype, usually in a header file), not in the definition (the body, usually in a `.cpp` file).** Putting them in both is an error in most setups, and putting them only in the definition means they're invisible to callers who only see the declaration.\n\nA clean two-file setup:\n\n\n```cpp\n// discount.h\n#ifndef DISCOUNT_H\n#define DISCOUNT_H\n\nvoid applyDiscount(double price, double percent = 10.0);\n\n#endif\n```\n\n\n\n```cpp\n// discount.cpp\n#include \"discount.h\"\n#include \n\nvoid applyDiscount(double price, double percent) {\n double discount = price * (percent / 100.0);\n std::cout << \"Final: $\" << (price - discount) << std::endl;\n}\n```\n\n\nThe default `= 10.0` appears in the header, where every caller can see it. The `.cpp` file defines the function. Callers `#include \"discount.h\"` and inherit the default.\n\nWriting the default in both places makes `g++` complain:\n\n\n```cpp\n// discount.h\nvoid applyDiscount(double price, double percent = 10.0);\n\n// discount.cpp\nvoid applyDiscount(double price, double percent = 10.0) { /* ... */ }\n```\n\n\n\n```shell\nerror: default argument given for parameter 2 of 'void applyDiscount(double, double)'\nnote: previous specification in 'void applyDiscount(double, double)' here\n```\n\n\nThe standard says a default argument can be specified only once per translation unit for a given parameter. If the header is `#include`d in the `.cpp` file (which it usually is), the default appears twice and the compiler rejects it.\n\nThe opposite mistake: default only in the definition.\n\n\n```cpp\n// discount.h\nvoid applyDiscount(double price, double percent);\n\n// discount.cpp\nvoid applyDiscount(double price, double percent = 10.0) { /* ... */ }\n```\n\n\nThis compiles, but it doesn't do the right thing. The default is only visible to code in `discount.cpp` (and to any file that happens to `#include` the `.cpp` file, which no one should ever do). Every other caller sees the declaration in the header, which has no default, so they're forced to supply both arguments. The default exists but is useless.\n\n**Rule of thumb:** Default arguments live in the header. The definition repeats the parameter list without the `=` part.\n\nIn a single-file program (everything in `main.cpp`), the default can go on either the forward declaration or the definition, as long as it appears in only one place.\n\n\n```cpp\n#include \n\n// Forward declaration with default\nvoid applyDiscount(double price, double percent = 10.0);\n\nint main() {\n applyDiscount(50.0);\n return 0;\n}\n\n// Definition without the default\nvoid applyDiscount(double price, double percent) {\n std::cout << \"Final: $\" << (price - (price * percent / 100.0)) << std::endl;\n}\n```\n\n\nWhen there's no separate forward declaration and only the definition exists, that definition is also the declaration, and the default goes on it:\n\n\n```cpp\n#include \n\nvoid applyDiscount(double price, double percent = 10.0) {\n std::cout << \"Final: $\" << (price - (price * percent / 100.0)) << std::endl;\n}\n\nint main() {\n applyDiscount(50.0);\n return 0;\n}\n```\n\n\nThat works too. The point: **the default appears exactly once, in whichever declaration the caller can see.**\n\n---\n\n# How Call Resolution Picks Defaults\n\nArgument matching is strictly positional. The compiler lines up arguments from left to right against parameters. When the caller runs out of arguments before the parameter list ends, the compiler fills the rest from the defaults, again left to right.\n\nConsider this function:\n\n\n```cpp\nvoid createUser(std::string name, std::string email, bool isPremium = false);\n```\n\n\nThe valid call shapes are:\n\n\n```cpp\ncreateUser(\"Alice\", \"alice@example.com\"); // isPremium = false (default)\ncreateUser(\"Alice\", \"alice@example.com\", true); // isPremium = true (explicit)\n```\n\n\nThe compiler cannot skip a middle parameter to reach a later one:\n\n\n```cpp\ncreateUser(\"Alice\", true); // Error: tries to pass `true` as email\n```\n\n\n`g++` says:\n\n\n```shell\nerror: invalid conversion from 'bool' to 'std::string'\n```\n\n\nThe compiler matched arguments left to right: `\"Alice\"` went to `name`, then `true` was matched against `email`, which is a `std::string`. There's no way to say \"skip the email and use its default.\" C++ has no named-argument syntax. The defaults only fill in at the end of the list.\n\nThe same idea with `formatPrice`:\n\n\n```cpp\nstd::string formatPrice(double value, std::string currency = \"USD\", int decimals = 2);\n\nformatPrice(19.99); // currency = \"USD\", decimals = 2\nformatPrice(19.99, \"EUR\"); // currency = \"EUR\", decimals = 2\nformatPrice(19.99, \"EUR\", 3); // currency = \"EUR\", decimals = 3\nformatPrice(19.99, 3); // Error: 3 is matched against `currency`, which is a string\n```\n\n\nThe last line fails for the same reason. Defaults are not labeled. They just fill from the right end of the parameter list as far as needed.\n\n\n```mermaid\nflowchart LR\n A[Caller writes
formatPrice 19.99]:::cyan --> B[Compiler matches
left to right]:::orange\n B --> C[value gets 19.99]:::teal\n C --> D{More arguments?}:::green\n D -- No --> E[Fill rest from
defaults]:::orange\n E --> F[currency = USD
decimals = 2]:::teal\n F --> G[Call function]:::cyan\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe flow is one-directional. Once the compiler stops pulling arguments from the call site, every remaining parameter is filled from its default, in order.\n\n---\n\n# What Can Be a Default Value\n\nThe default expression can be any expression that's valid at the point where the default is declared and produces a value compatible with the parameter type. The most common cases are literals.\n\n\n```cpp\nvoid applyDiscount(double price, double percent = 10.0); // literal\nvoid createUser(std::string name, bool isPremium = false); // literal\nvoid formatPrice(double value, std::string currency = \"USD\"); // literal\n```\n\n\nA `const` variable or `constexpr` value visible at the call site also works.\n\n\n```cpp\n#include \n#include \n\nconst std::string DEFAULT_CURRENCY = \"USD\";\nconstexpr double DEFAULT_DISCOUNT = 10.0;\n\nvoid formatPrice(double value, std::string currency = DEFAULT_CURRENCY);\nvoid applyDiscount(double price, double percent = DEFAULT_DISCOUNT);\n\nint main() {\n formatPrice(19.99);\n applyDiscount(50.0);\n return 0;\n}\n\nvoid formatPrice(double value, std::string currency) {\n std::cout << currency << \" \" << value << std::endl;\n}\n\nvoid applyDiscount(double price, double percent) {\n std::cout << \"Final: $\" << (price - price * percent / 100.0) << std::endl;\n}\n```\n\n\nA function call also works as a default. The function is invoked once per call where the default is used, not once when the program starts.\n\n\n```cpp\n#include \n#include \n\nint currentTimestamp() {\n return static_cast(std::time(nullptr));\n}\n\nvoid logEvent(std::string message, int timestamp = currentTimestamp());\n\nint main() {\n logEvent(\"Order placed\");\n return 0;\n}\n\nvoid logEvent(std::string message, int timestamp) {\n std::cout << \"[\" << timestamp << \"] \" << message << std::endl;\n}\n```\n\n\nEvery call to `logEvent` without a timestamp invokes `currentTimestamp()` fresh, so each call gets the current time at the moment of the call. This is sometimes useful, but it can surprise readers who expected the default to be a static value.\n\n---\n\n# Defaults Cannot Refer to Earlier Parameters\n\nThis rule confuses developers coming from languages like Python. In C++, a default value cannot reference another parameter of the same function. The default is evaluated at the call site, before the function is called, when the other parameters don't have values yet.\n\n\n```cpp\n// Error: 'price' is not known when the default for 'tax' is evaluated\nvoid chargeOrder(double price, double tax = price * 0.08);\n```\n\n\n`g++` rejects this with:\n\n\n```shell\nerror: local variable 'price' may not appear in this context\n```\n\n\nThe default for `tax` is computed at the call site, before `chargeOrder` is called. At that moment, `price` is the name of a parameter that doesn't exist yet (the function call hasn't started). The compiler enforces this with a hard rule: defaults can only see names that are visible in the surrounding scope, not the function's own parameters.\n\nFor a default that depends on another argument, do it inside the function body:\n\n\n```cpp\n#include \n#include \n#include \n\nvoid chargeOrder(double price, double tax = std::numeric_limits::quiet_NaN()) {\n if (std::isnan(tax)) {\n tax = price * 0.08;\n }\n std::cout << \"Total: $\" << (price + tax) << std::endl;\n}\n\nint main() {\n chargeOrder(100.0);\n chargeOrder(100.0, 15.0);\n return 0;\n}\n```\n\n\nThat's the pattern: use a sentinel (`NaN`, `-1`, an empty string, depending on what's available) as the default, then compute the real value inside the body after detecting the sentinel. It's clunkier than the original would have been, but it's the C++ way of expressing \"default depends on another argument.\"\n\nA cleaner alternative is a wrapper function that supplies the dependent default and forwards to the main function:\n\n\n```cpp\nvoid chargeOrder(double price, double tax); // main function\n\ninline void chargeOrder(double price) { // wrapper\n chargeOrder(price, price * 0.08);\n}\n```\n\n\nThat's two functions sharing a name (function overloading). The wrapper computes the tax from the price and forwards. No sentinel needed, no in-body check. Most C++ codebases pick this style when the dependency is real.\n\n---\n\n# Interaction with Function Overloading\n\nFunction overloading allows multiple functions with the same name but different parameter lists. Defaults and overloading can both produce the same effect (a function callable with different argument counts), and putting them together can create ambiguity the compiler can't resolve.\n\nAn ambiguous case:\n\n\n```cpp\n#include \n\nvoid placeOrder(int customerId) {\n std::cout << \"Standard order for customer \" << customerId << std::endl;\n}\n\nvoid placeOrder(int customerId, bool expedited = false) {\n std::cout << \"Order for customer \" << customerId\n << (expedited ? \" (expedited)\" : \" (standard)\") << std::endl;\n}\n\nint main() {\n placeOrder(101); // ambiguous: matches both\n return 0;\n}\n```\n\n\n`g++` rejects the call:\n\n\n```shell\nerror: call of overloaded 'placeOrder(int)' is ambiguous\nnote: candidate: 'void placeOrder(int)'\nnote: candidate: 'void placeOrder(int, bool)'\n```\n\n\nBoth functions are valid candidates. The first takes one `int`. The second takes one `int` and uses the default for the second parameter. The compiler has no rule to prefer one over the other, so the call is rejected. The fix is to pick one design, not both.\n\n**Fix 1: drop the overload, keep the default.**\n\n\n```cpp\nvoid placeOrder(int customerId, bool expedited = false);\n```\n\n\nOne function, one call site shape (`placeOrder(101)` and `placeOrder(101, true)` both work). This is usually the cleanest answer.\n\n**Fix 2: drop the default, use two overloads.**\n\n\n```cpp\nvoid placeOrder(int customerId); // standard only\nvoid placeOrder(int customerId, bool expedited); // explicit choice\n```\n\n\nNow the compiler can pick exactly one based on the argument count, and there's no overlap.\n\nThe general guidance: **don't mix overloading and defaults on the same parameter position.** Doing so makes ambiguity likely. Pick one tool per slot.\n\nAnother flavor of the same problem, with different types:\n\n\n```cpp\nvoid notifyCustomer(int customerId);\nvoid notifyCustomer(int customerId, std::string channel = \"email\");\n\nnotifyCustomer(101); // ambiguous again\n```\n\n\nSame story, same fix. Either remove the default or remove the overload.\n\n---\n\n# Defaults vs Overloading: When to Pick Which\n\nBoth tools offer multiple call shapes for the same operation. They are not interchangeable. The trade-offs matter.\n\n\n| Use default arguments when... | Use overloading when... |\n|---|---|\n| All call shapes do the same thing, just with different values for some parameters | The behavior is different for different parameter combinations |\n| The parameters have the same types in all call shapes | Different types must be accepted (e.g., `int` and `std::string`) |\n| A single function in the binary is preferable | Each version should compile separately, possibly with different optimizations |\n| The default value is a constant | The \"default\" depends on other arguments or needs setup logic |\n\n\nA concrete example. Consider a `printReceipt` function. If all variations print the same data with different formatting options (currency symbol, decimal places, line width), defaults are a good fit. The behavior is the same; only formatting parameters change.\n\n\n```cpp\nvoid printReceipt(const std::vector& prices,\n std::string currency = \"USD\",\n int decimals = 2,\n int lineWidth = 40);\n```\n\n\nIf instead receipts need to print from completely different inputs (one takes a vector of prices, another takes a single struct, another takes a database cursor), overloading is right. Same name, different input shapes, different bodies.\n\n\n```cpp\nvoid printReceipt(const std::vector& prices);\nvoid printReceipt(const Order& order);\nvoid printReceipt(DatabaseCursor& cursor);\n```\n\n\nThe two are mixed up most often when a developer wants \"the convenience of optional arguments\" and uses overloading by reflex. If the bodies are nearly identical, defaults are cleaner.\n\nA real cost worth knowing: with defaults, the default expression is compiled into every call site that uses it, not stored once in the function. That doesn't matter for simple literals, but it can matter for function-call defaults that get inlined repeatedly.\n\nA function-call default like `int x = expensive()` runs `expensive()` once per call that omits `x`. If `expensive()` is non-trivial and the function is called from many places, the default expression is duplicated at every call site. For pure constants this is free; for function calls, prefer an explicit overload that does the work once.\n\n---\n\n# A Larger E-Commerce Example\n\nA small order-management snippet that uses defaults for a few different parameter types: `bool`, `double`, `std::string`, and `int`.\n\n\n```cpp\n#include \n#include \n#include \n\nvoid placeOrder(int customerId,\n double total,\n std::string currency = \"USD\",\n bool expedited = false,\n int loyaltyPointsMultiplier = 1) {\n double shippingCost = expedited ? 19.99 : 4.99;\n int pointsEarned = static_cast(total) * loyaltyPointsMultiplier;\n\n std::cout << std::fixed << std::setprecision(2);\n std::cout << \"Order for customer \" << customerId << std::endl;\n std::cout << \" Total: \" << currency << \" \" << total << std::endl;\n std::cout << \" Shipping: \" << currency << \" \" << shippingCost\n << (expedited ? \" (expedited)\" : \" (standard)\") << std::endl;\n std::cout << \" Points: \" << pointsEarned << std::endl;\n std::cout << std::endl;\n}\n\nint main() {\n placeOrder(101, 49.99);\n placeOrder(102, 89.50, \"EUR\");\n placeOrder(103, 120.00, \"USD\", true);\n placeOrder(104, 200.00, \"USD\", true, 3);\n return 0;\n}\n```\n\n\nFour calls, four different argument counts, one function. Customer 101 takes everything by default. Customer 102 overrides only the currency. Customer 103 adds expedited shipping. Customer 104 also gets a triple loyalty multiplier.\n\nParameter order matters. `currency` is the third parameter, `expedited` is the fourth, `loyaltyPointsMultiplier` is the fifth. A caller who wants only `expedited = true` still has to supply `currency`, because there's no way to skip a parameter. That's why the most-commonly-changed optional parameters should appear leftmost in the optional section, and the rarely-changed ones rightmost.\n\nA common ordering rule when designing a function:\n\n1. Required parameters first (no defaults).\n2. Optional parameters in order from most-commonly-overridden to least.\n3. Group related options together (e.g., all formatting options after all behavior options).\n\nFrequent need to skip a middle parameter is a sign the parameter order needs work, or that the function should be split into multiple overloads.\n\n---\n\n# Defaults in Headers: A Subtle Pitfall\n\nWhen defaults live in a header, every translation unit that includes the header sees those defaults. Changing a default value requires recompiling every file that includes the header to pick up the new default. The compiler bakes the default into the call site of every caller.\n\n\n```cpp\n// shipping.h\nvoid calculateShipping(double weight, double rate = 2.0);\n```\n\n\nChanging the default to `3.0` means every `.cpp` file that includes `shipping.h` and calls `calculateShipping(weight)` (without a second argument) will, after recompilation, compute the shipping at the new rate. Files that aren't recompiled still use the old default. This is a real source of bugs in larger projects when build systems don't track header dependencies correctly.\n\nChanging a default argument is an interface change. Every translation unit that includes the header must be rebuilt to see the new value. A precompiled library that ships to callers compiled against the old header keeps using the old default until those callers rebuild.\n\nFor library APIs, this is a reason to be conservative about defaults. A default value becomes part of the API contract, and changing it can change caller behavior without warning. If a parameter's \"right\" value is likely to change over time, consider making it required or providing a separate \"configuration\" mechanism.\n\nFor application code where the header and every caller are controlled together, defaults are fine to evolve as the code evolves.\n\n---\n\n# Common Mistakes\n\nA short tour of the mistakes that show up most often when working with defaults.\n\n**Mistake 1: Default in both declaration and definition.**\n\n\n```cpp\n// header.h\nvoid f(int x = 5);\n\n// header.cpp\nvoid f(int x = 5) { /* ... */ }\n```\n\n\n`g++` reports `default argument given for parameter ... here` with a note pointing to the previous specification. The fix is to keep the default only in the header.\n\n**Mistake 2: Skipping the rightmost parameter when an earlier one has a default.**\n\n\n```cpp\nvoid f(int a = 1, int b); // error: 'b' missing default\n```\n\n\nOnce `a` has a default, `b` (to its right) must also have one. Move the default to `b` instead, or give both parameters defaults.\n\n**Mistake 3: Trying to skip a middle argument.**\n\n\n```cpp\nvoid f(int a, std::string s = \"x\", bool b = false);\n\nf(1, true); // 'true' is matched against 's', which is a string\n```\n\n\nThere's no way to write \"use the default for `s` but supply `b`.\" The compiler walks left to right and stops when the call's argument list ends. Overriding only `b` requires supplying `s` as well.\n\n**Mistake 4: Expecting a default to depend on another parameter.**\n\n\n```cpp\nvoid f(double price, double tax = price * 0.08); // error: 'price' isn't visible here\n```\n\n\nC++ defaults can't see the function's other parameters. Use a sentinel inside the body, or define an overload that computes the dependent value and forwards.\n\n**Mistake 5: Mixing defaults and overloading on the same call shape.**\n\n\n```cpp\nvoid f(int x);\nvoid f(int x, int y = 0);\n\nf(5); // ambiguous\n```\n\n\nBoth overloads can accept `f(5)`. Pick one strategy per call shape.\n\n---\n\n# When to Use Defaults\n\nA short checklist for deciding whether a default argument is the right tool:\n\n1. **Is there a single \"obvious\" value for this parameter most of the time?** If yes, a default fits.\n2. **Do all call shapes do the same logical operation?** If yes, defaults are cleaner than overloads.\n3. **Does the default value depend on another argument?** If yes, prefer an overload or a sentinel pattern.\n4. **Is the default likely to change over the life of the codebase?** If yes, think hard before using a default in a public header. A required parameter or a configuration object may be safer.\n5. **Is the alternative to add an overload that does the same thing with one fewer parameter?** A default does that job with less code.\n\nFor internal application code, defaults are a small, low-cost convenience. For library APIs, treat them as part of the contract and choose them deliberately. Either way, when defaults and overloads start to overlap on the same call shape, the design has gone too far in one direction. Step back and pick one.","pageType":"cpp"}

Default Arguments

Get Premium