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