What to do if you don't want a default constructor? -- Sandor Dargo
Do we need a default constructor? What does it mean to have a default constructor? What happens if we don’t have one? Those are the questions we are going after in this article.
What to do if you don't want a default constructor?
by Sandor Dargo
From the article:
A default constructor is a constructor that takes no arguments and initializes - hopefully - all the members with some default values. If you define no constructors at all, it’ll even be generated for you.
Do we need default constructors?
It really depends. Let’s first approach this question from a design point of view. Does it make sense to represent an object where the members are default initialized?
If you represent a tachograph, it probably makes sense to have such a default state where all the counters are initialized to zero.
The tachograph is the device that records driving times and rest periods as well as periods of other work and availability taken by the driver of a heavy vehicle.
On the other hand, if you represent a person or a task identifier - which inspired me to write this article - it doesn’t. A person with an empty name or a task ID with an empty ID doesn’t make much sense.
Well, that’s the case from a design point of view. What about the technical aspects? What happens if we don’t have a default constructor?
Working with the filesystem can be a daunting task, but it doesn’t have to be. In this post, I’ll walk you through some of the most common filesystem operations using the powerful features introduced in C++17, as well as some new enhancements in C++20/23. Whether you’re creating directories, copying files, or managing permissions, these examples will help you understand and efficiently utilize the 
C++17 introduced 
Concurrency is a complicated topic. Lucian Radu Teodorescu provides a simple theory of concurrency which is easy to reason about and apply.
How do you expose a C++ object to a TypeScript layer or other scripting language? Russell K. Standish demonstrates an approach using a RESTService API that is scripting-language independent.
Last time, we saw how to provide formatting for a simple user-defined class. Spencer Collyer builds on this, showing how to write a formatter for more complicated types.
The conclusion of the last post was that we need to change something in our models: maybe std::vector should use a different strategy when erasing elements; maybe types like std::tuple<int &> should not be allowed to be stored in a vector; maybe Qt should not be using memmove when erasing objects of trivially relocatable type (but it can still optimize the reallocation of a vector); maybe Qt’s definition of trivial relocability does not match ours, and we need to fix our definitions. In this post we will explore these possibilities and reach some conclusions.