Articles & Books

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.

A Case for p0424 - Sane C++ Serialization -- Wojciech Szeszol

Serialization was always a problematic topic in C++. Is it going to change in the future? Check out to see how the string literals as the template parameters can help here.

A Case for p0424 - Sane C++ Serialization

By Wojciech Szeszol

From the article:

Probably every C# developer knows how versatile the Newtonsoft.Json or the standard C# serialization libraries are. The serialization with DataContract or JsonProperty is easy to write, maintain and quite efficient. When we compare it with what C++ have to offer, the latter looks very poorly. We have selection of dedicated reflection/serialization libraries [...]. Unfortunately all of them come with different sets of drawbacks: they require the serialization methods to be written manually, force usage of ugly macros, require manual registration of the structures and their fields or involve additional compilation step for the schema definitions. [...] This may change with the new C++20 standard and the introduction of the string literals as the template parameters.

Announcing “trivially relocatable”-- Arthur O’Dwyer

Do you want this?

Announcing “trivially relocatable”

by Arthur O’Dwyer

From the article:

Frequent users of Compiler Explorer, a.k.a. godbolt.org, may have noticed that a few days ago a new compiler appeared in its dropdown menu. “x86-64 clang (experimental P1144)” is a branch of Clang which I have patched to support the concept of “trivially relocatable types,” as described in my C++Now 2018 talk and as proposed for standardization in my upcoming paper P1144 “Object relocation in terms of move plus destroy” (coauthored with Mingxin Wang)...

How to Construct C++ Objects Without Making Copies--Miguel Raggi

Avoiding copies.

How to Construct C++ Objects Without Making Copies

by Miguel Raggi

From the article:

C++ references are a powerful but tricky tool: used correctly, they can improve performance with little impact on the clarity of code. But used badly, they can hide performance issues, or even send a peaceful program into the realm of undefined behaviour.

In this post, we will explore how to use the various references of C++ to minimize copies when constructing an object that holds a value, and how in some cases we can even reach zero copies.

This article assumes that you’re familiar with move semantics, lvalue, rvalue and forwarding references. If you’d like to be refreshed on the subject, you can take a look at lvalues, rvalues and their references.

Customisation points to support interfaces -- Krzysztof Ostrowski

Testable interfaces with polymorphic backends.

Customisation points to support interfaces

by Krzysztof Ostrowski

From the article:

Definition of an interface is not a trivial task. The resulting abstraction that embeds the defined interface actions does not have to be a set of virtual member functions wrapped into a class from which implementations exposed to the user derive. General guideline promoted in this article is to expose non-virtual interfaces to the user while providing a customisation point in the form of a minimal set of actions that can be combined with each other.

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?

The Incredible Const Reference That Isn’t Const--Jonathan Boccara

To be const or not?

The Incredible Const Reference That Isn’t Const

by Jonathan Boccara

From the article:

While working on the NamedType library I came across a situation that left me stunned in bewilderment: a const reference that allows modification of the object it refers to. Without a const_cast. Without a mutable. Without anything up the sleeve.

How can this be? And how to enforce the const in that const reference?