I stumbled through an example from "Effective C++ in an Embedded Environment" by Scott Meyers where two ways of using default parameters were described: one which was described as costly and the other as a better option.
I am missing the explanation of why the first option might be more costly compared to the other one.
void doThat(const std::string& name = "Unnamed"); // Bad
const std::string defaultName = "Unnamed";
void doThat(const std::string& name = defaultName); // Better
In the first one, a temporary std::string is initialised from the literal "Unnamed" each time the function is called without an argument.
In the second case, the object defaultName is initialised once (per source file), and simply used on each call.
defaultName has internal linkage, I would assume the compiler to be smart enough to eliminate it altogether if it's never used by the file. –
Girl void doThat(const std::string& name = "Unnamed"); // Bad
This is "bad" in that a new std::string with the contents "Unnamed" is created every time doThat() is called.
I say "bad" and not bad because the small string optimization in every C++ compiler I've used will place the "Unnamed" data within the temporary std::string created at the call site and not allocate any storage for it. So in this specific case, there is little cost to the temporary argument. The standard does not require the small string optimization, but it is explicitly designed to permit it, and every standard library currently in use implements it.
A longer string would cause an allocation; the small string optimization works on short strings only. Allocations are expensive; if you use the rule of thumb that one allocation is 1000+ times more expensive than a usual instruction (multiple microseconds!), you won't be far off.
const std::string defaultName = "Unnamed";
void doThat(const std::string& name = defaultName); // Better
Here we create a global defaultName with the contents "Unnamed". This is created at static initialization time. There are some risks here; if doThat is called at static initialization or destruction time (before or after main runs), it could be invoked with an unconstructed defaultName or one that has already been destroyed.
On the other hand, there is no risk that a per-call memory allocation will occur here.
Now, the right solution in modern c++17 is:
void doThat(std::string_view name = "Unnamed"); // Best
which won't allocate even if the string is long; it won't even copy the string! On top of that, in 999/1000 cases this is a drop-in replacement to the old doThat API and it can even improve performance when you do pass data into doThat and not rely on the default argument.
At this point, c++17 support in the embedded may not be there, but in some cases it could be shortly. And string view is a large enough performance increase that there are a myriad of similar types already in the wild that do the same thing.
But the lesson still remains; don't do expensive operations in default arguments. And allocation can be expensive in some contexts (especially the embedded world).
doThat is called" without arguments. Right? –
Anchie () added. –
Omentum Maybe I misinterpret "costly" (for the "correct" interpretation see the other answer), but one thing to consider with default parameters is that they dont scale well in situations like that:
void foo(int x = 0);
void bar(int x = 0) { foo(x); }
This becomes an error prone nightmare once you add more nesting because the default value has to be repeated in several places (ie costly in the sense that one tiny change requires to change different places in the code). The best way to avoid that is like in your example:
const int foo_default = 0;
void foo(int x = foo_default);
void bar(int x = foo_default) { foo(x); } // no need to repeat the value here
foo_default as default for bar() (as well as for foo()) is somewhat counter intuitive (principle of least surprise etc.). foo_and_bar_default might be a better name (or one might want to consider refactoring the entire thing) –
Lactose bar() the name of foo_default doesnt really matter to the client (other than providing a hint that eventually the parameter is passed to foo). I would rather add a const int bar_default = foo_default;. Anyhow, the point of my answer still holds: using values as defaults isnt nice and this can be fixed by using OPs approach –
Catbird NO_OPTION, NOT_MOD, whatever -- and use the same variable for both. That way it's explicitly clear. It's hard to come up with a good example for this, since by definition foo and bar don't... actually do anything. It would be worth mentioning that in the prose, though. Or maybe renaming foo_default to default_value? –
Boo 0 or nullptr anyway. Just my 2ct. –
Mcdermott © 2022 - 2024 — McMap. All rights reserved.
std::stringobject for the default argument on every call. It's not needed for the "better" example. – Embouchurevoid doThat(const std::string& name = "Unnamed"s );<= Trailing 's' makes it a true string literal. – TonerdefaultNamewould also be evaluated at every call. That's not necessarily costly. The problem with the bad form is that the evaluation in that case consists of a call tostd::string::string(const char*)which includes a call tostrlen. – TonerdefaultNameis the name of a pre-created object."whatever"sis formally a function call too. – Humeralstrlenmay or may not happen, especially ifdoThatcan be inlined. godbolt.org/g/n1tpbE – Sall