Andrzej Krzemieński


Andrzej is a software developer since 2004. He works mostly with C++ in commercial software, which includes safety-related and high-performance systems. He is a member of the C++ Standards Committee and a Boost developer. He is also a co-organizer of C++ User Group Kraków. Known to the community for his blog on C++:



Preconditions, postconditions, invariants – how they help write robust programs (2019)

Preconditions, postconditions, and invariants are part of what is often called Design by Contract, or Contract Programming. Even if you haven't heard of them, you are probably using them already. In this talk, we are going to see what they are, and how people and tools can make use of them.


Dealing with function failures in C++ (2018)

When a function fails, how should you report the failure: throw an exception, or return an error code? In this talk we will not answer this question, but instead explore the motivation that leads people to to choose one way or the other. Next, we will see how this motivation is changed in C++17 with its new features; we will also have a look at the Outcome library. Finally, we will have a peek at the future plans for the next generation failure handling in C++.


Faces of undefined behavior (2017)

Undefined Behavior (UB) can make your programs safer and faster; it can also really mess your life. In this talk, by examples, we will see why we cannot avoid UB, why some programmers want even more of it, why others avoid it at all cost, and why they are all right.


Fewer Bugs (2016)

Unit tests are a good way of catching some bugs in a compiled program or pieces thereof. However, bugs should really not make it as far as to the unit-testing phase. In this presentation we will see pieces of advice and techniques that either prevent bugs from occurring in the first place or employ the C++ compiler to detect them during the compilation.


Constrain Yourself (2015)

This lecture shows how by the addition of ‘constrained’ types we can make our C++ compiler, perform a limited static analysis of our program, and therewith detect certain bugs and report them as compile-time errors. There are also some real-life examples of how this has been implemented in a production code.


Seeing The Bigger Picture -- Part 1 (2014)

The programs we write affect other people: they make life easier and help us do more. Programs with bugs also have negative effects: they can destroy people's work, their life, they can also cause injuries. We take certain responsibility when we write programs. In this presentation we will see examples of bugs (some with serious consequences) in programs; they are not obvious and may be difficult to spot. What connects them is the observation that they could have been avoided if the author imagined how the piece of code could be used and misused by the clients.


Seeing The Bigger Picture -- Part 2 (2014)

In this part we will see less spectacular, but more common examples of bugs. The solutions in the code may appear to be improving robustness of the program, but in fact they result in serious consequences to the users.