In this talk we will explore "Concepts," a powerful feature for expressing template requirements added in C++20. Participants will learn how concepts improve code readability, provide clearer compiler diagnostics, and help enforce correct usage of templates and function overloading. Through simple, hands-on examples, we will explore the syntax, common use cases, and best practices for integrating concepts into modern C++ code. By the end of the session, attendees will understand how to write safer, more maintainable template code and leverage concepts to communicate intent clearly.
Amir Kirsh is a C++ lecturer at the Academic College of Tel-Aviv-Yaffo and Tel-Aviv University, previously the Chief Programmer at Comverse, after being CTO and VP R&D at a startup acquired by Comverse. Amir is also co-organizer of the annual Core C++ conference and the Core C++ meetup... Read More →
Your system has interchangeable strategies chosen at runtime, but the hot path runs millions of times per second. Runtime polymorphism has virtual dispatch overhead. Templates give you performance but lock you at compile time.
This workshop shows how to leverage inheritance for extensibility while avoiding vtable overhead, using a layered architecture of compile-time patterns. We'll build them up through OpenJDK's GC barrier system, where different GC algorithms compose different barriers on one of the hottest paths in the JVM.
We will also discuss trade-offs against alternatives like std::variant, function pointers, and plain virtual dispatch throughout. No JVM knowledge required.
Shubhankar Gambhir is a Software Development Engineer at Azul Systems, where he works on JVM runtime efficiency and warmup technologies. Previously, he contributed to the garbage collector, with a focus on performance and scalability. He enjoys building C++ prototypes to explore systems... Read More →
Native C++ types often become the format for bytes that cross a boundary: shared-memory IPC, plugin interfaces, persistent storage, or software built for more than one ABI. At that point the type is no longer just an implementation detail; it is part of a binary contract. trivially_copyable , sizeof , and code review help, but they do not answer the two questions that matter: may this type be transported as bytes at all, and do all supported ABIs give it the same object representation?
C++26 reflection can derive that evidence from the type itself. The technique builds a compile-time layout signature from ordinary C++ types, without IDL, generated stubs, or runtime inspection. The signature records the representation facts needed for byte transfer: architecture and endianness, leaf type tokens, sizes, alignments, absolute offsets, bit-fields, and pointer-like markers. It deliberately leaves out field names and source-level meaning.
With those signatures in hand, the build can enforce a gate for memcpy-style transfer. You name the boundary types and supported ABIs. Each target exports signatures, and a verification build permits direct byte transfer only when the type is byte-copy safe and the signature matches across the set. We'll walk through the workflow with static_assert checks and CI diagnostics: a fixed-width type that passes, a pointer-containing type rejected by admission, and a platform-divergent type rejected by signature comparison. The claim is intentionally narrow: representation compatibility, not semantic compatibility or schema evolution.
Fanchen Su is a game research & development expert and team leader. He has over 20 years of experience in designing, writing, and maintaining C++ code. His main areas of interest and expertise are modern C++, code performance, low latency, and maintainability. He graduated from Wuhan... Read More →
Practical HPC — Forcing the Compiler's Hand with Modern C++
Achieving near-peak FLOPs on modern CPUs requires exploiting SIMD, register files, and cache hierarchies — yet the levers that matter most (loop unrolling, vectorization width, tile sizes, register tiling) are largely outside the programmer's direct control. Autovectorization is fragile, #pragma unroll is advisory and non-portable, and the information the compiler needs most — loop bounds, problem shapes, working-set sizes — is typically only available at runtime. The result is a familiar gap between theoretical peak and delivered performance, bridged in practice only by hand-written intrinsics or inline assembly, fragile macro forests, or external code generators that sacrifice maintainability and type safety.
Modern C++ is, sometimes surprisingly, an excellent language for closing that gap without leaving the host language. We walk through the concrete features that make this possible and how to use them in practice — templates and constexpr to promote runtime values into compile-time constants, if constexpr and parameter packs for shape-specialized kernels, generic and template lambdas for loop bodies that are unrolled and inlined by construction, and concepts to turn silent performance cliffs into compile-time errors. Together, these give the programmer precise control over what the compiler emits: compile-time dispatch that specializes kernels per shape and target, guaranteed static unrolling that unlocks ILP and register tiling without relying on optimizer heuristics, and hardware-aware specialization parameterized on register count, SIMD width, and cache sizes.
Looking forward, C++26 and static reflection push this approach considerably further, turning today's disciplined metaprogramming into something closer to first-class, in-language code generation — and squarely aligning the language with the goal of making inline assembly unnecessary, even at the highest performance tiers.
These patterns are powerful but verbose and reappear across kernels, so we briefly introduce POET (Performance Optimized Excessive Templates), a header-only library usable from C++17 onward that packages the most common cases as ready-to-use building blocks, alongside xsimd for portable SIMD.
As a concrete case study, we walk through a real scientific-computing kernel — a workload of the kind that has historically demanded hand-tuned assembly — and show how these abstractions get within a small fraction of theoretical peak throughput while keeping the source readable, portable, and maintainable, with no inline assembly, no compiler builtins, and no external code-generation step. Scientific computing does not have to choose between performance and engineering quality, and with the right abstractions, development becomes dramatically more effective.
