intermediate

Should I Use Overloads or Default Parameters?—Jonathan Boccara

The answer is not obvious.

Should I Use Overloads or Default Parameters?

by Jonathan Boccara

From the article:

“Should I use overloads or default parameters”, haven’t you asked yourself that question?

When designing an interface where the user can leave the value of an argument up to the API, two approaches are possible:

Using a default parameters:

voiddrawPoint(int x, int y, Color color = Color::Black);
void drawPoint(int x, int y, Color color = Color::Black);

And using overloading:

void drawPoint(int x, int y); // draws a point in black
void drawPoint(int x, int y, Color color);

Which approach is cleaner? Which expresses better the intentions of the interface? Or is it just a matter of style?

This may be subjective, but I’m under the impression that overloading tends to have better popularity than default parameters amongst C++ developers. But I believe that both features have their usages, and it’s usefulto see what makes one or the other more adapted to a given situation.

In-Place Construction for std::any, std::variant and std::optional—Bartlomiej Filipek

Efficient construction.

In-Place Construction for std::any, std::variant and std::optional

by Bartlomiej Filipek

From the article:

When you read articles or reference pages for std::any, std::optional or std::variant you might notice a few helper types called in_place_* available in constructors.

Why do we need such syntax? Is this more efficient than “standard” construction?

C++17: Attributes—Marc Gregoire

Another new feature.

C++17: Attributes

by Marc Gregoire

From the article:

C++17 introduces three new code attributes:

  • [[fallthrough]]
  • [[maybe_unused]]
  • [[nodiscard]]

The first one was discussed in detail in my C++17: Fallthrough in switch statements blog post. The others are briefly explains below...

Quick Q: Accessing protected members in a derived class

Quick A: Only your own type can be accessed.

Recently on SO:

Accessing protected members in a derived class

You can only access protected members in instances of your type (or derived from your type).
You cannot access protected members of an instance of a parent or cousin type.

In your case, the Derived class can only access the b member of a Derived instance, not of a different Base instance.

Changing the constructor to take a Derived instance will also solve the problem.

Hello CMake!—Arne Mertz

Do you use it?

Hello CMake!

by Arne Mertz

From the article:

Since I have mentioned CMake in a handful of past blog posts, it is time to give a short introduction for those that don’t know it yet.

CMake is one of the most popular build systems for C++ out there. One of the main reasons probably is that it is cross-platform: It does not build the project itself but operates a platform-specific system. That means it can generate Makefiles, ninja-build files, or project files for Visual Studio or Xcode, to name just a few...

Error Handling and std::optional—Bartlomiej Filipek

Do you have a prefered way?

Error Handling and std::optional

by Bartlomiej Filipek

From the article:

In my last two posts in the C++17 STL series, I covered how to use std::optional. This wrapper type (also called “vocabulary type”) is handy when you’d like to express that something is ‘nullable’ and might be ‘empty’. For example, you can return std::nullopt to indicate that the code generated an error… but it this the best choice?

std::accumulate vs. std::reduce—Simon Brand

Old vs new.

std::accumulate vs. std::reduce

by Simon Brand

From the article:

std::accumulate has been a part of the standard library since C++98. It provides a way to fold a binary operation (such as addition) over an iterator range, resulting in a single value. std::reduce was added in C++17 and looks remarkably similar. This post will explain the difference between the two and when to use one or the other...