DEV Community: Sandor Dargo

My way to get into conferences

Sandor Dargo — Wed, 28 Jun 2023 06:15:59 +0000

In this article, I'll share with you my journey to become a "regular" conference speaker. I'll also explain what regular means in my case. Don't expect any magic from the article, I cannot offer you anything that would work in the short term. It took me years to get where I am, but I'm sure that if getting into conferences is a major goal for you, you can achieve it faster.

Going to or speaking at conferences?

A few years ago, after having completed most of the internal trainings at my job, I started to see conferences both as a perk and a replacement for regular trainings. I thought that conferences are a great way to learn about trends, technologies, and methodologies. I wanted to go to conferences and not only to smaller local events. One of my former bosses who could go to CppCon told me that he'd help me if I asked for his help. So did I.

His boss also helped me.

I remember that a Friday afternoon my senior manager rushed to my desk really excited saying there are very few people who could go that year due to budget cuts, but I'll be one of them. Expect the mail! The mail arrived and I didn't understand it.

We were talking about a week in Colorado, but the mail was about a one-day conference in Paris. Was it in addition? Was it by mistake?

No. It was a budget cut.

There were two outcomes of it:

I had a great time at CPPP, where my trip report was among the two best ones according to the organizers.
I understood something I had been already suspecting. If I wanted to go to a conference without paying for it, I rather go as a speaker. So I doubled down on my efforts.

How to prove that you're ready to speak?

I had two problems at that point. I had no credibility as a speaker and in addition, I had nothing to speak about.

Not an optimal situation when you want to speak at conferences.

In this section, I'll delve into the first problem. A bit earlier, in 2017, I attended my first IT conference, RivieraDev. Each year, RivieraDev has a special track called "we are not just coders". On this track, you'll find presentations both by non-dev people (usually there are 1-2 gastronomic ones) and non-IT-related presentations by developers. You might learn about multi-day hikes with very light backpacks or about lockpicking.

There I realized that you don't have to be "special" to talk at a conference.

This track gives you a nice opportunity to speak at a conference and get some real-life experience. The next time you apply, you can mention that as a previous experience at a conference. Even though many conferences specifically mention that they welcome new speakers, experience doesn't hurt.

I only needed some compelling topics. So I spoke about things that not everyone does (well) and something I had been passionate about.

In my first year, I spoke about how to organize your holidays. The second year I spoke about sourdough baking where I also brought some freshly baked bread and pastries.

I had some speaking engagements that I could mention in my applications and I definitely proved to myself that I was ready.

At that point, I needed good topics.

What makes a good topic?

I think we can agree that holiday organisation and sourdough baking are interesting and fun, but probably not the topics you'd call compelling at a developer conference.

Ideally, you should find a topic that meets 3 requirements:

would be accepted by the organizers / attendees
something you will be able to present
something that interests you

The first requirement is obvious. If the organizers wouldn't accept it, if nobody would come to your talk, then you have no talk.

At the same time, an accepted submission is worth nothing if you won't be able to present at the conference. It will even ruin your credibility. Mind the future tense. I don't think you have to be able to present a topic at the moment of submission.

I don't mean that you don't have the slides ready. Of course, you don't. I mean that you know close to nothing about a topic. In my opinion, it's not a problem. At the moment, you only have to know enough to write a compelling abstract and outline. By being able to do so, you probably understand if that topic isn't too complex for the current you.

I knew close to nothing about undefined behaviour when I submitted a proposal in 2020. I also knew that I shouldn't submit anything about SFINAE because I was (and am) clearly not there yet to talk about it. To meet this criteria you need some humility.

You might think that I'm crazy, but this is an extremely motivating way to learn about a topic. As such I have a very hard deadline to finish my research, I have a reason that kicks me out of bed every single morning earlier than the rest of my family.

It's not enough that you have a topic you will be able to speak about and that it would be acceptable to the organizers. That topic must be interesting for you. You'll have to prepare a lot. Maybe a little bit every day. You'll have to speak about it to others and most probably not only during your talk but during coffee breaks, at breakfast, at the pub, etc. Talk about something that you like, something that you find interesting. It'll be better for you and for the attendees too.

How to know what the organizers want?

The second and third criteria are only up to you. But what about the first one? How could you know what the programme committee would like?

"I cannot read others' minds!" - you might object. That's right, but you can do your homework!

You can read the programs of earlier years and of other similar conferences. You can study what were topics that got accepted, what were popular topics and what topics people barely spoke about. You can more or less understand which conferences like to have some talks on softer topics such as clean code, and where that most probably wouldn't be accepted. You might also identify certain patterns for abstracts that people use.

You have to accept that especially as a fresh speaker you'll have to face lots of rejections. That's fine. Maybe you won't even get into any conference the first year. That's fine. However, there is a fair chance that you'll be invited to program committees where you'll have the chance to review other submissions. That's a great opportunity to learn about trending topics and the quality of submitted proposals.

Remember, when you get into a program committee, don't only review others' topics, but also analyze them! What do they want to talk about? How deep, how well structured their abstracts are? What kind of comments do they get from other reviewers? Take some notes and compare them later with the line-ups to understand where the bar is and draw your conclusions for the next year.

On certain evaluation platforms, you'll get feedback. Take them into account. Maybe you can improve your submission for next year.

If you really care about the learning opportunity, find user groups or local events that would give you an opportunity to present your ideas. You'll learn a lot, you might engage in deep technical discussions with experts and you can improve your content so that next year you might come back with an enhanced proposal that has higher chances to get accepted.

But does this actually work?

For me, it worked and I'm more than grateful both to the organizers and my employers for the several opportunities they granted me. I have to mention my employers too because while it's often difficult to get money to travel and to buy a conference ticket, it's much easier to convince your bosses to give you the time to speak at a conference.

In the beginning, I applied for almost anything locally. I wanted to get experience and build up credibility. As I mentioned I talked about sourdough baking and travel organization at RivieraDev. My first breakthrough was in 2019 when I got the chance to talk at an international conference 200 km away from my home, at DevOps D-Day in Marseille, I talked about Coding guidelines and decision fatigue. An important topic to me.

2020 was a big shock for most of us. I got accepted for C++ On Sea, the first time for a C++ conference. No, that's what shocked most of us. It was that Covid came, restrictions came and I stayed home. Nevertheless, the conference was held online and it still was a big experience.

In the coming one and a half years, I spoke at several online events, at CPPP, MeetingC++, CppNow, CppCon... I presented probably about 4 different topics. And in 2022, finally I got to an in-person C++ Conference, C++ On Sea 2022 and this year (in 2023) once again I can go to C++ On Sea.

Thanks to the restrictions I had several opportunities. I needed less time and no travel budget. Since most conferences are luckily in-person once again, I apply for less. But that's another story. My point is that what I explained above really worked for me and I'm sure that if that's what you're looking for you can use the above pieces of advice.

Conclusion

In this article, I covered one way that can help you get closer not only to attend but to speak at conferences. In my opinion, this is way better than just attending, because often (most of) your costs will be covered, you'll learn way more and build more connections. Not to mention that it's easier to convince your boss to let you speak at a conference than to buy you a ticket.

If you start from zero, make sure that you practice enough and that you build up some credibility by speaking at smaller events. Even if you give some non-technical talks. Once you're confident and you have some experience, start applying for bigger events with more technical talks. Grab all the opportunities to study successful proposals and use the findings to make yours better.

Once you got accepted, make sure that you prepare well and you live up to the expectations and you don't waste your time. But that's another story.

Good luck!

Connect deeper

If you liked this article, please

hit on the like button,
subscribe to my newsletter
and let's connect on Twitter!

The 3 best books to level up your C++

Sandor Dargo — Wed, 21 Jun 2023 07:58:10 +0000

In this article, I'll present you 3 books that can level up your C++. For this article, I'm assuming that you have little or medium experience with C++ and you're looking for ways to reach the next level.

Reading blogs is also a good way to enhance your knowledge and keep up with the news. Here is my curated list of C++ blogs. There are many ways and you should not stick only to one type of source.

In this article, I'm focusing on books. On books that will help you reach the next level. With the level of knowledge I assume you have, you should be familiar with the language and library basics, maybe a little bit more. You should be able to use them with confidence and probably understand how they work, and some of their internals.

With the below 3 books, you'd learn the ins and outs of several C++ best practices, you'd learn a lot about templates to make them less dreadful and of course, one must get comfortable with architecture if he/she wants to make some career progression.

I'm not going to share full reviews of these 3 books, but you'll get the main idea behind them and a link to my full reviews on them.

Beautiful C++ by J. Guy Davidson and Kate Gregory

Beautiful C++: 30 Core Guidelines for Writing Clean, Safe and Fast Code by J. Guy Davidson and Kate Gregory is the book to read if you want to learn how to write more readable and therefore more maintainable C++ code. In it, you’ll find 30 handpicked guidelines from the Core Guidelines.

The authors explain each of those guidelines in detail. By reading the book, you will understand how and why you should apply them. While it doesn't cover all the guidelines (that would be a really long book!), it introduces the Core Guidelines to you and probably you'll open it up from time to time to see what is in there.

Among others, by reading this book you'll learn why it's sane to avoid trivial getter and setters, why you should specify concepts or why you should opt for immutable data.

You'll also learn how to write more beautiful and more maintainable code than most of your fellow developers.

C++ Software Design by Klaus Iglberger

C++ Software Design by Klaus Iglberger is a great book that every non-beginner C++ developer should read in order to level-up their knowledge. Reading this book, you'll learn about the most useful design patterns in C++. More than that, you'll not only learn about their classical implementation, which is usually based on dynamic polymorphism, but you'll also learn about modern implementation approaches. The latter ones are usually value-based and let the compiler do most of the work, instead of the run-time. You also get comparisons, pros and cons so that you can choose in your real-life projects, which implementations you should consider.

If you ever wanted to understand (better) the strategy/policy or the visitor patterns, if you ever wondered what type erasure is or if you wanted to understand why there are so many debates about the singleton pattern, you should read this great book from Klaus Iglberger.

Template Metaprogramming with C++ by Marius Bancila

Templates can be intimidating. Even though every C++ developer is using them at least through standard library types, more elaborated usages can be seen difficult. In fact, they are. SFINAE is not easy to grasp and if you talk to developers who haven't kept up that much with the evolution of C++, they will strengthen this feeling in you.

But if you understand the basics well and use modern language features, such as if constexpr or concepts, templates become much easier. Template Metaprogramming with C++ by Marius Bancila provides you with exactly that.

It has a clear structure and builds from the simple to the complex. It starts with the basics of templates, not forgetting about the terminology, history, and why you’d use templates in the first place. In the second part, it moves to advanced template concepts. It details how overload resolution works with templates, how to use forwarding/universal references, what is CTAD, and how to use decltype and std::declval. It also covers the already mentioned SFINAE and how to replace them with modern techniques.

In the third and final part, Marius Bancila details several design and implementation patterns that are using templates. The Curiously Recurring Template Pattern, mixins, and type erasure are well explained with lots of code examples. The book also gives a nice introduction to the ranges library.

Conclusion

In this article, you could learn about 3 great books that will help you reach the next levels in C++. With Beautiful C++, you'll learn how to write more beautiful and more maintainable code than most of your fellow developers. C++ Software Design by Klaus Iglberger will teach you about the most important design patterns in C++ and how their pointer and value-based implementations compare against each other. Last, but not least, by reading Template Metaprogramming by Marius Bancila, you'll learn the most important details of how to deal with templates, including modern features such as concepts.

Connect deeper

If you liked this article, please

hit on the like button,
subscribe to my newsletter
and let's connect on Twitter!

Fold expressions in C++

Sandor Dargo — Wed, 14 Jun 2023 18:02:07 +0000

In this article, we are going to talk about time expressions. First, we are going to take some time to define what they are in case you're not familiar with them. We'll do this using C++ syntax, but we must keep in time that the concept is not exclusive to our favourite language.

Then we are going to see what the standard library offers us in terms of algorithms and we'll also see how they evolved so far since they were introduced in C++17 and what new functions we are going to get with C++23.

What are fold expressions?

When you have several values of the same type and you'd like to apply a binary function to each of these values and produce one single result then you essentially want to fold or reduce them. When you sum up several values and return the result, then you use might use a fold expression.

Using a fold expression lets you not use an ugly loop, it gives you a concise way to perform any binary operation and give back a single result.

We differentiate between left and right fold operations depending on from which direction we apply the operation.

When we start from the left, we talk about left folding and when we start from the right, we talk about right folding.

Using the example of summing up 5 numbers, let's represent the difference between left and right folding.

operator+ 1 2 3 4
// equivalent to left folding
(((1 + 2) + 3) + 4)
// equivalent to right folding
(1 + (2 + (3 + 4)))

While the direction doesn't matter if an operation is associative, in other cases, it's important, such as for division.

A fold expression can be also called parameter pack expansion.

The syntax in C++

There are two ways to approach fold expressions in C++. The first is through the syntax supporting writing fold expression and we can use fold expressions thanks to algorithms in the standard library.

In this section, let's talk about the syntax that was introduced in C++17.

The fold expression syntax (...) can be used only with variadic templates???, they cannot be directly used on standard containers.

#include <vector>
#include <iostream>

template <typename ...Ts>
auto sum(Ts... numbers) {
    return (numbers + ...);
}

int main() {
    std::cout << sum(1, 2, 3, 4) << '\n';
    return 0;
}

In the above example, there are three items to notice.

In the template parameter list there, there are three dots after the typename keyword, indicating that there can be more than one item of the same type
In the function parameter list, there are also three dots, but after the actual type indicating also that there can be many of them

You could read about the details of those in this article on variadic templates.

The third thing to notice is the (numbers + ...) expression. That is called the fold expression and this particular one is a unary right fold. It will be expanded as (1 + (2 + (3 + 4))). The parameter pack you have on the left will be "combined" by using the operator in the middle. If the fold expression would have started with the three dots ((... + numbers)) then we would talk about a unary left fold expression expanded as (((1 + 2) + 3) + 4).

There are a couple of more things here.

Why did I use the unary word?
Can we pass in a standard container?

I used the unary keyword because the above is not the only type of fold expression that exists. Binary fold expressions are also a thing. The main difference is that with binary fold expressions, you define an initial value so that folding doesn't start by combining the first two elements of the variable pack, but by combining the first item with the initial value.

If we rewrite a unary fold to a binary fold by using the identity element of a given type/operation combination, then we can be sure to have a well-defined and meaningful behaviour even if the variable pack does not contain any items. Binary fold expression can also start from the left ((0 + ... + numbers)) or from the right ((numbers + ... + 0)).

For standard containers, we'll see how to use the standard algorithms. We could pass a container to the above sum() function but it wouldn't sum up the vector. The template would be expanded into a function that takes one std::vector as Ts. But it could effectively use the operator+ on different vectors combining them into one std::vector.

Fold algorithms

While fold expressions were only introduced in C++17, we already had fold algorithms earlier in the standard. The most well-known is std::accumulate which was added in C++11. std::reduce is another fold operation added by C++17.

With C++23, we get 6(!) other fold operations, namely:

std::ranges::fold_left
std::ranges::fold_left_first
std::ranges::fold_right
std::ranges::fold_right_last
std::ranges::fold_left_with_iter
std::ranges::fold_left_first_with_iter

`std::accumulate`

std::accumulate takes 4 parameters. The first two define the range of elements it should fold. It also takes an initial value for the folding operation and as a last parameter, it takes a binary operation that it will apply on the running accumulated value (starting with the initial value) and the next item of the input range going from left to right. The binary operation defaults to operator+.

#include <iostream>
#include <numeric>
#include <vector>

int main()
{

    std::vector nums {1, 2, 3, 4};
    std::cout << "sum: " 
              << std::accumulate(nums.begin(), nums.end(), 0,  [] (int previousResult, int item) {
                    return previousResult + item;
                  })
              <<'\n';
}
/*
sum: 10
*/

As mentioned above, std::accumulate performs a left fold. In order to apply a right fold, we have to pass in the input range in reverse order.

It's also worth noting that we can fold a range of items into a type that is different from the initial value. So for example we can accumulate a range of ints to a single string.

#include <iostream>
#include <numeric>
#include <string>
#include <vector>

int main() {
    std::vector nums {1, 2, 3, 4};
    std::cout << std::accumulate(nums.begin(), nums.end(), std::string(),  [] (std::string previousResult, int item) {
                    if (previousResult.empty()) {
                      return std::to_string(item);
                    }
                    return previousResult + '-' + std::to_string(item);
                  })
              <<'\n';
}
/*
1-2-3-4
*/

If you want to avoid having an additional initial value and fold items starting right with the first item, just use the first item as an initial value and leave it out of the range you pass in.

#include <iostream>
#include <numeric>
#include <string>
#include <vector>

int main() {
    std::vector nums {1, 2, 3, 4};
    std::cout << std::accumulate(nums.begin()+1, nums.end(), std::to_string(nums[0]),  [] (std::string previousResult, int item) {
                    return previousResult + '-' + std::to_string(item);
                  })
              <<'\n';
}
/*
1-2-3-4
*/

`std::reduce`

std::reduce was introduced later than std::accumulate, only in C++17. While std::accumulate is a left-fold operation, std::reduce doesn't guarantee any order, it can take pairs of items in just any order. As such, its binary operation can only operate on elements that are at least convertible into the value type of the range. In other words, you cannot fold a container of integers into a string as an integer is not implicitly convertible to a string.

On the other hand, std::reduce can be parallelized, and accordingly, it takes an optional ExecutionPolicy parameter before all the others.

#include <iostream>
#include <numeric>
#include <string>
#include <vector>

int main() {
    std::vector nums {1, 2, 3, 4};
    std::cout << std::accumulate(nums.begin(), nums.end(), 0) <<'\n';
    std::cout << std::reduce(nums.begin(), nums.end()) <<'\n';
}
/*
10
10
*/

The initial value is missing from the parameters of std::reduce as it can default it to the default constructed value of the passed-in range's value type. This might be dangerous because the default constructed type might not always be the identity value.

As reduce might take items in just any order, the results might differ from the result of a left-fold operation.

#include <iostream>
#include <numeric>
#include <string>
#include <vector>
#include <execution>

int main() {
    std::vector nums {32,16,8, 4, 2, 1};
    std::cout << std::accumulate(nums.begin()+1, nums.end(), *nums.begin(), std::minus<>{}) <<'\n';
    std::cout << std::reduce(nums.begin()+1, nums.end(),*nums.begin(), std::minus<>{}) <<'\n';
    std::cout << std::reduce(std::execution::seq, nums.begin()+1, nums.end(),*nums.begin(), std::minus<>{}) <<'\n';
    std::cout << std::reduce(std::execution::unseq, nums.begin()+1, nums.end(),*nums.begin(), std::minus<>{}) <<'\n';
    std::cout << "======\n";
    std::cout << std::reduce(std::execution::par, nums.begin()+1, nums.end(),*nums.begin(), [](int a, int b){
        std::cout << a << " " << b << '\n';
        return a-b;
    }) <<'\n';
}
/*
1
25
25
1
======
16 8
4 2
8 2
32 6
26 1
25
*/

With accumulate we get 1 as expected, but reduce produces different outputs except for with the unsequenced_policy. The last call, where we pass in a lambda doing an identical operation compared to std::minus, reveals the reason. Subtraction is not commutative and associative, therefore when the items are evaluated in a different order, you won't have the same result.

So when you make a decision between accumulate and reduce, you have to take into account that as well.

Now let's move on to algorithms introduced by C++23.

`std::ranges::fold_left` and `std::ranges::fold_right`

The names of these algorithms are straightforward. They either perform a left- or a right-fold on the passed-in range. As they are part of the ranges library they can directly take a range (such as a container), but they also have overloads to take a range defined by its beginning and the end.

Both the initial value and the binary operation must be provided.

#include <iostream>
#include <algorithm>
#include <vector>

int main() {
    std::vector nums {1, 2, 3, 4};
    std::cout << std::ranges::fold_left(nums, 0, std::plus{});
}
/*
10
*/

As we saw with std::accumulate, these new fold algorithms can also fold items of a range into a different type, such as ints to a string.

#include <iostream>
#include <algorithm>
#include <string>
#include <vector>

int main() {
    std::vector nums {1, 2, 3, 4};
    std::cout << std::ranges::fold_left(nums, "",
        [](std::string previous, int item) {
            if (!previous.empty()) {
                previous += "-";
            }
            previous += std::to_string(item);
            return previous;
        });
}
/*
1-2-3-4
*/

`std::ranges::fold_left_first` and `std::ranges::fold_right_last`

It might happen that you don't have an identity element for the type you're folding. In those cases, you can start folding starting from the second item and use the first as the initial value. We already saw earlier how to do it with std::accumulate when we passed numbers[0] as the initial value and numbers.begin()+1 as the beginning of the input range.

C++23 provides library support for those cases so you don't have to write error-prone code, you simply pass in the range, you skip the initial value and call the function that will take the first value from the range. There are 2 such functions so that we have support both for left and right folding.

#include <iostream>
#include <algorithm>
#include <optional>
#include <string>
#include <vector>

int main() {
    std::vector<int> nums {8, 2, 2, 2};
    std::optional<int> r = std::ranges::fold_left_first(nums, std::divides{});
    if (r) {
        std::cout << r.value();
    } else {
        std::cout << "folding has no value!\n";
    }

    std::cout << '\n';
    std::vector<int> reversedNums(nums.rbegin(), nums.rend());
    std::optional<int> r2 = std::ranges::fold_right_last(reversedNums,
        [](int item, int previous) { return previous / item; });
    if (r2) {
        std::cout << r2.value();
    } else {
        std::cout << "folding has no value!\n";
    }
    return 0;
}

It's worth noting that in the second example we could not use std::divides, because when we fold from the right to the left, we have to also change the order of the parameters for a non-commutative operation.

Sadly, we cannot use these two functions when we want to fold a collection of elements into another type. We cannot fold a vector of integers into a string.

`std::ranges::fold_left_with_iter` and `std::ranges::fold_left_first_with_iter`

The previous functions returned only the folded value. These two functions return two values. In the first position, they return the iterator pointing at the end of the range and in the second position there comes the result. The main difference between these two functions is that std::ranges::fold_left_with_iter takes an initial value and therefore it always returns a folded value, while std::ranges::fold_left_first_with_iter doesn't take an initializer, uses the first item as the initial value and only returns a std::optional as a value.

Why are these functions needed?

A range is not necessarily defined by two iterators. The first iterator denoting the beginning of a range is mandatory, but the second one can also be a sentinel, a condition defining when the iteration should finish.

As the fold functions must compute the end, why not return them just in case?

#include <iostream>
#include <algorithm>
#include <ranges>

int main()
{
    auto oneDigitNums = std::views::iota(1) | std::views::take_while([](int i) { return i < 10;});
    std::cout << std::ranges::fold_left(oneDigitNums, 0, std::plus{}) << '\n';

    auto [end, result] = std::ranges::fold_left_with_iter(oneDigitNums, 0, std::plus{});
    std::cout << "Folding finished at " << *end << " with the value " << result << '\n';

    auto [end2, result2] = std::ranges::fold_left_first_with_iter(oneDigitNums, std::plus{});
    std::cout << "Folding finished at " << *end2 << " with the value " << result2.value_or(-1) << '\n';
}
/*
45
Folding finished at 10 with the value 45
Folding finished at 10 with the value 45
*/

Conclusion

In this article, we reviewed how fold expressions and functions evolved in C++. The first fold function (std::accumulate) was introduced by C++11. Then C++17 also introduced std::reduce and language support as well in the form of fold expressions to simplify folding for variadic templates.

Last, but not least, we reviewed the 6 brand new fold functions C++23 is going to give us. We'll have the chance to

fold from both directions,
use the first or last value as the initial value and
we can even get back the iterator pointing just past the last value that was taken into account from a range.

Connect deeper

If you liked this article, please

hit on the like button,
subscribe to my newsletter
and let's connect on Twitter!

Recent changes and personal commitments

Sandor Dargo — Wed, 07 Jun 2023 05:31:38 +0000

Life is change. Such a cliché.

Yet it is true. Everything is changing around us and if we try to stay the same, the world passes by. If you don't want to move backwards, you have to keep reinventing yourself.

Even if I don't want to constantly reorganize my day, as a parent I must. The constraints set by the world, by the obligations of my kids make me do so.

They are not the only reasons, but at least they have helped me to get into the habit of making changes. I'm not attached to how I do things.

The need for change

I wake up about an hour and a half before my family on a normal workday to progress with reading, with writing my blog, and my book projects. A few months ago, I started to feel that things progress very slowly. I spend the same amount of time on writing, but I don't progress well - something that you hopefully haven't realized by reading my articles.

For some reason, I find it more difficult to deal with context changes than before and it takes me more time to focus on something than before. Ideally, I should understand the reasons behind it so that I can act on the problem. Maybe it's because my topics are more complex than used to be, or at least I demand a deeper analysis from myself, a higher quality - something that you have hopefully seen over the last few years.

If I want to keep up with the demands of the raising bar that I have set for myself, I have to apply some changes.

I changed how I use pomodori

Until I don't understand the root causes of my struggles, I made some immediate changes. Working on different things every day and progressing a little bit is great. It helps you to realize the benefits of the compound effect. But if the taxes of context switching is too high, then it's worth investing the double less frequently, reaping twice the benefits every time (or even more).

Mathematically it makes sense.

Imagine that you do something every day and you get 1% better. By the end of the year, you'll be 37 times better. It's maybe inaccurate in this context, but it shows the power of compound interest.

(1 + 0.01)**365 = 37.78

If you only do the same things every second day, but then you get better by 2% because you invest twice the time on each occasion and you get better focus, you can still get ahead just as far.

(1 + 0.02)**183 = 37.48

So this is what I'm trying these weeks and months. I have reorganized my work on personal projects in a way that instead of one pomodoro, I spend two consecutive pomodori on a given area a day. I still start my day with half an hour of reading - unless I don't manage to get up, which sometimes happens especially if the kids don't sleep well. Then instead of working half an hour on one and then on a second writing project, I only work on one for a full hour.

Maybe it's just the power of the new approach, but so far it works better.

It usually takes some time to get focused, but then I can get into a flow-like state and I can make bigger progress.

Some smaller adjustments

You can usually read that the way you do one thing is the way you do everything. If you manage to change one aspect of your life, it will have an effect on all the others. I want to become better focused and I think there are a couple of things that are in my way.

Social media

When I'm tired - that can be during the day - or when I'm just waiting for a task to finish, I tend to open social media and not do there anything useful. I just scroll. I'm not even willing to enter into any discussion because it never ends well.

So instead, I try to keep a list of articles open and just resume those when I have some time to kill, up to a few minutes. I try to get ahead by reading C++-related articles or The Pragmatic Engineer.

Calories

When I left behind the office because of Covid, I quite quickly lost about 3 kilograms. I guess all fat. The reason was that in the office, there was always an occasion. Someone brought some pastries, a cake, whatever. They were not replacing my breakfast at home. They were additional calories.

This disappeared when I started to work from home and the results were visible - at least on the scale.

With years this started to change. And I have often gone out to the kitchen looking for something to eat, usually in the late afternoon even though I cut some fruits each morning for an afternoon snack. I decided to cut these afternoon journeys to the kitchen. As I started to associate most of these items with sugary industrial garbage, I tend not to desire them. The best would be not to have them at home, but hey, I don't live alone.

I also like to drink 1-2 beers or glasses of wine a few evenings a week and they are often accompanied by a handful of peanuts. Obviously, I started to limit these items too. An easy thing was to buy less peanuts, so if there is no more, there is no more. You could argue that I should do the same with alcohol, but I buy them when they are on sale. But if there is no beer in the fridge, who would drink it? So that's a solution. And anyway, I find it much easier to say no to these items as they are associated with bad habits and addiction, not like peanuts which contain a load of calories but are healthy as well.

With these changes and my rigorous evening walks I start to lose the excess. I mean we talk about an excess of less than 10kgs, not a huge amount, but you must take things under control while they are easily manageable.

In any case, in my opinion, going for a walk every day is a must when you work from home both for physical and mental reasons.

Double task list

I started to manage a double task list at work. There is one for the current items that I have to deliver. There might be two projects in parallel or just that they are not broken down as much as I need for my daily work. They are refined enough so that the team understand and decides what to work on, but I prefer to further break it down into bit-sized chunks so that I can more easily pick up the next during the day.

Also, if I have to wait on a longer local build or on the CI, it's good if I can pick up something. Reading the above-mentioned articles for half an hour is nice and dandy but probably not the most productive.

Hence I started a second talk list that contain smaller and not very important items. Some cleanup tasks, small experiments, things that are not related closely to my deliverables, and mostly things that nobody asked for. If I have some time to kill, I pick something from there.

Goals everywhere

I've been setting daily/weekly/monthly goals for a long time and now I (re)started to do it also at work. I close each day by setting the goals for the next and trying to make sure that at least one of the 3 items I hit already before lunch. It helps me stay focused and also to be more confident.

Conclusion

I wanted to write this article to share a bit about my struggles and the experiments, and solutions I've come up with and I'm more than happy if you also share how you manage to keep up with life. I'm lucky because I don't have to work at a second job and that I can get up in the morning and work on some personal projects and that I can leave the apartment in the evening, the kids are not sleeping alone. I find the idea of only working and taking care of the family and chores without almost no personal time terrifying... I'm lucky. You need something else, something personal to fulfil you.

We all have only so much time. It might not be up to us to decide on our responsibilities, but it's completely up to us, how we manage the time we have and we better do it well, as time is the only resource that we cannot get back if we waste it.

Connect deeper

If you liked this article, please

hit on the like button,
subscribe to my newsletter
and let's connect on Twitter!

C++23: two additional noexcept functions

Sandor Dargo — Wed, 31 May 2023 07:58:56 +0000

If my math is correct, there are 125 changes / fixes / new features in C++23 and we are progressively covering them on this blog. I try to go from topic to topic. There are some topics with many smaller changes, such as constexpr, there are some significant topics where even one topic must be in its own post such as the stacktrace library, and there are also some shorter posts with few and quite small changes on a given topic. Today we are going to discuss noexcept related changes.

If you haven't read it, I'd recommend reading my article on noexcept and its effects on binary size

We can definitely see two trends in the proposals accepted for the latest standards. They try to make more and more functions:

constexpr, and
noexcept

The two main changes presented today fit into this trend. But let's start with discussing a bit of noexcept policies in the standard.

`noexcept`, but with conditions

The current policies on whether something in the standard can be noexcept or not is defined by P1656R2. Let me summarize the gist of it here.

As we got used to it, a destructor should never throw and therefore even if you don't mark it noexcept they implicitly are!

There might be standard library functions marked unconditionally noexcept if the committee fully agrees that the given function cannot throw.

The standard specifies a couple of special member functions and library functions that can be marked conditionally noexcept, based on the underlying types and the types these functions operate on. Nothing else can be marked noexcept, except for library functions that are designed for compatibility with C. Those can be unconditionally noexcept.

Most often, we mark functions either noexcept or not. So we often mark our functions unconditionally noexcept. But noexcept can take a compile-time computable condition, such as std::is_nothrow_move_constructible_v<T> && std::is_nothrow_assignable_v<T&, U>

Here is the list that can be marked conditionally noexcept according to C++20.

std::swap
the copy-constructor and -assignment operator
the move-constructor and -assignment operator

This list is getting modified in the C++23 standard.

It's also worth noting that an implementation can mark conditionally noexcept a function even if it's not listed by the standard so.

Add a conditional noexcept specification to `std::exchange`

One of the primary use cases for std::exchange is implementing the move constructor and move assignment operator. In a certain way, it's quite similar to std::swap. Yet, while std::swap and move operations can be conditionally noexcept, it was not the case for std::exchange.

Up until C++23.

P2401R0 makes std::exchange conditionally noexcept. The conditions are the same as for move operations: is_nothrow_move_constructible_v<T> && is_nothrow_assignable_v<T&, U>.

Add a conditional noexcept specification to `std::apply`

With the introduction of zip algorithms in C++23, people in and around the committee started to talk once again more and more about std::apply.

The reason is that std::apply could be effectively used to implement these new algorithms. In fact, in the previously referenced proposal apply appears quite a few times. Sadly, std::apply is not noexcept.

But, if we have a look into the exposition-only implementation of apply, we can see that it uses invoke and get. The latter is noexcept and the former is conditionally noexcept, so there is no reason why std::apply should not be conditionally noexcept.

And that becomes the new reality with C++23:

template<class F, class Tuple>
  constexpr decltype(auto) apply(F&& f, Tuple&& t) noexcept(see below);

// Let I be the pack 0, 1, ..., (tuple_size_v<remove_reference_t<Tuple>>-1). The exception specification is equivalent to: noexcept(invoke(std::forward<F>(f), get<I>(std::forward<Tuple>(t))...)).

Conclusion

In this article, we reviewed how the standard defines its policies towards the noexcept specification and we also see that two standard library functions (std::apply and std::exchange) are becoming noexcept.

Connect deeper

If you liked this article, please

hit on the like button,
subscribe to my newsletter
and let's connect on Twitter!

C++23: Even more constexpr

Sandor Dargo — Wed, 24 May 2023 08:28:09 +0000

Ever since C++ introduced the constexpr keyword in C++11, each new standard brought us more and more opportunities to make our code increasingly constexpr, in other words, compile-time execution friendly.

In this article, we are going to review briefly what changes with C++23 on this front.

Non-literal variables in `constexpr` functions

P2242R3 proposes to remove the restriction that a constexpr function cannot contain

a definition of a variable of a non-literal type
a definition of a variable of static or thread storage duration,
or a goto statement,
or an identifier label.

The rationale behind this change is that the presence of the listed things in a function is not a problem as long as they are not evaluated at compile-time. We should remind ourselves that a constexpr function may or may not be evaluated at compile-time.

Let's suppose that in a constexpr function we want to call a piece of code that is guaranteed to be evaluated at compile-time. Then we need to have that piece of code in a block under the condition of either if consteval or if (std::is_constant_evaluated()).

With this paper, the following code becomes valid.

template<typename T> constexpr bool f() {
  if (std::is_constant_evaluated()) {
    // ...
    return true;
  } else {
    T t; // This could have been problematic before
    // ...
    return true;
  }
}
struct nonliteral { nonliteral(); };
static_assert(f<nonliteral>());

As nonliteral is a non-literal type, the compilation should fail without this proposal, even though the line that causes the failure is not in a constant-evaluated context.

This change is available starting from GCC 12 and Clang 15.

Relaxing some more `constexpr` restrictions

As I mentioned in the intro, every new standard relaxes a bit constexpr conditions and in fact, even the previous section discussed relaxations. But there is more. Thanks to Barry Revzin and P2448R2.

Let's see the two main issues the paper wants to solve.

Functions that are not yet `constexpr`

As I wrote earlier, a constexpr function might be evaluated at compile-time but might not. Whether or not a call can be constant-evaluated might depend on the parameters passed in. Often it seems straightforward that a function cannot be constant-evaluated because of the non-constexpr functions it calls. But never say never! More and more functions in the standard library become constexpr and conditionally marking functions constexpr - as in the next happens - is painful:

#include <optional>

#if __cpp_lib_optional >= 202106
constexpr
#endif
void h(std::optional<int>& o) {
    o.reset();
}

Explicitly defaulted functions follow different rules

Another problem Barry wanted to address is related to explicitly defaulted functions. Let's use the following template to demonstrate the issue:

template <typename T>
struct Wrapper {
    constexpr Wrapper() = default;
    constexpr Wrapper(Wrapper const&) = default;
    constexpr Wrapper(T const& t) : t(t) { }

    constexpr T get() const { return t; }
    constexpr bool operator==(Wrapper const&) const = default;
private:
    T t;
};

If you mark a member function constexpr, it means that it might be evaluated in a constant-evaluation context.

On the other hand, if you default a member function, it means that it must be constexpr-compatible in all instantiations. Yet, not all the compilers complain if you violate this rule and those that raise an error, they don't raise the error in each case.

In the case of a template, this means that all instantiations should be constexpr-compatible. If that's not possible, the current solution is to remove the constexpr from the explicitly defaulted constructors and operator==(). We might end up with an instantiation where they would be usable in a constant-evaluation context, yet they are not marked as constexpr

What is changing after all?

With the acceptance of this proposal, there are a couple of restrictions removed.

Constructors and destructors will follow the same rules as functions in terms of constexpr. In addition, an explicitly defaulted function on its first declaration will not only be implicitly inline but also implicitly constexpr if it satisfies the requirements of a constexpr function.

And even constexpr functions will get some relaxed rules - beyond the relaxation presented in the previous section. They can return and/or take as parameters non-literal types.

This change is available starting from GCC 13.

Permitting static `constexpr` variables in `constexpr` functions

P2647R1 corrects a hole in the standard. As the proposal says, there is no good reason why a constexpr function cannot have today a static constexpr local variable.

While this is fine:

char xdigit(int n) {
  static constexpr char digits[] = "0123456789abcdef";
  return digits[n];
}

Its constexpr version wouldn't compile without some workarounds presented in the [paper](https://wg21.link/P2647R1:

constexpr char xdigit(int n) {
  static constexpr char digits[] = "0123456789abcdef";
  return digits[n];
}

Not anymore! The above code is becoming legit. GCC 13 and Clang 16 already support it!

`constexpr type_info::operator==()`

At the moment, typeid is allowed in constant expressions, but the returned std::type_info object has no constexpr methods, therefore it's not practically usable in a constexpr context.

P1328R1 makes the equality operator (operator==()) constexpr to std::type_info becomes practically usable in compile-time functions!

It's fascinating how far the constexpr came. I mean, typeid() and std::type_info are used for Run-Time Type Information (RTTI) and yet we talk about constexpr...

GCC 12, Clang 17 and MSVC 19.33 already provide this feature!

`constexpr` for `<cmath>` and `<cstdlib>`

Until now, <cmath> and <cstdlib> has barely contained any constexpr functions. P0533R9 aims to improve on this situation in order to facilitate compile-time programming. These headers have been simply neglected so far, otherwise, there is no reason why std::chrono::abs is constexpr but std::abs is not.

In (8.E-G sections of P0533R9 you can find the full list of functions that are going to become constexpr. Luckily it's quite a long list!

This is yet to be implemented by the compilers!

`constexpr std::unique_ptr`

P2273R3 is bringing us constexpr unique pointers. The requirements of constexpr were loosened by P0784R7, adopted by C++20. With that new and delete might be used in certain constexpr-contexts, so it was worth trying making std::unique_ptr also constexpr. It worked out fine and it's already available in the new versions of major compilers.

The authors also tried to make shared_ptr constexpr, but due to missing compile-time atomic support it's not possible for the moment to implement shared_ptr according to the standard. The authors are going to explore their possibilities further.

GCC 12, Clang 16 and MSVC 19.33 already provide this feature!

`constexpr` for integral overloads of `std::to_chars()` and `std::from_chars()`

At compile-time, there is currently no standard way to make conversions between numbers and strings. Now that a std::string can be instantiated at compile-time, we are much closer to get a constexpr std::format and this is a gap.

std::to_chars and std::from_chars are fundamental blocks for parsing and formatting as they are locale-independent, they don't throw and don't allocate memory. Except for the floating point overloads now they will become constexpr thanks to P2291R3.

They will be another step forward to have constexpr std::format.

GCC 13, Clang 16 and MSVC 19.34 already provide this feature!

`constexpr std::bitset`

P2417R2 extends the constexpr interface of std::bitset. So far, only one of the constructors and operator[] was marked as constexpr. However, since std::string can be constexpr, all the internals - and therefore the full API - of std::bitset can be constexpr.

GCC 13, Clang 16 and MSVC 19.34 already provide this feature!

DR: constexpr for std::optional and std::variant

P2231R1 adds some missing constexpr both to std::optional and std::variant. As the already referenced P0784R7 made it possible to use new and delete at compile-time (by using std::construct_at), there was no reason to not making optional and variant fully constexpr.

GCC 11, Clang 13 and MSVC 19.31 already provide this fix!

Conclusion

In this article, we reviewed the constexpr related changes in C++23. There are quite many of them, and our options for compile-time programming are growing! You can check on C++ Reference whether they are implemented by your compiler of choice.

Connect deeper

If you liked this article, please

hit on the like button,
subscribe to my newsletter
and let's connect on Twitter!

Are we - developers - spoiled or abused?

Sandor Dargo — Wed, 17 May 2023 08:04:36 +0000

I think we are lucky as software developers. Most of us like what we do and we get a good salary. Even if a lot of people do not like the company they work for, in general, they like software development and they have the possibility to learn a little bit more and look for another job.

Even if we tend to complain about the salaries we make, and it might be that we are underpaid compared to some others, in general, we earn a good salary and only a few professions let people earn and live as well.

I know that sitting all day has its severe dangers on our health, but our decent salaries come with an essentially safe job.

Outsiders would tend to tell that we are spoiled.

But the feeling of developers is often that we are severely abused.

I guess both groups are right in certain aspects.

Let me share a story with you.

Mo' responsibilities but no mo' bucks

I've met recently a friend of mine, who told me that he is finally on the lookout for a new job. He had told me some time ago, that'd stay a bit more time in his current role, so I became quickly interested in why he changed his mind.

He told me that got promoted! That's good news I thought.

So he was told that now he had the role to deploy in production, he is expected to review code and he'd have to investigate bugs in production.

As I didn't want to stop his flow of words, I kept on listening amazed. I personally think that every engineer should do code reviews. Maybe, just maybe, not everyone's approval should count the same way, but juniors should also perform code reviews. At least for three different reasons.

They often spot such typos that others wouldn't, because they focus on what they can with their experience. This was meant to be a compliment, they are often very thorough. At the same time, they often lack the bigger picture, just because of the shorter time spent around.
As they have fewer preconceptions and assumptions, they often ask very different questions in code reviews than more experienced colleagues. Those questions often help both reveal problems the authors wouldn't have thought of and put problems into a different context.
Code reviews are also a great tool to learn from more experienced authors.

I was also surprised by the fact that juniors don't have to do production investigations. Again, they are such a great tool for learning even if you have to sometimes ask for help from more experienced colleagues.

But each company, each team forms its own culture, I'm not here to judge...

It's clear that at this place juniors are deprived of tasks and responsibilities, while medior and senior engineers have both more tasks and responsibilities.

When this friend of mine asked his management what would be his new salary he was told that there is no increase, no new salary. After all, he's still a programmer who'd just write code.

What the hell?

At my previous job when I was promoted to a senior role, my senior manager even took pride in handing me over the promotion mail with the new salary. I wouldn't say it was a huge increase, it was double of a normal yearly increase. Yet, it was still at least something and the increased level of responsibility and expectations were acknowledged.

Is this friend of mine spoiled or abused? Are we developers in general spoiled or abused?

No matter the money, fairness is important

I personally think that no matter how much we earn, we should be treated fairly and an increased level of responsibility should be paid with a higher salary. At the same time, I think it's also reasonable to expect you to already perform on that level before you get the position.

In my previous jobs - as a DBA in one and a software engineer in the other - people could only be promoted if they performed their new tasks for a couple of months and management was happy about their performance. When I heard about this for the first time, I was surprised and a bit angry. What? I should perform more for the same money? But I realized that this makes sense.

What if you are a good coder, but you cannot be a good mentor? What if you cannot communicate and you cannot review code without killing the morale of the team? What if you cannot handle the pressure that comes with investigating production incidents? Then you clearly don't merit the position where these are expected, and these tasks, including communication, are expected from senior engineers!

It doesn't mean that you're bad at what you had been doing, it means that you're not ready for the new position. Or maybe you don't even want to be in that position! Not everyone has to be a mentor and accept a certain level of technical leadership.

Demoting someone can be a big loss of face. I think it's better if our current abilities and readiness are slowly assessed based on real-life performance before a promotion. I think it's even better if we pick up these responsibilities gradually. Then once we have enough of them and we perform in those well enough, then we can get our promotion - along with the salary increase.

Now you might claim that if those responsibilities come gradually, then the salary increase should be gradual too and the promotion shouldn't be a big hike. You should get a few smaller increases over the years - beyond the normal yearly increase. That's also a way, still, I think that a promotion should always come with a certain level of salary increase.

If that's not possible due to some economic circumstances, make sure as an employer that you emphasize those circumstances and promise that as soon as the wartime ends, you compensate for the missed increase. And of course, don't forget about it...

Conclusion

Are we spoiled or abused? In certain ways, both can be true. Our field is very competitive and we are asked a lot in order to get a good job. Sometimes even in order to get a bad job. On the other hand, we are paid a relatively high salary and we can complain about things that make us seem spoiled.

On the other hand, there are many bad practices in the industry, in our management that might make you feel abused if you experience it. One of these things is getting a promotion with increased responsibilities and more tasks but without a salary increase.

I think that no matter how much we earn we should be treated fairly and part of this fairness is that you don't handle a promotion in two different ways. Saying that now you have to do this and that in addition, but then claiming that your job is still the same, so you don't qualify for an increase is not what I call fair treatment.

Connect deeper

If you liked this article, please

hit on the like button,
subscribe to my newsletter
and let's connect on Twitter!

Is this dynamic_cast needed?

Sandor Dargo — Wed, 10 May 2023 08:02:48 +0000

I have already written a couple of times about dynamic_cast. I claimed that if you can avoid using it and RTTI, you can get a smaller binary. I also claimed that without dynamic_cast your code will be cleaner.

The first claim is new from my side, I didn't care about executable size earlier. The second one is less so, I read a long time ago in the Core Guidelines that one should avoid using dynamic_cast whenever possible, but there are some cases when you cannot avoid it.

I've discussed this topic with a friend of mine who's been teaching C++ for a couple of years and I know he doesn't share these views that much. Or at least he's not so critical towards dynamic_cast. He thinks that it is a useful tool in many cases and there must be a reason why it's in the language and not removed.

It is true that is mentioned in the Core Guidelines that there can be some cases when it is needed. Besides, one of the greatest superpowers of C++ is backward compatibility. Removing dynamic_cast would break half of the world...

dynamic_cast safely converts pointers and references to classes up, down and sideways along the inheritance hierarchy - according to CppReference.

This friend of mine sends me some piece of code every now and then saying that this might be a good example. He sent me an example a few weeks ago and maybe this was the good one. Maybe.

A tree combining templates and virtuals

The example is from Category Theory for Programmers written by Bartosz Milewski who also wrote C++ In Action: Industrial Strength Programming Techniques. He shows that we should be able to write/recognize some algebraic data structures in C++ and implement fmap for them.

fmap is a higher-order function in functional programming that applies a given function to the elements of a container and returns a new container with the results.

And here is his implementation for a Tree and fmap().

template<class T>
struct Tree {
    virtual ~Tree() {};
};

template<class T>
struct Leaf : public Tree<T> {
    T _label;
    Leaf(T l) : _label(l) {}
};

template<class T>
struct Node : public Tree<T> {
    Tree<T> * _left;
    Tree<T> * _right;
    Node(Tree<T> * l, Tree<T> * r) : _left(l), _right(r) {}
};

template<class A, class B>
Tree<B> * fmap(std::function<B(A)> f, Tree<A> * t) {
    Leaf<A> * pl = dynamic_cast <Leaf<A>*>(t);
    if (pl)
        return new Leaf<B>(f (pl->_label));
    Node<A> * pn = dynamic_cast<Node<A>*>(t);
    if (pn)
        return new Node<B>( fmap<A>(f, pn->_left)
                          , fmap<A>(f, pn->_right));
    return nullptr;
}

Is that a good implementation? What is good anyway? The author explicitly writes that he omitted resource and memory management and in production code, one should use smart pointers. I think it's a meaningful simplification in a book or in a blog post.

Let's concentrate on fmap() first and just take note that it's probably an acceptable idea to return nullptr if both casts fail. I'd probably throw an exception instead if exceptions are allowed, otherwise, let's say that this is fine.

But what about the dynamic_cast?

My first idea was that hey, we should replace the one "big" fmap() with 2 overloads:

template <typename A, typename B>
Leaf<B>* fmap2(std::function<B(A)> f, Leaf<A>* t) {
    return new Leaf<B>(f2(t->label));
}

template <typename A, typename B>
Node<B>* fmap2(std::function<B(A)> f, Node<A>* t) {
    return new Node<B>(fmap2<A>(f, t->_left),
                        fmap2<A>(f, t->_right));
}

But in this case, the compilation fails!

<source>: In instantiation of 'Node<B>* fmap2(std::function<B(A)>, Node<A>*) [with A = int; B = float]':
<source>:82:28:   required from here
<source>:68:32: error: no matching function for call to 'fmap2<int>(std::function<float(int)>&, Tree<int>*&)'
   68 |     return new Node<B>(fmap2<A>(f, t->_left),
      |                        ~~~~~~~~^~~~~~~~~~~~~
<source>:62:10: note: candidate: 'template<class A, class B> Leaf<B>* fmap2(std::function<B(A)>, Leaf<A>*)'
   62 | Leaf<B>* fmap2(std::function<B(A)> f, Leaf<A>* t) {
      |          ^~~~~
<source>:62:10: note:   template argument deduction/substitution failed:
<source>:68:39: note:   cannot convert 't->Node<int>::_left' (type 'Tree<int>*') to type 'Leaf<int>*'
   68 |     return new Node<B>(fmap2<A>(f, t->_left),
      |                                    ~~~^~~~~
<source>:67:10: note: candidate: 'template<class A, class B> Node<B>* fmap2(std::function<B(A)>, Node<A>*)'
   67 | Node<B>* fmap2(std::function<B(A)> f, Node<A>* t) {
      |          ^~~~~
<source>:67:10: note:   template argument deduction/substitution failed:
<source>:68:39: note:   cannot convert 't->Node<int>::_left' (type 'Tree<int>*') to type 'Node<int>*'
   68 |     return new Node<B>(fmap2<A>(f, t->_left),
      |                                    ~~~^~~~~

Of course! What if t is a Tree<A> and not a Leaf of a Node?! That shouldn't happen, but even in the original code we have a case to handle that, so let's just add:

template <typename A, typename B>
Tree<B>* fmap2(std::function<B(A)>, Tree<A>*) {
    return nullptr;
}

Now the code compiles, but the executable returned 139. In other words, we have a segmentation fault.

Right, Node has two pointers to Tree and instead of matching one of the overloads for Leaf or Node, the one for Tree is matched which returns a nullptr and when we try to print the labels we crash.

In case of function overloads the static type is matched. If we want runtime dispatching, we need virtual functions and overrides.

So what if we'd implement a virtual clone function? The initial idea might seem nice, but the problem is that we'd also have to either apply f on the member or just use its return type (marked by typename B). In order to do so, we could apply an extension of the prototype design pattern, where a virtual clone() method replaces a virtual constructor which doesn't exist in C++. The only problem is that we would need to extend the pattern by passing the transformation function (f) to the clone() as a parameter. But f is a template type and we cannot combine a virtual function with a template.

We'd need to somehow erase f's return type by the time we reach clone(). But you have to know where to stop and when going down the rabbit hole is not worth it - in my opinion.

Let's just accept that dynamic_cast has its merit with this Tree implementation.

But do we really need it?

Prefer composition over inheritance

Probably we have all heard in many places that we should prefer composition over inheritance.

We are also probably familiar with the KISS principle which means that we should keep things simple, stupid.

Now let's have a look at the above Node class once again:

template<class T>
struct Node : public Tree<T> {
    Tree<T> * _left;
    Tree<T> * _right;
    Node(Tree<T> * l, Tree<T> * r) : _left(l), _right(r) {}
};

We have a derived class inheriting from a templated base class. This derived class stores two pointers to objects of the base class type. We use templates, composition and inheritance at the same time. That cannot be KISS.

I don't think that it's needed.

We do need templates given that we want the ability to store different types in the tree.

We also need composition, as in a node we want to store references to the underlying two trees.

To simplify the Tree class and also hope to remove the need for dynamic_cast, let's get rid of the class hierarchy.

(I'm also omitting the issue of memory management as I want the two solutions to remain easily comparable)

What does that inheritance give us anyway?

Just by looking at the type, we know whether we deal with an intermediary node or a leaf in the tree. But we can know that in other ways too.

template<typename V>
class Tree {
 public:
    Tree(Tree* l, Tree* r): left(l), right(r) {}
    Tree(V l): label(l) {}

 private:
    Tree<V>* left = nullptr;
    Tree<V>* right = nullptr;
    std::optional<V> label = std::nullopt;
};

In the above Tree class we have three members. Two pointers two other Trees and we also store an optional label.

We expose two constructors:

the one taking two pointers to Trees initializes an object that corresponds to the former Node class
the other taking an instance of the template argument type initializes an object that will serve as a Leaf

As the members are private, we either use Tree one way or the other. By looking at the initialization, we'll know which way it is used. If you really want to know it during runtime, we could query an additional member bool is_leaf; which would be initialized in the constructor call. But I don't think that we need that knowledge. (If the label cannot be nullopt in a leaf, we could also check the state of the optional label)

Also, we'd need to expose certain getters to the members of this class, but we don't need them for the fmap() implementation. You might argue that if the accessors are non-const then people can misuse the class. And that's a valid concern. But it takes extra effort (why would you do that?) and it strikes out in a pull request, it's easy to spot such misuses (why would you approve that?).

The fmap() implementation is fairly simple:

template<typename V, typename N>
Tree<N>* fmap(std::function<N(V)> f, Tree<V>* t) {
    if (!t) { return nullptr; }
    return new Tree(fmap(f, t->left),
                    fmap(f, t->right),
                    t->label ? std::optional<N>(f(*t->label)) : std::nullopt);
}

If t is nullptr then we stop the recursion by returning nullptr. Otherwise, we return a new Tree using the mapped type (V -> N).

In order to make this work, we need a new Tree constructor that can initialize all the members. But nobody else needs that so let's make it private and make fmap() a friend of Tree.

template<typename V>
class Tree {
 public:
    Tree(Tree* l, Tree* r): left(l), right(r) {}
    Tree(V l): label(l) {}

 private:
    Tree(Tree* l, Tree* r, std::optional<V> v): left(l), right(r), label(v) {}

    template<typename V2, typename N>
    friend
    Tree<N>* fmap(std::function<N(V2)> f, Tree<V2>* t);

    Tree<V>* left = nullptr;
    Tree<V>* right = nullptr;
    std::optional<V> label = std::nullopt;
};

Which one is better?

I don't have a clear answer.

In the original solution, you can see from the (dynamic) type whether you deal with a node or a leaf. But you also need a polymorphic structure and all the overhead that comes with it. You don't only see this characteristic, but each type represents a clear role.

You might say that my solution is not complete because we need to expose the members, but there is a very high chance that the original Tree wouldn't stay a struct and the members would be private in that too. But even in that case, the second solution (if the accessors are non-const) might be misused. Even though it's not convenient and it is highly visible.

But what about performance?

We can expect that the second solution will have a bigger memory footprint as in every case each node of the Tree has 3 members. Two pointers and an optional V.

On the other hand, we can expect that the second solution will be faster, as there are no virtual functions, there is no dynamic dispatching of function calls and obviously no casting.

I created a small Tree of 8 integers and applied a function on it which multiplies each value by 2 and ran it 10,000 times. The static solution took a bit longer time to compile (~3%), and its executable was a tiny bit smaller (~2%), but it was executing much faster (~50%). Even though as expected, the memory consumption was 30% higher for the non-polymorphic version.

So the second solution is smaller, much faster, but it needs way more memory at runtime. It's simpler, but in a way, it's less expressive.

In most cases, there is no black or white. Only tradeoffs. In this case, we traded off memory for runtime. Simplicity for expressiveness.

Conclusion

Today, we talked once again about when (not) to use dynamic_cast. We looked into a tree implementation where fmap() needed to use dynamic_cast. Then we looked into another where it was not needed. The dynamic_cast version needs more time to execute but much less memory than the non-polymorphic version.

Programming, just like life, is about tradeoffs. In this case, the solution with dynamic_cast has its merits, but you might go with another solution depending on your constraints.

Connect deeper

If you liked this article, please

hit on the like button,
subscribe to my newsletter
and let's connect on Twitter!

Variadic functions vs variadic templates

Sandor Dargo — Wed, 03 May 2023 09:17:13 +0000

A few months ago, I wrote a review on Template Metaprogramming with C++ by Marius Bancila
where I mentioned not only that it's a great book, but also that there are some topics which I'll cover more in detail. Some time ago we discussed constructor templates and today I want to discuss variadic functions and variadic function templates.

What are variadic functions?

Even if you don't explicitly know about variadic functions, you have most probably used the printf() family in C and/or C++. A variadic function is a function that can take an arbitrary number of arguments of any type. It must be the last (group of) parameters in a function signature.

void printAll(std::string items, ...);

Then in order to process the arguments, you have to use a couple of macros defined in <cstdarg>.

First, we need va_list to hold the information needed by the other macros. Then using va_start() you get access to the first argument, then with va_arg() you get access to each coming one and with va_end() you finish the traversal.

#include <cstdarg>
#include <iostream>

void printAll(size_t count, ...) {
    va_list args;
    va_start(args, count);
    for(size_t i = 0; i < count; ++i) {
      std::cout << va_arg(args, int);
      std::cout << " ";
    }
    std::cout << '\n';
    va_end(args);
}

int main() {
  printAll(4, 3, 2, 1);
  printAll(3, 8.2, 2, 1.1);
  printAll(5, 23, 32, 8, 11, 9);
}

The thing is, it's extremely error-prone. Only one out of the above 3 calls is correct.

Let's see the outputs.

3 2 1 -665149312 
2 -665177168 24116274 
23 32 8 11 9

In the first call, we first pass 4 indicating that we are passing 4 arguments and that's what we do, we pass overall four and four values are printed. While the first three are fine, the fourth one is a negative number. Well, the function reads some value from uncharted memory territories. We should have passed in 3 as a count to show that we want to print 3 arguments. Sadly, the function didn't complain that we try to print more than was passed in.

In the second case, we send in the right amount of parameters, but while the function tries to read out int values, two of the inputs are floating point numbers. And while you might have expected that those numbers are truncated to integers, instead some odd values are printed. The reason is that an integer and a floating point number are represented differently in memory so when you try to read an int as a float or a float as an int, you'll end up with something completely different. Though I don't understand why the value 2 appears in the first place, instead of the second.

The third call is fine. We pass in the right amount of parameters and of the right type. But these short examples already showcased how easy it is to shoot ourselves in the leg with variadic functions. It's one thing that they rely on macros, which is clearly not the way in 2022, but they are also entirely unsafe and they rely on that you count the number of passed-in arguments.

Now let's see if variadic templates are safer.

What are variadic templates?

What is going to be similar is the use of the three dots (or ellipses): .... But where should those dots appear?

They can both appear before and after the type parameter! Depending on where they appear, they have different meanings. So far, so bad!

Let's have a look at the implementation of our printAll function.

#include <cstdarg>

#include <iostream>

template <typename T>
void printAll(T item) {
  std::cout << item << ' ';
}

template <typename T, typename... Args>
void printAll(T item, Args... args) {
  printAll(item);
  printAll(args...);
  std::cout << '\n';
}

int main() {
  printAll(3, 2, 1);
  printAll(8.2, 2, 1.1, "duck");
  printAll(23, 32, 8, 11, 9);
}

You notice immediately that we have 2 overloads. One for the normal case and one for the variadic one. The first one prints one argument, while the second one recursively calls the first as it expands its parameter pack.

Let's talk about two things here. First, the position of the ellipses and second a bug in our implementation and how to fix it.

In the template parameter list, there are three dots between the typename keyword and the name of the template parameter pack (Args). That's by convention that it's attached to the typename but they can be attached to the parameter (...Args) or they can be standalone as longs as the dots are consecutive (typename ... Args), the compiler does not care.

It's similar to the function parameter list. You can put the ellipses wherever you want between the parameter type and the parameter name. Again, by convention, we attach them to the parameter name meaning that there will be many of them coming.

In the implementation, the three dots must follow the parameters, it does not matter whether there is a space in between or not. But if the ... are missing, in other words, if you don't unpack the parameter pack, the compilation fails. As long as there is more than one parameter in the pack, the same variadic overload is called recursively and once there is only one left, the other overload is pulled that will stop the recursion.

And now let's talk about the problem, which does not come up for example if you want to sum up a list of numbers, but I still decided to keep this example. We might learn something interesting.

With this version, We are printing n-2 newlines after calling printAll where n is the number of parameters to be printed. One way to overcome this issue would be to have a parameter for indicating whether a new line should be printed at the end of the call, and it would be only true for the client printAll() call. To make the client pass in a boolean (or any other parameter) all the time would not be nice. It makes the API more difficult to use and also error-prone. Ideally, that could be done with a default argument, but both a default argument and a variadic template argument need to have the last place. Even though there are some techniques to overcome this they are too complex to keep our code clean.

We need a helper method.

#include <iostream>

template <typename T>
void printAllImpl(T item) {
  std::cout << item << ' ';
}

template <typename T, typename ...Args>
void printAllImpl(T item, Args ... args) {
  printAllImpl(item);
  printAllImpl(args...);
}

template <typename... Args>
void printAll(Args&&... args) {
  printAllImpl(std::forward<Args>(args) ...);
  std::cout << '\n';
}

int main() {

  printAll(3, 2, 1);
  printAll(8.2, 2, 1.1, "duck");
  printAll(23, 32, 8, 11, 9);
}
/*
3 2 1 
8.2 2 1.1 duck 
23 32 8 11 9 
*/

With the separation of printAllImpl from the non-recurisve printAll we achieved that there will only be one newline character printed and we used perfect forwarding so that we reduce the unnecessary copies.

This solution is totally superior to the variadic function both in terms of readability and in terms of type safety.

Conclusion

In this article, we discussed the differences between variadic functions and variadic templates. We saw how to use variadic functions, how they rely on macros and that we pass in exactly the types a variadic function expects and also the right amount of them. Variadic templates are easier to read and easier to use. They provide the type safety that is missing from the old variadic functions.

Do you still use variadic functions? If so what are your arguments?

Connect deeper

If you liked this article, please

hit on the like button,
subscribe to my newsletter
and let's connect on Twitter!

Without RTTI your code will be cleaner

Sandor Dargo — Wed, 26 Apr 2023 12:40:26 +0000

Recently, in the binary sizes series, we discussed how run-time type information affects RTTI. I also mentioned that in my opinion the lack of RTTI leads to better practices and you'll end up with a more readable, more maintainable code.

It's time to delve into this topic and see why.

What is RTTI again?

But first of all, let's quickly recap what is run-time type information. RTTI let us have information on the dynamic type of reference/pointer types. It lets us use dyanamic_casts and also call the typeid() function and query the returned instance of std::type_info.

I think that not having access to these tools will let you write better code. Why so?

Let's start with probably the less controversial tool.

Don't rely on `typeid()`

Inexperienced programmers might want to automatically use typeid().name() to see what's the dynamic type of something during development and testing. It's usually not kept because often the output is not that readable. I mean for int, you might simply get i. That's something easily recognizable, but not something you'd want to see in the logs.

The bigger problem is that the output is implementation-defined, so you really shouldn't count on it if you want code that is portable. (Even though there is a fair chance that they will be the same on GCC and clang).

Let's see a couple of examples.

#include <iostream>

int main() {
    std::cout << typeid(5).name() << ' ';
    std::cout << typeid(5u).name() << ' ';
    std::cout << typeid(5.0).name() << ' ';
    std::cout << typeid(true).name() << ' ';
    std::cout << typeid('5').name() << '\n';
    return 0;
}
/*
gcc:   i j d b c
clang: i j d b c
*/

Different outputs among compilers do not mean that you cannot use them consistently. You can still use typeid().name() or typeid.hash() to compare types against each other in your code and branch the execution based on those comparisons...

On the other hand, you don't have many reasons to do that. If you have to deal with, if you have to compare unrelated types, probably you should extract the type-dependent code and use different overloads.

#include <memory>
#include <iostream>
#include <vector>

class Wine {
public:
  virtual ~Wine() = default;
  virtual void print() { std::cout << "this is wine\n"; }
};

class WhiteWine {
public:
  virtual ~WhiteWine() = default;
  virtual void print() { std::cout << "this is white wine\n"; }
};

class RedWine {
public:
  virtual ~RedWine() = default;
  virtual void print() { std::cout << "this is red wine\n"; }
};

class RoseWine {
public:
  virtual ~RoseWine() = default;
  virtual void print() { std::cout << "this is rose wine\n"; }
};

int main() {
    std::vector<std::unique_ptr<Wine>> wines;
    auto wine1 = std::make_unique<WhiteWine>();
    auto wine2 = std::make_unique<RedWine>();
    auto wine3 = std::make_unique<RoseWine>();
}

If the types are from the same inheritance tree, then you should either use dynamic_casts or even better, you should benefit from dynamic dispatching.

`dynamic_cast` is slightly better, but still should be avoided

dynamic_cast safely converts pointers and references to classes up, down and sideways along the inheritance hierarchy - according to CppReference. Often when you have a collection of pointers to the base class, you'll try to cast it to different derived classes and if the case is successful you do whatever you want with that type.

In other words, when you have no idea what types you have, you can start casting things. You might even have a series of casts like this:

OffRoader* offroader = dynamic_cast<OffRoader*>(car);
if (offroader) {
  offroader->turnOnAllWheelDrive();
}

Van* van = dynamic_cast<Van*>(car);
if (van) {
  van->attachThirdSeatRow();
}

Roadster* roadster = dynamic_cast<Roadster*>(car);
if (roadster) {
  roadster->removeRoof();
}

Many would say that this is a code smell. I'm among them. Many would go further and say that using dynamic_cast in general is a code smell.

As mentioned earlier, this is almost always better than relying on typeid(), but behind dyanimc_casts you'll only find bad inheritance trees and messed up APIs.

Rather than having different public interfaces, we should have a unified one.

There is a convenient reason for that. If the interface is unified, we don't need to cast our objects, we can simply rely on runtime dispatching of our function calls.

#include <iostream>
#include <memory>
#include <vector>

class Car {
public:
  virtual ~Car() = default;
  virtual void doSomeFun() = 0;
};

class OffRoader: public Car {
public:
  void doSomeFun() override {
    std::cout << "use all wheel drive on OffRoader\n";
  }
};

class Van: public Car {
public:
  void doSomeFun() override {
    std::cout << "attach third seatrow in a van\n";
  }
};

class Roadster: public Car {
public:
  void doSomeFun() override {
    std::cout << "remove roadster's roof\n";
  }
};

int main() {
    std::vector<std::unique_ptr<Car>> myCars;
    myCars.push_back(std::make_unique<OffRoader>());
    myCars.push_back(std::make_unique<Van>());
    myCars.push_back(std::make_unique<Roadster>());

    for (auto& car: myCars) {
      car->doSomeFun();
    }

    return 0;
}

When `typeid` is still better?

As I mentioned earlier, while dynamic_cast is not a good solution, it's almost always better than using typeid(). Why not always?

There is a not-so-subtle difference between these 2 RTTI tools. dynamic_cast checks whether an object "is kind of" another class. But typeid() will look for an exact match.

#include <iostream>
#include <memory>
#include <vector>

class A {
public:
    virtual ~A() = default;
};

class B: public A {
};

class C: public B {

};

int main() {
    std::unique_ptr<A> p1 = std::make_unique<C>();

    B* p2 = dynamic_cast<B*>(p1.get());
    C* p3 = dynamic_cast<C*>(p1.get());
    if (p2) {
        std::cout << "p1 is like B*. it's convertible to B\n";
    } else if (p3) {
        // we won't reach this branch due to bad ordering of if/else branches
        std::cout << "p1 is like C*. it's convertible to C\n";
    }

    if (typeid(*p1) == typeid(B{})) {
        std::cout << "*p1 is B\n";
    } else if (typeid(*p1) == typeid(C{})) {
        std::cout << "*p1 is C\n";
    }

    return 0;
}

/*
p1 is like B*. it's convertible to B
*p1 is C
*/

As such, typeid() is both simpler and faster. Even though we had to construct an extra instance of B and C in the above example to be able to compare the type information. If that's costly and/or we must do this several times, we could create a map of std::type_index objects.

// ...
const std::map<std::string, std::type_index> typeMap = {
    {"A", std::type_index(typeid(A{}))},
    {"B", std::type_index(typeid(B{}))},
    {"C", std::type_index(typeid(C{}))}
};


if (p2) {
    std::cout << "p1 is like B*. it's convertible to B\n";
} else if (p3) {
    // we won't reach this branch due to bad ordering of if/else branches
    std::cout << "p1 is like C*. it's convertible to C\n";
}

if (typeid(*p1) == typeMap.at("B")) {
    std::cout << "*p1 is B\n";
} else if (typeid(*p1) == typeMap.at("C")) {
    std::cout << "*p1 is C\n";
}
// ...

There is a couple of things to note:
- typeMap is const. It's necessary, because std::type_index is a copyable wrapper around the non-copyable std::type_info. It is not default constructible. In other words, if the map is not const, then the code wouldn't compile as a mutable map's value type must be default constructible.

std::type_index is a copyable wrapper around the non-copyable std::type_info. As std::type_index does not have a default constructor, you cannot use operator=() to add new items to the map. You either initialize it at declaration (which is preferable), or you use the insert() method.
We use map::at() and cannot use map::operator[]. The reason is that map::operator[] is not const whereas map::at() has a const overload.

Overall, the best is still avoiding both using typeid and dynamic_cast.

When to still use `dyanmic_cast`?

The C++ core guidelines explain well the differences between casting to a pointer or a reference type and when you should refer which (C.147 and C.148), but it doesn't mean that you should use any.

In fact, even C.153 says that you should prefer using virtual functions to casting. Casting is error-prone and you can make mess it up easily. Virtual functions are safe and when you call virtual functions it's guaranteed that you'll reach the most derived function. On the other hand, we saw with dynamic_cast that you might end up calling an intermediary function.

As we saw earlier, with virtual functions your code will be cleaner and speed is not an issue because dynamic_cast is (also) slow.

Conclusion

With Run-time Type Information, we get access to typeid() and dynamic_cast. They help us query the dynamic types of polymorphic objects. In other words, they help us identify which derived objects are held by base class pointers.

With great power, we also get great responsibility. Sadly, experience shows that responsibility is often abused. These tools are often overused and result in messy code. Using virtual functions and relying on dynamic dispatching is almost always better.

Besides having cleaner code, you can also benefit from shorter compile times and smaller binaries as the type information doesn't have to be generated and stored. To me, turning RTTI off is a great option to consider.

Do you rely on it?

Connect deeper

If you liked this article, please

hit on the like button,
subscribe to my newsletter
and let's connect on Twitter!

We are always late

Sandor Dargo — Wed, 19 Apr 2023 07:20:32 +0000

I recently read a post on social media about modern people who are always chasing themselves as they are always late. It also reminded me of what one of my first bosses told me. According to the mentioned post, we all live as if we were late all the time. We keep complaining that we have no time and wherever we are, whatever we are doing, we just keep thinking about the next thing to do. Therefore we are not present even in our own lives.

If we are always late then we are anxious all the time. Being late is vastly different from waiting for something. While the latter is often positive - oh, I'm waiting for meeting my partner at this nice restaurant - the former is always negative - oh, I'm late from that bloody restaurant and my partner will be pissed off once again!

I feel this too. I don't have enough time. Neither at work nor in my personal life.

I have many ideas on what to do, but I simply don't have enough time to implement them. By now, I reached the point where I don't even have an idea how I could find significantly more time.

But is that normal?

There is the other idea that Béla told me, one of my first managers. He said that I should not worry about finishing all my tasks. There will be always more work at a corporation than time to finish it.

After 13 years of working for bigger companies, I'm sure that he was right. I don't remember a case where I would have had to think for more than a few seconds to find another task.

But isn't this stressful?

For many it is stressful because they think that they cannot stop, they should do whatever is lined up as soon as possible.

Personally, I don't find this stressful at all.

Let me explain why.

First of all, I see it as a challenge and an opportunity to learn. If you have more work than time, you have to prioritize. Knowing how to prioritize is a valuable skill in all domains of your life. If you had more time than tasks, you'd not be able to learn this skill.

Secondly, people are greedy. Including stakeholders. They always want more and more and they often want it for less and less. You shouldn't feel bad because you cannot satisfy greedy people's ideas.

But it's not all that negative. The excess of tasks does not only come because of greed, it's also a sign of creativity and care. You and your team know how to improve the code, how to make your product better, hence you have a bigger backlog that needs prioritization. Then it's up to the product owner/manager to decide on the priorities and up to the team to see how many tasks they can take. But rest assured there will be more tasks than you can take on.

How do I deal with it in my personal life?

In my own life, I'm both the product owner and the person who gets to implement the tasks. I have a chip in the game. I want to complete as many tasks as possible to get forward. I don't have a boss who understands that one cannot get everything done.

Or to put it differently, I am the boss and I'm a demanding one - demanding towards myself.

Does this mean that I'm always unhappy with my results, with my progress? Not exactly, I'm usually happy with my progress, I always try to see how far I got and not how far I'm still from my goals. But at the same time, I find it frustrating that I cannot spend more time on things that I'd like to do.

Here is my biggest mental pain. I find it extremely difficult to accept that I have almost no personal time at all apart from the time that I allocate from my sleep time. I get up about 90 minutes earlier than the rest of the family and I try to stay up later than I would normally do to be able to spend time on writing, reading, and learning.

Then I also feel humbled and grateful that at least I can manage this. There are many single and probably non-single parents who have to use even these parts of the day to provide. To do the chores, to cook for the next day, and so on.

I try to think about Toni Morrison who as a divorced mother with 2 little kids and with a day job managed to write her first book in the late evenings.

I know that I'm in a very good situation even considering my free time, but it's a hard job to remind myself about and accept that this is good. This is realistic.

How do I deal with it at work?

At work, I have understood what are realistic expectations and I do my best to live up to them. I understand that we cannot do everything and that we sell our time to our employer and we should do our best during the contracted time and stop when it ends.

It doesn't mean it's easy to stop. If you like your job, if you like what you're doing, then it's difficult to stop. Sometimes it's difficult for me to stop, but I remind myself that there are other things in life. Actually, many other things that I cannot complete.

This helps.

But that's only one side of the story. The other side is that I regularly talk about what can be done, and how much I can do with my manager and/or with my peers so that we are on the same page. If I get a new task and I feel that it's getting too much, I remind the manager or PO about it and I ask what should be deprioritized from the other tasks. I usually propose a few to choose from. Most of the management I've worked with understood this and picked something, sometimes the task once understood that it's not so much important.

When it comes to the quantity of work, it's worth keeping in mind two things.

The average office worker spends around 3 hours a day at productive work
50% of the work is done by the square root of the total number of people who participate in the work

Try to aim to be somewhere in between the two groups. Even though the 3 hours might be higher in certain companies. I think it's higher at Spotify, partly because you can survive with fewer meetings (most of the time), so you have more time to work.

At the same time, I think it's not worth being in the other group. Those people are not paid that much better, but they work a lot more. I'd say that the value of extra work is diminishing.

It might seem ridiculous to think about these things, but it helps set both your goals and boundaries.

What's the difference?

And that's why most people feel stressed about their long list of tasks. Most of us are not clear on our boundaries and therefore we are uncomfortable saying no. Partly because we are afraid that by saying no, we might be dismissed and also because we see it as a personal failure.

Managing this is difficult. I cannot do it well in my private life. I essentially sleep less to be able to do a bit more, but at least I know my limits. I know what's the point that if I bypass, I won't be able to get up on time and I'll feel shit the whole day. Even though I respect that in most cases, I don't think I have enough sleep time.

Work is easier because I realise I don't work for myself there. Don't get me wrong. I put in a fair quality and quantity of work. I don't think that I take advantage of the company or that the company takes advantage of me.

I don't feel bad that I could still continue working, that I still have many to do at the end of the day. But

if I work more, I won't get paid more
if I work more, it won't make a big difference on the scale of the company
if I work more, my family will feel it and it'll have bad consequences for us.

The key is that you have to understand your limits and also to communicate those limits with your peers and your managers so that they won't have false expectations towards you. This is so important. It's better to get 10 units if you communicate 10 than get 15 if you set the expectation to 20. In the latter case, you'll likely feel exhausted and disappointed. The others will simply be disappointed.

"I need good people not tonight, but also in a year. If you keep working like that, you'll burn out. Please, go home now." - This is what one of my former senior managers used to tell a colleague who always stayed late and worked overtime. He didn't only care about the product, but also about the people. We loved him so much for a reason.

Conclusion

Today we discussed the relationship between available time and work to do. The latter is always more abundant than the former. If not, I think your job is at stake and you have other problems to focus on.

My advice is that don't overwork and do not feel late or bad about the work lined up. It's not your fault that there is more work than time. It's natural at the companies. If you're a developer and you're stressed out because of this, you are probably not shielded enough and your product owner is not setting priorities well.

In your personal life, it's more difficult to set the right boundaries and not to feel bad, but try to remind yourself about your professional approach and maybe you find some help and reassurance in that.

Connect deeper

If you liked this article, please

hit on the like button,
subscribe to my newsletter
and let's connect on Twitter!

Vectors and unique pointers

Sandor Dargo — Wed, 12 Apr 2023 06:20:56 +0000

In this post, I want to share some struggles I had twice during the last few months. For one of my examples, I wanted to initialize a std::vector with std::unique_ptr. It didn't compile and I had little time, I didn't even think about it. I waved my hand and changed my example.

Then I ran into the same issue at work, while we were pairing over an issue. I couldn't just wave anymore, and luckily we also had the time to go a bit deeper.

What we wanted was a little bit different and more complex though. We wanted to return a vector of unique pointers to a struct that holds - among others - a unique pointer.

This is a simplified version of what we wanted:

class Resource {
  // unimportant
};

struct Wrapper {
  std::string name;
  std::unique_ptr<Resource> resource;
}

// somewhere in a function
std::vector<std::unique_ptr<Wrapper>> v{
  std::make_unique<Wrapper>(std::move(aName), std::make_unique<Resource>()),
  std::make_unique<Wrapper>(std::move(anotherName), std::make_unique<Resource>())
};

That's a bit too complex to start with, so let's dissect the issue into two parts.

No compiler-generated copy constructor

Let's first omit the external unique pointer and try to brace-initialize a vector of Wrapper objects.

#include <memory>
#include <string>
#include <vector>

class Resource {
  // unimportant
};

struct Wrapper {
  std::string m_name;
  std::unique_ptr<Resource> m_resource;
};


int main() {
  std::string aName = "bla";
  std::vector<Wrapper> v{Wrapper{aName, std::make_unique<Resource>()}};
}

The first part of the problem is that we cannot {}-initialize this vector of Wrappers. Even though it seems alright at a first glance. Wrapper is a struct with public members and no explicitly defined special functions. Our {}-initialization follows the right syntax and the parameters are passed in the right order.

Still, the compiler says stop! Here is a part of the error messages. As vector is a template we cannot expect a concise message.

/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_uninitialized.h:90:56: error: static assertion failed: result type must be constructible from input type
   90 |       static_assert(is_constructible<_ValueType, _Tp>::value,

If we scroll up in the errors we'll find a more explanatory line:

In instantiation of 'constexpr bool std::__check_constructible() [with _ValueType = Wrapper; _Tp = const Wrapper&]':

So the problem is Wrapper cannot be constructed from const Wrapper&, in other words, Wrapper cannot be copy constructed. That makes sense! It has a move-only member, std::unique_ptr<Resource> m_resource! Because of this move-only member, the compiler cannot automatically generate a copy constructor.

A `std::vector` always copies its `std::initializer_list`

That's all fine but why do we need a copy constructor? Why cannot we benefit from move semantics?

We can spot the answer on C++ Reference! std::vector has only one constructor involving a std::initializer_list and there the initializer_list is taken by value. In other words, vector copies its initializer_list. Always.

As the passed in initializer_list is going to be copied, the contained type must be copy-constructible. That's clearly not the case for Wrapper which we can easily assert.

struct Wrapper {
  std::string m_name;
  std::unique_ptr<Resource> m_resource;
};

static_assert(std::is_copy_constructible<Wrapper>());
/*
main.cpp:18:20: error: static assertion failed
   18 | static_assert(std::is_copy_constructible<Wrapper>());
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*/

Let's make contained types copy constructible

That's quite easy to fix, we need to provide a user-defined copy constructor, such as Wrapper(const Wrapper& other): m_name(other.m_name), m_resource(std::make_unique<Resource>()) {}. At the same time, let's not forget about the rules of 0/3/5, so we should provide all the special functions.

Now we don't have the problem anymore, we can easily use the brace initialization.

#include <memory>
#include <string>
#include <vector>

class Resource {
  // unimportant
};

struct Wrapper {
  std::string m_name;
  std::unique_ptr<Resource> m_resource;
  Wrapper() = default;
  ~Wrapper() = default;
  Wrapper(std::string name, std::unique_ptr<Resource> resource) : m_name(std::move(name)), m_resource(std::move(resource)) {}

  Wrapper(const Wrapper& other) : m_name(other.m_name), m_resource(std::make_unique<Resource>()) {}
  Wrapper(Wrapper&& other) = default;

  Wrapper& operator=(const Wrapper& other) {
    m_name = other.m_name;
    m_resource = std::make_unique<Resource>();
    return *this;
  }

  Wrapper& operator=(Wrapper&& other) = default;
};

int main() {
  std::string aName = "bla";
  std::vector<Wrapper> v{Wrapper{aName, 
  std::make_unique<Resource>()}};
}

But what if we cannot or do not want to modify Wrapper? Do we have any other options?

Of course!

We can also extract `vector` initialization

If we have to avoid the brace-initialization of the vector, we can simply default initialize it, probably reserving then enough space for the items we want to add, and use either vector's emplace_back() or push_back() methods.

There is not a big difference in this case between emplace_back() and push_back(). push_back() will call the appropriate constructor first and then the move constructor. emplace_back() will only make one constructor call. At least that's the theory. Let's see if we're right. I amended Wrapper so that each of its special functions prints.

#include <memory>
#include <string>
#include <vector>

#include <iostream>

class Resource {
  // unimportant
};

struct Wrapper {
  std::string m_name;
  std::unique_ptr<Resource> m_resource;

  Wrapper() {
    std::cout << "Wrapper()\n";
  }

  ~Wrapper() {
    std::cout << "~Wrapper()\n";
  }

  Wrapper (std::string name, std::unique_ptr<Resource> resource) : m_name(std::move(name)), m_resource(std::move(resource)) {
    std::cout << "Wrapper (std::string name, std::unique_ptr<Resource> resource)\n";
  }

  Wrapper(const Wrapper& other) : m_name(other.m_name), m_resource(std::make_unique<Resource>()) {
    std::cout << "Wrapper (const Wrapper& other)\n";
  }

  Wrapper(Wrapper&& other) {
    std::cout << "Wrapper (Wrapper&& other)\n";
  }

  Wrapper& operator=(const Wrapper& other) {
    std::cout << "Wrapper& operator=(const Wrapper& other)\n";
    return *this;
  }

  Wrapper& operator=(Wrapper&& other) {
    std::cout << "Wrapper& operator=(Wrapper&& other)\n";
    return *this;
  }
};


int main() {
  std::string aName = "bla";
  std::vector<Wrapper> v{};
  v.emplace_back(aName, std::make_unique<Resource>());
  // v.push_back(Wrapper(aName, std::make_unique<Resource>()));
}

/*
output with emplace_back:
Wrapper (std::string name, std::unique_ptr<Resource> resource)
~Wrapper()
*/

/*
output with push_back
Wrapper (std::string name, std::unique_ptr<Resource> resource)
Wrapper (Wrapper&& other)
~Wrapper()
~Wrapper()
*/

Our assumption was right, except that I forgot to note the extra destructor call on a moved-from object. While these extra calls would be often negligible, we have no reason not to use emplace_back(). It's not more difficult to write it and it's better for the performance.

With that, we've seen why we couldn't {}-initialize a vector of Wrappers following the rule of zero, where Wrapper is a type that allocates on the heap.

Now let's move over to the other issue.

The same issue with `initializer_list` once again

Actually, by answering the first question, we also learned why we cannot {}-initialize a vector of unique_ptrs. It's the problem of an initializer_list taken by value instead of reference and the fact that unique_ptrs cannot be copied.

Can we do anything to improve the situation?

We can extract the creation and population of the vector to a separate method so that we don't have the visual noise of vector insertions along with the rest of the code.

std::vector<std::unique_ptr<Resource>> createResources() {
  std::vector<std::unique_ptr<Resource>> vec;
  vec.push_back(std::make_unique<Resource>());
  vec.push_back(std::make_unique<Resource>());
  vec.push_back(std::make_unique<Resource>());
  return vec;
}


int main() {
  std::vector<std::unique_ptr<Resource>> resources = createResources();
  // ...
}

But can we do something better?

We can make a better, generalized function that makes us a vector of unique_ptrs, but the idea behind is essentially the same: the pointers are added one by one after the construction of the vector.

Let me borrow an implementation by Bartek. I take this piece of code from C++ Storties and I encourage you to read the whole article on initializer_list:

template<typename T, typename... Args>
auto makeVector(Args&&... args) {
  std::vector<T> vec;
  vec.reserve(sizeof...(Args)); 
  (vec.emplace_back(std::forward<Args>(args)), ...);
  return vec;
}

Now we can update our original example.

#include <memory>
#include <string>
#include <vector>

#include <iostream>

class Resource {
  // unimportant
};

struct Wrapper {
  std::string m_name;
  std::unique_ptr<Resource> m_resource;
  Wrapper() = default;
  ~Wrapper() = default;
  Wrapper(std::string name, std::unique_ptr<Resource> resource) : m_name(std::move(name)), m_resource(std::move(resource)) {}

  Wrapper(const Wrapper& other) : m_name(other.m_name), m_resource(std::make_unique<Resource>()) {}
    Wrapper(Wrapper&& other) = default;

  Wrapper& operator=(const Wrapper& other) {
    m_name = other.m_name;
    m_resource = std::make_unique<Resource>();
    return *this;
  }

  Wrapper& operator=(Wrapper&& other) = default;
};

// this is from Bartek: https://www.cppstories.com/2023/initializer_list_improvements/
template<typename T, typename... Args>
auto makeVector(Args&&... args) {
  std::vector<T> vec;
  vec.reserve(sizeof...(Args)); 
  (vec.emplace_back(std::forward<Args>(args)), ...);
  return vec;
}

int main() {
  [[maybe_unused]] std::vector<std::unique_ptr<Wrapper>> v = makeVector<std::unique_ptr<Wrapper>>(
  std::make_unique<Wrapper>("keyboard", std::make_unique<Resource>()),
  std::make_unique<Wrapper>("mouse", std::make_unique<Resource>()),
  std::make_unique<Wrapper>("screen", std::make_unique<Resource>())
  );
  return 0;
}

Conclusion

Today, I shared with you a problem I faced lately. I wanted to {}-initialize a vector of unique pointers, but it didn't work. A std::vector takes an initializer_list by value, so it makes a copy of it. Hence, the compilation will fail if you try to use an initializer_list with move-only types.

If you want to use the {}-initializer for a vector, you need to implement the move constructor. If that's not an option and you want to separate the creation of the vector, you have no other option than move the related code to a separate function.

Connect deeper

If you liked this article, please

hit on the like button,
subscribe to my newsletter
and let's connect on Twitter!

DEV Community: Sandor Dargo

My way to get into conferences

Going to or speaking at conferences?

How to prove that you're ready to speak?

What makes a good topic?

How to know what the organizers want?

But does this actually work?

Conclusion

Connect deeper

The 3 best books to level up your C++

Beautiful C++ by J. Guy Davidson and Kate Gregory

C++ Software Design by Klaus Iglberger

Template Metaprogramming with C++ by Marius Bancila

Conclusion

Connect deeper

Fold expressions in C++

What are fold expressions?

The syntax in C++

Fold algorithms

std::accumulate

std::reduce

std::ranges::fold_left and std::ranges::fold_right

std::ranges::fold_left_first and std::ranges::fold_right_last

std::ranges::fold_left_with_iter and std::ranges::fold_left_first_with_iter

Conclusion

Connect deeper

Recent changes and personal commitments

The need for change

I changed how I use pomodori

Some smaller adjustments

Social media

Calories

Double task list

Goals everywhere

Conclusion

Connect deeper

C++23: two additional noexcept functions

noexcept, but with conditions

Add a conditional noexcept specification to std::exchange

Add a conditional noexcept specification to std::apply

Conclusion

Connect deeper

C++23: Even more constexpr

Non-literal variables in constexpr functions

Relaxing some more constexpr restrictions

Functions that are not yet constexpr

Explicitly defaulted functions follow different rules

What is changing after all?

Permitting static constexpr variables in constexpr functions

constexpr type_info::operator==()

constexpr for <cmath> and <cstdlib>

constexpr std::unique_ptr

constexpr for integral overloads of std::to_chars() and std::from_chars()

constexpr std::bitset

DR: constexpr for std::optional and std::variant

Conclusion

Connect deeper

Are we - developers - spoiled or abused?

Mo' responsibilities but no mo' bucks

No matter the money, fairness is important

Conclusion

Connect deeper

Is this dynamic_cast needed?

A tree combining templates and virtuals

Prefer composition over inheritance

Which one is better?

Conclusion

Connect deeper

Variadic functions vs variadic templates

What are variadic functions?

What are variadic templates?

Conclusion

Connect deeper

Without RTTI your code will be cleaner

What is RTTI again?

Don't rely on typeid()

dynamic_cast is slightly better, but still should be avoided

When typeid is still better?

When to still use dyanmic_cast?

Conclusion

`std::accumulate`

`std::reduce`

`std::ranges::fold_left` and `std::ranges::fold_right`

`std::ranges::fold_left_first` and `std::ranges::fold_right_last`

`std::ranges::fold_left_with_iter` and `std::ranges::fold_left_first_with_iter`

`noexcept`, but with conditions

Add a conditional noexcept specification to `std::exchange`

Add a conditional noexcept specification to `std::apply`

Non-literal variables in `constexpr` functions

Relaxing some more `constexpr` restrictions

Functions that are not yet `constexpr`

Permitting static `constexpr` variables in `constexpr` functions

`constexpr type_info::operator==()`

`constexpr` for `<cmath>` and `<cstdlib>`

`constexpr std::unique_ptr`

`constexpr` for integral overloads of `std::to_chars()` and `std::from_chars()`

`constexpr std::bitset`

Don't rely on `typeid()`

`dynamic_cast` is slightly better, but still should be avoided

When `typeid` is still better?

When to still use `dyanmic_cast`?

A `std::vector` always copies its `std::initializer_list`

We can also extract `vector` initialization

The same issue with `initializer_list` once again