Modern C++

Choosing Between Default Arguments and Overloading in C++

Decisions, decisions. Here's why overloading will keep you out of trouble.

• By Kate Gregory
• 10/24/2016

Do you provide default values for one or more arguments, or add overloads of the function that take fewer arguments? This is a design decision every C++ developer faces at some point.

There are more than 50 guidelines relating to functions (and that's not counting sections on special functions like constructors and destructors). They're all good, but I want to show you F.51: Where there is a choice, prefer default arguments over overloading.

Imagine you have a function that performs some sort of calculation with an optional "fudge factor." One way to design the class would be with two functions, like this:

double Offset(double a, double b, double ff);
double Offset(double a, double b);

This will compile happily enough and you might implement it like this:

double Reactor::Offset(double a, double b, double ff)
{
  // Insanely complicated calculations using member variables, a, b and ff
  return whatever;  
}
double Reactor::Offset(double a, double b)
{
  return Offset(a,b,1.0);
}

Anyone reading this code can see that the two-argument version of Offset is using 1.0 for the "fudge factor" and has the same logic as the three-argument version others -- because all it does is call that three-argument version. Of course, there's no requirement that one call the other -- many developers might copy-and-paste between the two versions of the functions, and "simplify" by omitting things like "multiply by 1" or "add zero" completely, making it hard to see the difference between the two functions.

To make it clear what you're doing, and to prevent developers of the future messing up your clear, intentful code by adding lines to one version of Offset but not the other, you could instead use default arguments. You only declare one function:

double Offset2(double a, double b, double ff=1.0);

In the implementation, you cannot repeat the default value of the argument. I like to leave it there as a comment, though, like this:

double Reactor::Offset2(double a, double b, double ff /* = 1.0*/)
{
  // Insanely complicated calculations using member variables, a, b, and ff
  return whatever;  
}

(This is one of my No. 1 uses of comments that start /* and end */, by the way.)

When you design your class with default argument values, there aren't two functions to copy-and-paste the same set of changes between, nor to change one of while forgetting the other. The differences are very clearly called out -- you don't have two sets of logic depending on whether there's a fudge factor or not, you just have this factor that will be 1.0 if a value isn't passed in for it.

You really can't see a difference from code that uses the class. Both Offset and Offset2 can be called with two or three parameters, like this:

Reactor r;
double d;
d = r.Offset(0.0, 2.5, 2.90);
d = r.Offset(0.0, 2.5);
d = r.Offset2(1.0, 3.5, 1.90);
d = r.Offset2(1.0, 3.5);

When it comes to finding code you need to change, never being sure if you're found all of it is a real challenge. Using default arguments reduces the number of functions you need to find, because it reduces the number of overloads. It makes sure that as time goes by, the actual logic of the two overloads with different numbers of arguments don't drift apart, intentionally or accidentally. It makes your code easier to read and maintain from day one, and expresses your intent.

It's a simple guideline to follow that saves you waffling back and forth on a small decision by giving you a simple and consistent rule, and will improve the classes you design.