Executors are one of the most expected features for the upcoming C++ standards. This article tries to cast a critical perspective of some of the main proposals discussed for adoption. Besides briefly explaining the content of the executors proposal and providing a few examples, the article tries to pick on some decisions made in those proposals. It tries to argue about the strong and the weak points by adding simplistic labels of “good” and “bad”.
C++, like most imperative languages, have a bad tradition in writing multi-threaded applications. Concurrency safety ranks first in terms of C++ development frustration (far ahead from the second place). This talk shows how concurrent C++ applications can be designed by shifting the focus from low-level synchronisation to a set of concurrency patterns that deal with higher-level constructs.
Lately, we often compare the time spent reading code versus the time spent in writing code. And, we somehow lump together the actual reading of the code with reasoning about the code. But, if we look closely, these are very different activities.
We discuss too much about reading code but too little on what it means to reason about code. This article tries to explore a few aspects of what it means to reason about code. I’ll try to propose a new metric for code complexity that can be formalized (to some degree) and another metric that seems more appropriate to our cognitive behaviours.
Composition and decomposition are probably the most important tools we have as software engineers. And yet, for multi-threaded programs that use locks and raw threads, composition and decomposition doesn’t properly hold.
This article tries to consider composition and decomposition of task systems, showing that task systems play nice with regards to those two.
Similar to gotos, raw threads and locks should be banished from day-to-day programming. Moreover, we have far better way to build concurrent applications.
Watch my ACCU 2021 talk to see more.