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