The conference is moved from April 10-11 to October 30-31 due to the unstable international situation. You can return your personal tickets via bezkassira.by
With any questions related to the cancellation please reach out to conf@corehard.by or +375296088822
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 the author of "Functional Programming in C++" published by Manning. He is a Senior Software Engineer at KDAB and one of the core developers of KDE, the largest free/libre open source C++ project. He is also teaching modern C++ techniques and functional programming at the Faculty of Mathematics in Belgrade and has been using C++ for more than 20 years. 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++.
Klaus Iglberger is a freelancing C++ trainer and consultant. He has finished his PhD in computer science in 2010 and since then is focused on large-scale C++ software design. He shares his experience in popular advanced C++ courses around the world. Additionally, he is the initiator and lead designer of the Blaze C++ math library and (co-)organizer of the Munich C++ user group.
Security Researcher at Check Point Research. Used to work as a C++ Developer. Worked on industrial automation and cyber security products. Currently utilizes his skills in malware analysis and security research.
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
Course Description
This class gives you a detailed insight into the multithreading facilities of C++11, C++14, and the parallel algorithms which
we got with C++17.
Additionally, we will have a look into the C++ memory model consisting of the atomics and the various memory orders in C++.
This insight will provide you with a better understanding of the general concurrency features of C++.
Prerequisites
Participants should have a basic knowledge of the C++ language and the fundamentals of multithreading.
In the class, I will give you a concise introduction to the topic. This introduction provides the starting point for the exercises;
therefore, you should bring your laptop with you including a C++11 or C++14 compiler.
You will get in return the training material consisting of the presentation, the exercises, and the solutions to the exercises.
Course Topics
- Multithreading
-- Threads
-- Shared Data
-- Mutexes and Locks
-- Thread-safe Initialisation
-- Thread-Local Data
-- Condition Variables
-- Tasks (Promises and Futures)
-- Parallel STL
- Memory Model
Course Description
This class gives you a detailed insight into the multithreading facilities of C++11, C++14, and the parallel algorithms which
we got with C++17.
Additionally, we will have a look into the C++ memory model consisting of the atomics and the various memory orders in C++.
This insight will provide you with a better understanding of the general concurrency features of C++.
Prerequisites
Participants should have a basic knowledge of the C++ language and the fundamentals of multithreading.
In the class, I will give you a concise introduction to the topic. This introduction provides the starting point for the exercises;
therefore, you should bring your laptop with you including a C++11 or C++14 compiler.
You will get in return the training material consisting of the presentation, the exercises, and the solutions to the exercises.
Course Topics
- Multithreading
-- Threads
-- Shared Data
-- Mutexes and Locks
-- Thread-safe Initialisation
-- Thread-Local Data
-- Condition Variables
-- Tasks (Promises and Futures)
-- Parallel STL
- Memory Model
Design patterns have proven to be useful over several decades and knowledge about them is still very useful to design robust,
decoupled systems. Modern C++, however, has profoundly changed the way we use C++, think about design and implement solutions.
This hands-on training explores modern C++ design and the modern forms of the classic design patterns. It provides guidelines,
idioms and best practices for sustainable and maintainable design, which enable programmers to create professional, high-quality
code. Amongst others it will answer the following questions:
- How does good C++ design with a minimum of dependencies look like?
- Why does classical C++ design based on inheritance hierarchies fail so often?
- What advantages does value semantics based design provide?
- How are the classic design patterns realised in modern C++?
- What are alternatives to the classic design patterns?
After this course, participants will ...
... have an impression on the modern alternatives of classic design patterns;
... have gained knowledge about modern design techniques;
... understand how std::function, std::any, and ranges work;
... avoid the usual pitfalls in the context of inheritance;
... know about the importance of value semantics.
Classic Design Patterns Revisited:
- Command
- Prototype
- Strategy
- Observer
- Visitor
- Factory
- Decorator
- Template Method
- Singleton
Modern Design Patterns:
- Type Erasure
- CRTP
- Expression Templates
- Policy Based Design
Design patterns have proven to be useful over several decades and knowledge about them is still very useful to design robust,
decoupled systems. Modern C++, however, has profoundly changed the way we use C++, think about design and implement solutions.
This hands-on training explores modern C++ design and the modern forms of the classic design patterns. It provides guidelines,
idioms and best practices for sustainable and maintainable design, which enable programmers to create professional, high-quality
code. Amongst others it will answer the following questions:
- How does good C++ design with a minimum of dependencies look like?
- Why does classical C++ design based on inheritance hierarchies fail so often?
- What advantages does value semantics based design provide?
- How are the classic design patterns realised in modern C++?
- What are alternatives to the classic design patterns?
After this course, participants will ...
... have an impression on the modern alternatives of classic design patterns;
... have gained knowledge about modern design techniques;
... understand how std::function, std::any, and ranges work;
... avoid the usual pitfalls in the context of inheritance;
... know about the importance of value semantics.
Classic Design Patterns Revisited:
- Command
- Prototype
- Strategy
- Observer
- Visitor
- Factory
- Decorator
- Template Method
- Singleton
Modern Design Patterns:
- Type Erasure
- CRTP
- Expression Templates
- Policy Based Design
- Expression categories: how not to get lost in (g?l|p?r|x)value;
- Move semantics and its alternatives (RVO, CoW);
- Function specializations for short-living objects;
- Compile-time computations with constexpr;
- Parametric polymorphism;
- Fine-tuning with property classes;
- SFINAE and pattern matching;
- Arithmetic computations on types;
- Compile-time lists processing.
- Expression categories: how not to get lost in (g?l|p?r|x)value;
- Move semantics and its alternatives (RVO, CoW);
- Function specializations for short-living objects;
- Compile-time computations with constexpr;
- Static polymorphism;
- Fine-tuning with property classes;
- SFINAE and pattern matching;
- Arithmetic computations on types;
- Compile-time lists processing.
What kind of language is C++? Is it a procedural programming language? An object-oriented programming language? A functional programming language? A generic programming language? All of those? None of those? In this talk I’ll analyse why it is increasingly hard to answer these questions, especially since the advent of “Modern C++”. I’ll demonstrate by example that the good solutions, i.e. the solutions that promote loose coupling, ease of use, ease of maintenance, and performance, are not firmly rooted in either one of the traditional paradigms. The examples will raise doubt whether it is reasonable to try to assign C++ to any one of the paradigms. Instead, they may be an indication that we should embrace no-paradigm programming.
I want to start with a question: Why do we need Guidelines such as the C++ Core Guidelines for Modern C++? My answer consists of three observations: C++ is complicated for the novice, challenging for the professional, and used in safety critical environments. Guidelines should give us the means to write type safe, bounds safe, and lifetime safe code by design. My presentation gives you a concise insight into the lifesaving rules of the C++ Core Guidelines to write safe C++ code by design. I cover in my presentation topics such as interfaces, functions, classes and class hierarchies, resource management, Expressions and statements, error handling, constants and immutability, templates and generic programming, concurrency and the standard library.
Copy elision is an important and inalienable language optimization that allows us to get rid of unnecessary copying and moving
which propitiously affects application performance. No developer imagines a compiler that doesn't know how to use NRVO. But
how much does copy elision save us from unnecessary constructions of object copies? In which cases he's capable of doing it
and in which not, and why? Is it possible to improve it and how will this improvement affect the performance of our programs
and code writing?
This talk is an answer to all these questions and more. Speakers will talk about new proposal in the Standard — ultimate copy
elision and show how it will improve the life of C++ developers!
Malware often use different Anti-Analysis approaches to deceive a disassembler, detect a debugger or just make the analysis unbearable either with a disassembler or a debugger. However these techniques are used not only by the bad guys but also in some products which owners don't want them to be researched. This talk is an introduction to anti-debug and obfuscation tricks in C/C++. It will cover the following topics: - compile time encryption for strings; - how to make breakpoints on system functions useless; - how to hide system call from sandboxes and API monitors; - how to detect an attached debugger.
C++20 is finally here and with it the feature that was long time coming -- concepts. This talk will cover what concepts conceptually are (pun intended), how they fit into the rest of C++, the requires syntax and a few caveats of using them. Some people deem concepts a huge and important addition to C++ while some consider them unnecessary because most features they provide can be simulated with the detection idiom. Let's see in which group you will be after this talk.
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.
What kind of language is C++? Is it a procedural programming language? An object-oriented programming language? A functional programming language? A generic programming language? All of those? None of those? In this talk I’ll analyse why it is increasingly hard to answer these questions, especially since the advent of “Modern C++”. I’ll demonstrate by example that the good solutions, i.e. the solutions that promote loose coupling, ease of use, ease of maintenance, and performance, are not firmly rooted in either one of the traditional paradigms. The examples will raise doubt whether it is reasonable to try to assign C++ to any one of the paradigms. Instead, they may be an indication that we should embrace no-paradigm programming.
We have been developing a C/C++ static code analyzer for more than 10 years already. Looking back, we can recall a number of interesting events, bifurcation points, achievents and fails. This talk will cover a wide range of problems, starting from icicle and ending with self-written C++ code parser. The talk will be interesting to both to C++ history amateurs and to the ones interested in IT startups.
There's a group of people in C++ Standardization Committee that deals with number represtntation in different ways in C++.
If you're interested in what technical problems they deal with, why these problems need to be addressed and why we have nearly
zero information about this commitee group - welcome to the talk. If you're interested in some job aspects inside of the Committee
- you're even more welcome :)
Hardcoreness: low. Level of anger towards the C++ Committee: middle.
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.
What kind of language is C++? Is it a procedural programming language? An object-oriented programming language? A functional programming language? A generic programming language? All of those? None of those? In this talk I’ll analyse why it is increasingly hard to answer these questions, especially since the advent of “Modern C++”. I’ll demonstrate by example that the good solutions, i.e. the solutions that promote loose coupling, ease of use, ease of maintenance, and performance, are not firmly rooted in either one of the traditional paradigms. The examples will raise doubt whether it is reasonable to try to assign C++ to any one of the paradigms. Instead, they may be an indication that we should embrace no-paradigm programming.
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.