Apart from training, I often give conference talks and I often write about modern C++ techniques on my blog as a way to give back to the C++ community which was the main source.
These are some of the presentations held in the past years, skipping those not focused on C++ and Qt.
Design Idioms from an Alternate Universe
[…] It is common to see different design idioms and patterns in different programming paradigms as they represent /the way/ something should be implemented in a given paradigm, and each paradigm is special enough for its way to be completely different to the way taken by the other ones. […]
Ranges for distributed and asynchronous systems
[…] Most modern systems require writing asynchronous non-blocking code - from the ordinary GUI applications which can perform time-consuming operations, but still be responsive to the user input; to servers that need to be able to process many requests at the same time. […]
Functional Programming: Data
[…] Today, most software systems have the need for some sort of concurrency. This poses problems regarding the software design. […]
Functional Reactive Programming
[…] We are going to cover an emerging programming paradigm called Functional Reactive Programming (or FRP for short) which achieves concurrency using events-based programming. But, unlike the event-callback-based systems, it does so in a much cleaner way. […]
For a brighter QFuture
[…] In the first part of this talk, we will cover the potential improvements to the QFuture class that would bring it on par with the similar classes for C++ like boost::future and Folly Future, and with similar classes in other programming languages. […]
Awaiting for the ranges: C++17
[…] There are two features planned for C++17 that are poised to reinvent the language like the lambdas and auto did for C++11. Those are the ranges (N4128) and the await (N4134). […]
Reactive programming and Qt
[…] The talk will consist of two parts. In the first part, ranges will be explained (through the boost.range library, and Eric Niebler’s range library proposal for C++17). We will show that ranges, and range transformations are a natural extension to the library in STL, which allows writing more concise and safe code that deals with collection structures like lists, vectors or maps. […]
Reactive functional and imperative C++
[…] The talk presents an overview of the functional and imperative approaches for writing asynchronous software through event streams and monad composition. […]
Slides, Video not available
Functional reactive programming for C++
[…] Reactive programming creates abstractions on top of various low-level approaches for asynchronous execution such as threads, actors, callbacks and such. Those abstractions extend the commonly used higher-order functional programming concepts to be applicable to concurrent systems. […]
Slides, Video not available
Task scheduling with the continuation monad
[…] We will create an abstraction of the different types of asynchronous and synchronous methods and structures that will allow us to write our programs in a purely imperative manner, while leaving all the complexities of IoC to the C++ compiler. The abstraction we will use is a relaxed variant of the continuation monad. […]
Monads in chains
[…] In the recent years, the abuse of multi-threading has become apparent and more and more systems started being developed in the reactive, or event-processing style. It allows lowering the number of threads to match the system cores instead of items that are being processed by using non-blocking asynchronous APIs. […]
War of Idioms
[…] We will cover some of the useful concepts ranging from the simple ones like RAII (for warm-up), to static polymorphism, and some more advanced meta-programming techniques. […]
Natural task scheduling using futures and continuations
[…] With the continuators and continuations, we are able to mimic all control structures provided by the language like serial execution, different loop types, branching and similar, along with some that are not available such as the parallel execution that can wait for all subtasks to end (all_of), for only one (any_of), or just detach the tasks and ignore whether they have finished or not; transactional execution […]