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
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.
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.
- 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.
