The C++ CoreHard Spring 2020 is a conference dedicated to C++ and related hardcore technologies.
The conference is being organized by the CoreHard.by community that unites not only C++ engineers, but also those who are interested in low-level development in C and Assembler, programming of controllers, Internet of Things, highload server solutions and in any kind of “hardcore” development.
The conference will take 2 days: April 10 - workshop day, April 11 - conference day
Official conference languages: Russian, English
| Tickets | ||
| Date | Workshop (10.04) | Conference (11.04) |
| 01.02.2020 - 29.02.2020 | 450 BYN | 260 BYN |
| 01.03.2020 - 31.03.2020 | 500 BYN | 300 BYN |
| 01.04.2020 - 10.04.2020 | 550 BYN | 340 BYN |
Want to present a talk? Submit a proposal
We're following Berlin Code of Conduct

Phil is the author of the test frameworks Catch for C++ and Objective-C, and Swordfish for Swift. As Developer Advocate at JetBrains he's involved with CLion, AppCode and ReSharper C++. More generally he's an advocate for good testing practices, TDD and using the type system and functional techniques to reduce complexity and increase correctness. He's previously worked in Finance and Mobile as well as an independent consultant and coach specialising in TDD on iOS.

A representative of Russian working group (RG 21 RF) at C++ Standardization Committee. Author of several accepted proposals to the C++ standard. Author of the following Boost libraries: TypeIndex, DLL, Stacktrace; maintainer of Any, Conversion, LexicalCast, Variant. Author of "Boost C++ Application Development Cookbook" and "Boost C++ Application Development Cookbook, Second Edition" books.

Ph.D, 10 years of academic experience: lectures about programming for students, including Kiev National Taras Shevchenko University. 10+ years in software development (mainly in C++ and C#), focusing on data backup and restore. Vadim is an author of books "Algorithmic Languages and Basics of Programming: C language" and "Basics of Object-Oriented Programming in C++", as well as 29 publications in theory ofprogramming; translated into Russian "Principles of Object-oriented Software Development" by Anton Eliens and "Unifying Theories of Programming" by C.A.R.Hoare and He Jifeng. Now: technical lead developer at SolarWinds, develops a project in network security area. Interested in programming: C++ and functional languages (especially Haskell).

Rainer Grimm has worked as a software architect, team lead and instructor for about 20 years. In his spare time he likes to write articles about C++, Python and Haskell, but he also likes to speak at conferences. He publishes very often on his blog "Modern C++". Now he is a trainer giving seminars to modern C++ and Python. His books "C++11 für Programmierer ", "C++" and "C++ - Standardbiliothek" , and the "The C++ Standard Library" were published by O'Reilly and Leanpub.

Ivan Čukić is teaching modern C++ techniques and functional programming at the Faculty of Mathematics in Belgrade, and has been using C++ for the past 20 years. He is one of the core developers in KDE, the largest free/libre open source C++ project. He has been researching functional programming in C++ before and during his PhD studies, and uses the techniques in real-world projects.

Develops data backup and recovery software. In his spare time, actively contributes to Boost.Algorithm, is also interested in text processing algorithms. Devotes rest of the time to WG21 helping to improve C++.


Juanpe is a Berlin based freelance consultant and engineer, with a focus on interactive software, modern C++, functional programming and open source strategy. Before he worked for Ableton and he has been involved in various music technology projects. He has also developed for the GNU project and cofounded a Hacklab in Granada.

Speaker is being clarified
In any large codebase you can always find pieces of code which are not totally understandable. Mostly, such kind of code is
implemented when the application needs some performance boost... and, mostly, that code is not useful because it optimizes
functionality in wrong place, in incorrect way and in not a good way.
During our masterclass we will get to know to the allocators features, optimizers and implementations of containers; look
at assembler code; learn how to correctly and clearly write fast single-threaded and multi-threaded applications.
You only need a complier with C++ 11 support (at least VS 2013/Clang-3.3/GCC-4.8) and basic C++ knowledge
In any large codebase you can always find pieces of code which are not totally understandable. Mostly, such kind of code is
implemented when the application needs some performance boost... and, mostly, that code is not useful because it optimizes
functionality in wrong place, in incorrect way and in not a good way.
During our masterclass we will get to know to the allocators features, optimizers and implementations of containers; look
at assembler code; learn how to correctly and clearly write fast single-threaded and multi-threaded applications.
You only need a complier with C++ 11 support (at least VS 2013/Clang-3.3/GCC-4.8) and basic C++ knowledge
The C++ elites have been talking for years about value semantics, immutability, and sharing by communicating. A better world without mutexes, races, observers, command patterns and so more lies ahead! When it comes to doing it in practice, it is not so easy. One of the main problem lies in our data structures... Immutable data structures don't change their values. They are manipulated by producing new values. The old values remain there, and can be read safely from multiple threads without locks. They provide structural sharing, because new and old values can share common data — they are fast to compare and can keep a compact undo-history. As such, they are great for concurrent and interactive systems: they simplify the architecture of desktop software and allow servers to scale better. They are the secret sauce behind the success of Clojure and Scala, and even the JavaScript crowd is loving it via Facebook's Immutable.js. We are presenting Immer, a C++ library implementing modern and efficient data immutable data structures. In this session, we will talk about the architectural benefits of immutability and show how a very efficient yet powerful persistent vector type can be built using state of the art structures (Relaxed Radix Balanced Trees). We will also show an example application (a text-editor) built using the architectural style here proposed. Not only is its code extremely simple, it outperforms most similar programs. Don't believe it? Come and see!
When static vs. dynamic language debates flare up, someone invariably says that static languages are best because the compiler catches so many potential bugs. To which the dynamic language advocates say, "that doesn't happen very often, and when it does your tests will catch it - you do have tests, don't you?" Meanwhile, the debate about how to do error handling is almost as religious - do you do exceptions, error codes, assertions, contracts or something like optionals or result/ expected types? Could it be that all these concerns are related - and that understanding _how_ they are related may help us to resolve these conflicts once and for all. More importantly, can we take the best of all worlds to arrive at the nirvana of understandable, maintainable, robust, correct, code? These are the questions we will ponder, and hopefully answer.
When static vs. dynamic language debates flare up, someone invariably says that static languages are best because the compiler catches so many potential bugs. To which the dynamic language advocates say, "that doesn't happen very often, and when it does your tests will catch it - you do have tests, don't you?" Meanwhile, the debate about how to do error handling is almost as religious - do you do exceptions, error codes, assertions, contracts or something like optionals or result/ expected types? Could it be that all these concerns are related - and that understanding _how_ they are related may help us to resolve these conflicts once and for all. More importantly, can we take the best of all worlds to arrive at the nirvana of understandable, maintainable, robust, correct, code? These are the questions we will ponder, and hopefully answer.
When static vs. dynamic language debates flare up, someone invariably says that static languages are best because the compiler catches so many potential bugs. To which the dynamic language advocates say, "that doesn't happen very often, and when it does your tests will catch it - you do have tests, don't you?" Meanwhile, the debate about how to do error handling is almost as religious - do you do exceptions, error codes, assertions, contracts or something like optionals or result/ expected types? Could it be that all these concerns are related - and that understanding _how_ they are related may help us to resolve these conflicts once and for all. More importantly, can we take the best of all worlds to arrive at the nirvana of understandable, maintainable, robust, correct, code? These are the questions we will ponder, and hopefully answer.