Disclosure: On this site you won’t find specific advice on “how to call function xyz()”. Interpreting C++ ARM and #pragma dwim is also out of scope.

We’re treating our readers as intelligent beings who can use Google and/or StackOverflow, where all such specific questions were answered more than once.

What you will find is opinions, more opinions, and even more opinions on all the aspects of software development - and with a large chunk of them based on real-world experience too.

Your mileage may vary. Batteries not included.


#ACCU2018 Day 1. From Gender Equality to (kinda-)Quantum Computing, with Threads and C++ copy/move in between

As #ACCU2018 is underway, and as I am here, it would be strange if I wouldn’t use the opportunity to tell about what I like (and don’t like ;-)) here. Diversity in Tech – What Can We Do? Gen Ashley was opening the conference with a keynote speech on “Diversity & Inclusivity in Tech”. Main point: […]

Parallel Coding: From 90x Performance Loss To 2x Improvement

Quote: “as long as serial code provides good-enough response times from end-user perspective – DON’T PARALLELIZE”
Another Quote: “out of all the premature optimizations, premature parallelization is the most premature one”

Using Parallel <algorithm> Without a Clue: 90x Performance Loss Instead of 8x Gain

Abstract: “I made an experiment which demonstrates Big Fat Dangers(tm) of implying that parallelization can be made as simple as just adding a policy parameter to your std:: call.”
Quote: “it is still necessary to understand what we’re doing”

On Programming Language Complexity, or Our Brain as a CPU with 7+-2 Registers

Quote: “Let’s consider our brain as a CPU, which consists of the control unit, ALU, and 7+-2 registers.”
Another Quote: “Moving C++ one step farther from being a brainfuck is IMNSHO always a Good Thing(tm)”

A Usable C++ Dialect that is Safe Against Memory Corruption

Quote: “we DID get a perfectly usable C++ dialect which is also 100% safe against memory corruption and against memory leaks.”
Another Quote: “we can (and often SHOULD) have different approaches to safety of the Reactor::react() and the rest of the code.”

C++: Thoughts on Dealing with Signed/Unsigned Mismatch

Quote: “we’re just narrowly avoiding a disaster without understanding how close we were”
Another Quote: “there is a chance that intuitive::lt MIGHT be a good thing to make behaviour of our C++ code to correspond better to our-expectations-when-we’re-reading-it”