std::optional vs default argument

Question

In a discussion with a colleague regarding the use of std::optional this came up. Say we have a function that takes 2 unique pointers and the 2nd argument is optional i.e. it can be null.

It can be implemented either via using std::optional or just setting the default value of 2nd param as nullptr i.e.

#include <string>
#include <functional>
#include <iostream>
#include <optional>
#include <memory>

class A {
  // body of class  
};

class B {
  // body of class  
};

void func_with_optional(std::unique_ptr<A> aptr, 
                        std::optional<std::unique_ptr<B>> bptr = std::nullopt) {
  std::cout << "func with std::optional called\n";
}
 
void func_without_optional(std::unique_ptr<A> aptr, 
                           std::unique_ptr<B> bptr = nullptr) {
  std::cout << "func without std::optional called\n";
}

unless the second argument is class& say B& or any other type where default can't be specified say we only have one argument and that's also optional or an optional return value. I see no difference in the above two functions. The default value serves sufficiently enough without the need of std::optional.

Am I missing something here? Does the std::optional one or the default value version has more leverage over another. May be, answer lies in lines of best coding practices and not necessarily in what compiler allows or not.

What is the more generally accepted version in the industry?

Answer 1

You may start with noting that

• a std::optional may hold a value, or may be empty, and that
• a std::unique_ptr may hold ownership of an object, or may be detached (nullptr).

A std::optional<std::unique_ptr>> object would need to consider both of these, in this context without a clear purpose. A detached std::unique_ptr may just as well represent the absence of an object as compared to an optional wrapping a pointer type that may not refer to an object. Back-ported versions of std::optional to, say, a legacy C++03 (pre-move-semantics) code base would typically just implements the underlying value as a pointer that may or may not point to an object. This argument would thus favor using the func_without_optional version.

However, and this may be a wave breaker, many devs like to avoid default arguments for various reasons (concerns with pollution of the default argument into call sites, confusing API's where default arguments are used in virtual functions), and instead consider simply overloading:

void func(std::unique_ptr<A> aptr, std::unique_ptr<B> bptr) {
  // Common impl.
}

void func(std::unique_ptr<A> aptr) { func(std::move(aptr), nullptr); }

Answer 2

Differences:

1. For std::optional you need C++17. With the default parameter, you could be using C++98.

2. Lots of extra lines to compile (if you weren't including memory, string, etc and just using #include <optional> - it pulls nearly 7000 lines of code with gcc).

It is true, as @FrancoisAndrieux points out, that pointers have an inherent null value of their own, so wrapping them in an std::optional is not super-useful.

On the other hand - in a language with an optional type constructor, you don't really need null pointers. Suppose no pointer is null, i.e. all addresses are usable. This actually happens on some hardware. Then, functions can simply avoid pointer checks; and you would use a nullopt/None value to signify "no pointer" or "not pointing anywhere". See:

With std::optional standardizing, can we stop using nullptr in new code and deprecate it?

(but that's not the way things work in C++ officially, as commenters remind us.)

Answer 3

I prefer third solution: an overload with a single argument:

void func_without_defaults(std::unique_ptr<A> aptr, 
                           std::unique_ptr<B> bptr) {
  std::cout << "func without any default value\n";
}

void func_without_defaults(std::unique_ptr<A> aptr) {
  std::cout << "func with single argument\n";
  func_without_defaults(std::move(aptr), makeDefaultValueForB());
}

Quite often I see code with if checking for a default value.