Video

Just amazing, thank you

One of the biggest problems I've found with OOP is that it distributes the complexity of business requirements into relatively few and interdependent objects/abstractions. That has a tendency to lack orthogonality and skyrocket the complexity of the existing abstractions as well as multiply the coupling between them. Consider a design requirement like this from the AD&D rulebook: >> Nystul's Magic Aura : By means of this spell any one item of a weight of 50 g.p. per level of experience of the spell caster can be given an aura which will be noticed if detection of magic is exercised upon the object. If the object bearing the Nystul's Magic Aura is actually held by the creature detecting for a Dweomer, he, she or it is entitled to a saving throw versus magic, and if this throw is successful, the creature knows that the aura has been placed to mislead the unwary. Otherwise, the aura is simply magical, but no amount of testing will reveal what the magic is. The component for this spell is a small square of silk which must be passed over the object to bear the aura. Unless we've anticipated a whole lot in advance, implementing just this one new rule into even the most carefully-designed OO architecture will likely require changing and adding to the complexity of existing designs/interfaces/abstractions, and this is just one design requirement out of a 300+ page book filled with loads of such requirements. When we implement such design requirements procedurally or functionally, we get the desired orthogonality and don't have to add to the complexity of any design that already exists. We can just add a new function to implement each new such requirement, and distribute all the complexity into something new rather than things that already exist. OO veterans tend to wholeheartedly agree that OO design demands careful anticipation of the full design requirements upfront. What I think they fail to realize is how poorly this speaks of the OO paradigm when we use it as the central design paradigm for our business requirements, and how impossible it is to meet this demand in large-scale, long-lived software whose business requirements are ever-changing with each new version. I do find OOP useful on the small scale for relatively small sections of a codebase, since there are usually sections of a codebase whose design requirements can be trivially guaranteed to never change. Yet I think people moving away from OOP as the primary design paradigm -- not entirely and not dogmatically -- towards the likes of functional programming are genuinely doing it for very legitimate reasons (ex: John Carmack, who is a very mature sage of a programmer and not merely a cool kid), and there are radically simpler, more flexible, easier-to-maintain, easier-to-test, thread-safe codebases wanting to emerge when we do so.

This is really great stuff! Is there an open source implementation of type-safe-matrix or the compile-time-sparse-matrix available?

What is the talk about?

Dear Rainer, you are such an inspiring person, I've learned so much from your excellent talks, blogs and books! I wish you all the best and hope you get better soon.

I think there is a flaw with this design. Since the spmc queue supports variable-length messages, if a consumer is lapped by the consumer, the mVersion field the consumer thinks it is spinning on is probably not the version counter field at all. It may well be spinning on some random bytes right in the middle of mData. Then if the random bytes happen to be the version of the consumer is expecting(although the probability is very low), it could be disastrous. The customer does not know it is lapped at all, and continue processing with the meaningless data.

What ends up happening is that people explain the easy stuff with very simple clear language and they really break it down. But with the advanced stuff they prefer to believe you already know everything. I've been able to use Make to make compilation easier but CMake is really complex. It looks like it's got it's own language. A basic tutorial might include using CMake to write hello world then have it compile a very basic C hello world project with minimal Cmake files

*Abstract* This video explores C++20's coroutines, comparing them to traditional functions and highlighting their unique ability to preserve state and be resumed. The speaker delves into the key components of coroutines, including the promise type, awaiter type, and iterator, showcasing their customization potential. Through practical examples like interleaving data streams and task scheduling, the video demonstrates the power of coroutines in simplifying code and achieving efficient concurrency. *Speaker Introduction* * *0:00* Andreas Fertig, a C++ trainer and consultant, introduces himself and the topic of his talk: C++20 coroutines for beginners. * *0:37* Fertig explains the meaning and origin of his last name, highlighting the challenges of spellcheckers recognizing it as a proper noun. *Understanding Coroutines* * *2:35* Fertig differentiates coroutines from traditional functions by emphasizing the ability of coroutines to be resumed and preserve their state through `co_yield`, `co_await`, and `co_return` keywords. * *3:00* He illustrates the control flow of functions and coroutines, showcasing the resumable nature of the latter. * *6:14* He clarifies that coroutines are a superset of functions, with functions being a specialization of coroutines that do not pause. * *7:21* Fertig explains the distinction between stackful and stackless coroutines, noting that C++ implements stackless coroutines where state is stored on the heap. * *8:39* He introduces the concept of cooperative multitasking, where threads decide when to yield control, contrasting it with preemptive multitasking used in `std::thread`. *Coroutine Elements and Customization* * *11:50* Fertig details the key elements of a C++ coroutine: the return type (awaiter type), the promise type, the awaitable type (optional), and the iterator (optional). * *13:32* He emphasizes the role of the promise type in customizing coroutine behavior through various customization points like `get_return_object`, `initial_suspend`, `yield_value`, `await_transform`, `final_suspend`, and `return_value`. *Coroutine Examples* * *17:56* *Example: A Basic Chat Coroutine:* Fertig showcases a simple chat coroutine demonstrating the use of `co_yield`, `co_await`, and `co_return`, along with the implementation of the promise and return types. * *35:19* *Example: Interleaving Data with Coroutines:* He presents a coroutine that interleaves elements from two `std::vector` objects, highlighting the use of an iterator to enable range-based for loops for more readable code. * *46:12* *Example: Cooperative Task Scheduling:* Fertig demonstrates a coroutine-based scheduler that manages multiple tasks cooperatively, contrasting it with preemptive multitasking using threads. *Coroutine Restrictions and Limitations* * *56:21* Fertig outlines several restrictions on coroutines, including their incompatibility with `constexpr`, `consteval`, constructors, destructors, `varargs`, plain `auto` return types, concept return types, and the `main` function. *Q&A Session* * *1:00:01* *C++23 and Coroutines:* The discussion touches upon the `std::generator` introduced in C++23, its limitations, and the challenges of creating a universal library type for coroutines due to their flexibility. * *1:02:06* *Parallelism and Coroutines:* Fertig clarifies that coroutines do not inherently run in parallel but offer efficient concurrency through cooperative multitasking. He emphasizes the possibility of combining coroutines with `std::thread` for more complex scenarios. * *1:03:56* *Coroutine Depth and Heap Usage:* He confirms that the depth of coroutine chains is practically limited only by available heap memory. * *1:07:51* *Coroutine Preemption:* Fertig reiterates that coroutines are not preemptible and require careful design to avoid long-running tasks that block other coroutines. * *1:08:47* *Coroutines and Boost.Asio:* He suggests that the upcoming C++26 `sender/receiver` feature might be a better fit for Boost.Asio integration than coroutines. * *1:16:05* *Typical Use Cases:* Fertig highlights callback replacement and event handling as common scenarios where coroutines excel. * *1:21:04* *Coroutines in Embedded Systems:* He clarifies that coroutines do not require special OS support, making them suitable for embedded systems with limited resources. The primary requirement is heap access for storing coroutine state. * *1:23:12* *Stackful Coroutines in C++:* Fertig acknowledges the possibility of introducing stackful coroutines in the future if their benefits are clearly demonstrated. * *1:23:51* *Allocator Awareness:* While coroutines are not directly allocator-aware, they can utilize custom allocators through overloading `operator new` and `operator delete` in the promise type. i used gemini 1.5 pro Token count 19,459 / 1,048,576

where are conference materials published, e.g. codes?

if it's not broken, don't fix it. now there's so many ways to import and the build system is a mess -_-

So, adding new draw or serialize overloads for new ShapeConcepts just really needed? Maybe it should also be included to implementation details of the Shape with a templated version.

36:07 I may be mistaken, but I think currently such reinterpret_cast from buffer.data() is technically an UB unless std::launder() is used. Technically, because apparently popular compilers don't require std::launder() in this case. See P3006R0 "Launder less".

Cool

Great talk, thanks 🙏

so is c++ worth learning hm.

Tehnically, "probability zero" doesn't imply "impossible".

37:05 - Interesting Example. I taught my students that in C# the Random class actually took the time, so in order to make it work you need to initialize an instance and reuse the same instance. Or else you'll be getting bugs because it generates the same number.

Great talk! Well done, and thank you!

Write a thick client, write your own serializers, implement custom schema publishing... Hmm, I wonder what features from gRPC are actually there after all this and what is even the point of using such a heavy-duty library in this context. And yes, I am genuinely curious.

*Abstract* This presentation explores gRPC, a modern Remote Procedure Call (RPC) framework designed for high-performance distributed systems. It begins with an overview of gRPC's features, including cross-platform support, load balancing, and authentication. The presentation then delves into Protobuf, the language-neutral serialization mechanism commonly used with gRPC. The core of the presentation covers both the standard approach to using gRPC and a novel alternative. The standard approach involves defining services in `.proto` files, generating code, and directly using gRPC's service APIs. The alternative approach introduces a custom library called 'mygrpc,' which wraps gRPC and Protobuf. This library simplifies development by: * *Hiding gRPC and Protobuf Internals:* Users interact with custom APIs, not raw gRPC or Protobuf. * *Providing Generic Services:* A single generic service definition replaces complex `.proto` files. * *Streamlining RPC Calls:* The library handles reactors, message chunking, and data serialization. The presentation concludes with a summary of the benefits and drawbacks of this alternative approach, noting increased flexibility and cleaner code, but also the overhead of maintaining custom serializers. *Keywords:* gRPC, Protobuf, RPC, Remote Procedure Calls, distributed systems, serialization, C++

Massively Cool.

7:48 Interfaces must always be non-virtual, even if we use good old inheritance-based runtime polymorphism.

Defining operator == is still useful when also defining operator <=> because operator == (and operator !=) can return early when 2 containers don't have the same size.

6:30 what a brilliant illustration of time travel debugging by time travelling through his presentation. 🥇

std::memcpy is not data-race safe as per the standard. you could use std::atomic_ref<std::byte> to read/wrie individual bytes of the object.

Hah, what a coincidence! Early this month i JUST gave a talk on FOSDEM about the internal workings of GDB's inbuilt time travel debugging and how we're taking baby steps in improving it On an interesting note, the hardware watchpoint was fixed recently, and will no longe be a bug in GDB 15 :)

23:35 24:00 monitor builder 24.35 monitor 27:18

Ubuntu 20.04 has some different configuration which makes following this example very difficult. I didn't get the same crash reason the presenter got. Ubuntu 20.04 has some stack protection. "*** stack smashing detected ***: terminated"

ok, after the joy of minute 58, i'll stay on std::partition to prefilter.

does this apply also to userland(green) threads - like in boost fiber ?

With all due respect , following-up the other comments, it might look like there are some old-school developers a bit grumpy to have to learn stuff. Regarding the logic of the talk, I can’t follow along why (1) begin MUST be O(1) generally, even more when taking into that there was something special with fwdlist before ranges already, (2) why begin in a view must have the same semantics than in a container. In other words, if one is applying a filter to a collection and then surprised that it needs to iterate through it… 🤷🏻‍♂️ In any case, excellent talk from Nico as usual, top learning material. It is essential to make these parts also visible and talk about them.

As alway Klaus provides an interesting approach for C++ development. 😀

Abstract: Test-Driven Development (TDD) has been acknowledged for its effectiveness in reducing development time and error rates, leading to widespread adoption in many C++ projects. However, its application in embedded C++ development, especially those involving microcontrollers with significant hardware dependence, presents unique challenges. At the Meeting C++ 2023, Daniel Penning addresses the obstacles and opportunities for integrating TDD in microcontroller-based development. The talk delves into the dual-target approach, advocated by James Grenning, which recommends running unit tests both on microcontrollers (On Target) and personal computers (Off Target). Despite its advantages, this method reveals limitations when dealing with hardware-related code such as drivers. Penning introduces open loop testing to complement dual targeting, an innovative method where external microcontroller interfaces are mimicked using mocks and stubs. This methodology facilitates a practical TDD workflow that enables developers to reap the full benefits of TDD in their microcontroller development process. The talk not only illustrates how the dual-target approach can be built using open source solutions but also compares the additional advantages provided by commercial alternatives. It also touches upon the significance of TDD in embedded development, emphasizing the need for quick, automated feedback loops essential for TDD efficacy. Demonstrations within the presentation showcase the implementation of open loop testing, using a Robot Framework to script tests at the pin level for direct hardware interaction. Penning provides a thorough analysis of the nuances in off-target and on-target testing, detailing their respective limitations and how open loop testing fills the gaps for a comprehensive TDD practice. Finally, the session concludes with an insightful Q&A that explores related topics such as hardware verification, functional safety, and integration testing, and discusses industry trends in hardware abstraction layer and driver development. This presentation serves as a crucial guide for software engineers and project managers in embedded systems looking to refine their development practices with TDD, improving their product quality and reliability in a domain where traditional testing methods often fall short. Chapter Titles I. Fundamentals of TDD in Embedded Systems - 00:00 Introduction to TDD and Embedded Software Development - 01:59 The Importance and Challenges of TDD in Embedded Systems II. Testing Strategies for Embedded Software - 04:22 Testing Embedded Software Off-Target vs. On-Target - 07:26 Establishing Off Target Testing in Embedded Development - 11:41 Limitations and Risks of Off Target Testing - 14:33 Testing Hardware Dependent Code - 15:34 On Target Testing III. Advanced Testing Techniques and Tools - 17:09 State-of-the-Art in Testing: Pin Behavior - 19:13 Challenges with Manual and Register-Based Testing - 25:06 Open Loop Testing: A New Approach - 28:00 Demonstration of Open Loop Testing IV. Practical Application and Case Studies - 31:09 Configuration and Initial Test - 33:10 Multiple Byte Reception and Hardware Interaction - 35:19 Implementation Adjustments and Debugging V. Summation and Addressing Complex Testing Scenarios - 39:01 Summary and QA Session - 45:12 Concerning Emulation and Real-Time Testing - 47:50 Challenges in Hardware Verification VI. Ensuring Functional Safety and System Integration - 48:35 Functional Safety and Testing Approaches - 50:15 Integration Testing and Developer Feedback - 51:34 Hardware Abstraction Layer and Driver Development VII. Closing Remarks - 53:15 Conclusion

Depressing is the only way to describe this. We've waited so long for ranges because they would make it so much harder to make programming errors, and instead they've gone and made it more likely to make errors. It's a shame they didn't make the easy case easy and the complex case possible and instead made the easy (common) case hard and the complex (rare) case easy. The only safe way to teach this is the simple "don't use ranges", which sucks.

So that's how these "script extender" DLL mods for some games work, interesting SKSE for Skyrim, BG3se for Baldur's Gate 3, CET for CP2077, ... sadly these are never available on Linux/MacOS I guess there's no DLL there I'll never get NativeCameraTweaks on BG3 MacOS version, rip

I would agree with the "prefer std::ranges over std::", however, there is std::ranges::less (and the other suite of comparators), which you definitely shouldn't use, and you should use C++14 deducing versions of std::less (and the rest of the comparators).

That was depressing. Today I learned that ranges are a completely broken feature. It's so frustrating listening to others justify all the undefined behavior in the standard. They make it sound like it's necessary to not suffer undue performance loss on various platforms, but clauses like the one shown at 46:55 show how ridiculous that excuse is. We have to stop adding broken features into c++. And then we turn around and wonder why rust is gaining traction...

*Abstract* While C++20's filter view offers a powerful way to process data, its design compromises usability and can lead to surprising errors. This presentation reveals the internal mechanisms of views, explaining how cached 'begin' operations limit const correctness and create unexpected issues like runtime errors or undefined behavior. The 'filter' view, in particular, presents challenges due to its differing behavior on temporary and non-temporary objects. The speaker explores the trade-offs made in filter view design, raises concerns about broken const protection, and highlights the pitfalls developers need to be aware of. The presentation also critiques the C++ Standard Committee's decisions, advocating for changes to mitigate these problems. *Key Points* - *Issues with Filter Views:* Filter views can lead to unpredictable behavior and errors due to cached 'begin' operations and inconsistent const propagation. - *Broken Const Correctness:* Design decisions in filter views make it difficult to maintain const correctness, causing unexpected risks and undefined behavior. - *Internal Design Limitations:* View design, particularly around caching, imposes constraints on view usage, which may conflict with common coding practices. - *Standard Committee Debate:* There appears to be internal debate and disagreement within the C++ Standard Committee on how to address these problems. - *Call for User Feedback:* The presenter encourages viewers to provide feedback and bug reports to help facilitate a fix to these issues within the C++ standard. *Chapter Titles* *Chapter 1: Introduction to C++ Views* - 0:00 Introduction to C++ Views - 1:11 Basics of Using Views - 3:41 More Examples of C++ Views *Chapter 2: How Views Work* - 6:04 Understanding How Views Work - 9:23 Internal Structure of Views - 11:00 Iteration and Value Creation with Views - 14:30 Important Considerations *Chapter 3: Views and Performance* - 15:52 C++ Views Performance - 17:02 Performance Considerations with Views - 17:35 Performance Differences: Drop View - 19:44 Performance Differences: Filter View - 21:38 The Standard Template Library and Performance - 22:42 API Choices for Views *Chapter 4: Challenges and Pitfalls* - 28:18 Performance Constraints and Solutions - 31:04 Caching Mechanisms in C++ Views - 33:39 Caching of 'begin' with Cost Implications - 37:10 Consequences of Caching of 'begin' - 39:37 Workarounds and Issues - 44:39 Issues with a 'filter' View Example - 49:02 More Problems with a 'drop' View Example *Chapter 5: The 'filter' View Controversy* - 51:22 Broken 'const' Protection, Caching, and Design Concerns - 52:58 Understanding the 'filter' View - 55:14 Problematic Consequences of View Design - 56:47 How to (Not) Use a 'filter' View - 58:07 Lingering Consequences and Frustrations - 59:59 Call to Action *Summary* *Introduction to C++ Views* - 0:02 Introduction to C++ views technology. - 0:15 Discussion of important things to know about views. - 0:38 Focus on the filter view and its appropriate use. *Basics of Using Views* - 1:11 Example of a vector container. - 1:24 Example of set container. - 1:37 Introduction to generic print function - 2:03 Using Auto with constraints for generic code. - 2:19 Examples of the `take` view. - 2:42 Using pipelines for cleaner view syntax. - 3:16 `transform` view in combination with filter. *More Examples of C++ Views* - 3:41 Views offer a powerful way to process data. - 3:47 Example using a map to store key-value pairs. - 4:19 Filtering values within a map structure. - 5:23 `iota` view provides generated number sequences. *Understanding How Views Work* - 6:04 The importance of understanding internal mechanisms - 6:10 Views differ fundamentally from Unix pipes. - 6:17 Container iteration based on the begin/end interface. - 7:28 Range-based for loop leverages this container interface. - 8:05 Applying the same interface to views. - 8:19 Example of filter and transformation views. *Internal Structure of Views* - 9:23 Pipelines are syntactic sugar on nested view applications. - 9:28 Views don't generate elements upfront, focus on processing description. - 9:54 Views form a wrapper-like data structure. - 10:47 Iteration remains consistent but uses the view’s begin/end *Iteration and Value Creation with Views* - 11:00 Value creation and printing occur during iteration. - 11:15 Example of a view's begin call cascading down. - 12:07 The filter view may skip multiple elements. - 12:44 Filter views require both position and value, impacting cost. - 13:45 Cascading calls from star (to access value) through the views. - 14:10 Transformations act on values when accessed. *Important Considerations* - 14:30 Performance impact of filter view's begin operation. - 15:06 The begin operation cost depends on the underlying data structure. *C++ Views Performance* - 15:52 Discussion on how value transformations impact iterations. - 16:07 Example of how the filter view handles values that don't fit the criteria. - 16:35 The end iterator returned by a view signals completion. *Performance Considerations with Views*

The nordic shorts dude codes????

Yes.

I have limited experience with ranges, but I think I agree that views would be better off without caching. As a counter-argument to the committee for the case where a view is used twice, could we use the same subrange trick to eagerly compute begin instead of caching? I.e. in the rare case you want to re-use a view twice and want to cache begin, do it manually by wrapping your view in a subrange? I think it would be easier to teach too.

eagle burger lol

Would've probably reverse engineered bejeweled instead of relying on image data but this seems more versatile for other games if you dont want to reverse them all. For the algorithm an improvement could be MinMax + AlphaBeta pruning but without knowing what stones move in next that becomes a much much smaller improvement. Can obviously reverse engineer that too :P

Brilliant!

I remember that my colleague was tasked to chose between CUDA and OpenCL some 10 years ago. He liked OpenCL much more, because it allowed him to run code on both cards. But then it turned out that AMD did not support running OpenCL headless, without X server running and screen connected. Also CUDA was slightly more consistent. And that's how OpenCL was removed from feasible standards. It's hard to get also the usability and reliability right, even if the idea is great, I guess.

*Abstract* In the talk "A Smooth Introduction to SYCL for C++20 aficionados" at Meeting C++ 2023, Joel Falcou, an associate professor and co-founder of a C++ and HPC training company, delves into the challenges faced by developers in the era of performance-driven architectures such as GPUs and FPGAs. Addressing the need for efficient programming without compromising the elegance of C++20, Falcou introduces SYCL, an open standard for cross-platform programming that enables developers to target a variety of accelerators. The presentation provides insight into SYCL's compatibility with C++ syntax, its programming model, and how it facilitates device connection and management through 'queue' objects and memory management techniques. Additionally, Falcou outlines SYCL's support for hierarchical parallelism and its implementation in scientific computing, specifically particle physics. Falcou discusses the use of a custom C++20 library called Kiwaku, which is designed for multidimensional data storage and processing. The library leverages C++20 features and concepts to provide efficient execution contexts, data views, and algorithmic execution. The talk also touches on OneAPI's role as the implementation of SYCL used for the presentation and alternatives to Intel's implementation. Furthermore, Falcou emphasizes SYCL's ease of use, deployability, and forward-thinking approach to concepts and type handling. He concludes with remarks on SYCL's documentation, hardware support updates, and encourages the use of SYCL for working with accelerators. The talk ends with a discussion on device selection, fallback implementations, and CPU support, along with implementation recommendations for those getting started with SYCL. *Chapter Titles* *Chapter 1: Introduction to SYCL and Computing Paradigms* - 0:00 Introduction and Background - 1:24 Overview of Computing Challenges and Tools - 3:39 Introduction to SYCL (Pronounced 'sickle') - 6:06 OneAPI and Supporting Companies *Chapter 2: Understanding the SYCL Programming Model* - 7:48 Programming Model and Device Connection - 10:38 Device Selection and Queue Management - 14:22 Introduction to Shared Memory and Parallel Operations - 15:46 Synchronization and Memory Management *Chapter 3: Optimizing Memory Operations in SYCL* - 17:35 Improving Memory Operations with Buffers - 19:57 Automatic Data Transfer with Buffer Destruction *Chapter 4: Advanced Parallelism Techniques in SYCL* - 21:11 Leveraging Hierarchical Parallelism - 22:53 Implementing Algorithms with Hierarchical Parallelism - 24:51 Utilizing SYCL-based Parallel STL Implementation *Chapter 5: SYCL Applications in High-Performance Computing* - 26:00 Application in Scientific Computing - 28:16 Overview of Accelerated Computation in Particle Physics *Chapter 6: The Role of Custom C++ Libraries in Computational Efficiency* - 29:43 Advantages of a Custom C++ Library - 31:09 Utilizing C++20 Features and Concepts - 31:57 Data Views and Parametric Concepts - 33:40 Algorithmic Execution and Slicing Techniques *Chapter 7: Performance Considerations Across Different Hardware* - 35:38 Contexts and Performance on Different Hardware - 37:31 Flexibility and Extensibility of the Library - 39:00 Concluding Remarks on Acceleration APIs and the Future *Chapter 8: Compilation Aspects and Device Handling* - 42:22 Compilation Timing and Options - 45:08 Device Selection and Ranking - 48:04 Fallback Implementations and Targeting Specific Compilers - 49:53 CPU Support and SIMD Vectorization - 53:16 Decoding the Secret String and Implementation Recommendations

The problem with sycl is it's basically *another* standard, on top of what should have already *been* the open standard (OpenCL) which was knee capped by Nvidia a decade ago. Sycl is trying to circumvent this by just running on top of the other APIs, but the problem is that to do this, it lacks a bunch of performance critical features, and while the presenter claims it's easy to use, my experience, (as well as *many* other people) has been the exact opposite, it takes a *looong* time to set up, hard to make libraries for, and hard to make re-producible environments for (if you're not using Intel). And OneAPI might be easier to set up, but now you've effectively got *another* standard, because there are things in OneAPI not supported by Sycl on other platforms, and TBH, I'm not interested in *only* supporting Intel. Then there's the whole graphics interop issue... There *is* a cross platform solution to compute, but when I mention it, people on the Sycl end tend to wince. It's Vulkan. It works on mobile, Windows, Linux, some consoles even, and through MoltenVK, works on Apple as well,. which IIRC Sycl *still* doesn't support. It also supports those platforms *with out* translation layers. Sycl does not have the *modern* hardware support and featureset required to run applications at the speeds we require, Vulkan, for better or worse, does. The last things vulkan needs (which I don't even think Sycl suppports) are storage class aware physical pointers with reinterpret cast/pointer arithmetic (this is available for global memory storage classes only currently) and *device side enqueue*, which this year AMD submitted an extension for which will be even more powerful than it was in OpenCL, and no longer buggy and unusable like it was there as well github.com/KhronosGroup/Vulkan-Docs/blob/main/proposals/VK_AMDX_shader_enqueue.adoc.

*Abstract:* Test-Driven Development (TDD) has been acknowledged for its effectiveness in reducing development time and error rates, leading to widespread adoption in many C++ projects. However, its application in embedded C++ development, especially those involving microcontrollers with significant hardware dependence, presents unique challenges. At the Meeting C++ 2023, Daniel Penning addresses the obstacles and opportunities for integrating TDD in microcontroller-based development. The talk delves into the dual-target approach, advocated by James Grenning, which recommends running unit tests both on microcontrollers (On Target) and personal computers (Off Target). Despite its advantages, this method reveals limitations when dealing with hardware-related code such as drivers. Penning introduces open loop testing to complement dual targeting, an innovative method where external microcontroller interfaces are mimicked using mocks and stubs. This methodology facilitates a practical TDD workflow that enables developers to reap the full benefits of TDD in their microcontroller development process. The talk not only illustrates how the dual-target approach can be built using open source solutions but also compares the additional advantages provided by commercial alternatives. It also touches upon the significance of TDD in embedded development, emphasizing the need for quick, automated feedback loops essential for TDD efficacy. Demonstrations within the presentation showcase the implementation of open loop testing, using a Robot Framework to script tests at the pin level for direct hardware interaction. Penning provides a thorough analysis of the nuances in off-target and on-target testing, detailing their respective limitations and how open loop testing fills the gaps for a comprehensive TDD practice. Finally, the session concludes with an insightful Q&A that explores related topics such as hardware verification, functional safety, and integration testing, and discusses industry trends in hardware abstraction layer and driver development. This presentation serves as a crucial guide for software engineers and project managers in embedded systems looking to refine their development practices with TDD, improving their product quality and reliability in a domain where traditional testing methods often fall short. *Chapter Titles* I. Fundamentals of TDD in Embedded Systems - 00:00 Introduction to TDD and Embedded Software Development - 01:59 The Importance and Challenges of TDD in Embedded Systems II. Testing Strategies for Embedded Software - 04:22 Testing Embedded Software Off-Target vs. On-Target - 07:26 Establishing Off Target Testing in Embedded Development - 11:41 Limitations and Risks of Off Target Testing - 14:33 Testing Hardware Dependent Code - 15:34 On Target Testing III. Advanced Testing Techniques and Tools - 17:09 State-of-the-Art in Testing: Pin Behavior - 19:13 Challenges with Manual and Register-Based Testing - 25:06 Open Loop Testing: A New Approach - 28:00 Demonstration of Open Loop Testing IV. Practical Application and Case Studies - 31:09 Configuration and Initial Test - 33:10 Multiple Byte Reception and Hardware Interaction - 35:19 Implementation Adjustments and Debugging V. Summation and Addressing Complex Testing Scenarios - 39:01 Summary and QA Session - 45:12 Concerning Emulation and Real-Time Testing - 47:50 Challenges in Hardware Verification VI. Ensuring Functional Safety and System Integration - 48:35 Functional Safety and Testing Approaches - 50:15 Integration Testing and Developer Feedback - 51:34 Hardware Abstraction Layer and Driver Development VII. Closing Remarks - 53:15 Conclusion *Summary* *Introduction to TDD and Embedded Software Development* - 00:00 Introduction to the audience's familiarity with Test Driven Development (TDD) and experience with microcontrollers. - 00:33 Background of the speaker's experience in embedded software engineering. - 00:58 Contrast between common testing practices in traditional software development and the lack of unit testing and TDD in embedded systems. - 01:22 Current state of TDD in deeply embedded projects. - 01:44 Aim of the talk to discuss the obstacles of using TDD in embedded systems, present the state of the art, and suggest improvements. *The Importance and Challenges of TDD in Embedded Systems* - 01:59 The significance of the TDD micro cycle for software development. - 02:39 Necessity of a quick and automated feedback loop in TDD. - 02:52 Popularity of TDD through Kent Beck's book on the subject. - 03:04 Differences in feedback mechanisms between traditional software and embedded systems. - 03:36 In-depth explanation of the challenges in testing embedded systems. - 04:09 The standard practice of trying code on deeply embedded systems. *Testing Embedded Software Off-Target vs. On-Target* - 04:22 Unit testing in traditional software and the core principle of testing isolated code parts. - 04:53 Question of whether unit testing and abstraction can be applied to embedded systems. - 05:07 James Grenning's book on TDD for embedded C, introducing dual-target testing. - 05:40 Detailed explanation of dual-target testing: running unit tests on microcontrollers (On Target) and on PCs (Off Target). - 07:21 Types of code suitable for Off Target and On Target testing. *Establishing Off Target Testing in Embedded Development* - 07:26 Requirements for Off Target testing, including a compatible compiler and decoupling from hardware dependencies. - 08:03 Generalizing code to allow Off Target testing using standard headers. - 09:12 Example of a unit test for checksum calculation. - 09:55 Need for a setup allowing Off Target testing, including a toolchain and a unit test framework. - 11:00 Critical need to decouple code from hardware dependencies, especially in legacy projects. - 11:27 Benefits and speed of the TDD feedback loop provided by Off Target testing. *Limitations and Risks of Off Target Testing* - 11:41 The limitations and risks of relying solely on Off Target testing. - 11:53 Example showing different results between Off Target and On Target due to compiler differences. - 13:00 Definition of unspecified behavior and potential differences in program behavior. - 13:37 Additional risks including hardware defects and toolchain bugs. - 14:27 Necessity of On Target testing to mitigate risks and ensure object code is tested. *Testing Hardware Dependent Code* - 14:33 The issue of testing code that depends on microcontroller hardware features. - 14:40 Example of hardware-dependent code on an STM32 microcontroller. - 15:19 Possibility of unit testing hardware-dependent code through abstraction. *On Target Testing* - 15:34 Discusses integrating a test framework with an embedded compiler. - 15:46 Notes the challenge of older compilers not supporting modern C++ features. - 15:58 Suggests using C testing libraries like Unity or cppu test for compatibility. - 16:05 Recommends selecting a unit test framework that compiles with an ancient cross compiler. - 16:23 Explains how to adapt a unit test framework to output results via a serial line for PC display. - 16:40 Emphasizes the possibility of quick automated feedback and the importance of a good setup. - 16:47 Mentions the typical bottleneck in testing is microcontroller flashing but it can be optimized. *State-of-the-Art in Testing: Pin Behavior* - 17:09 Introduces the concept of testing pin behavior in embedded systems. - 17:33 Explains that testing should confirm the interactions through microcontroller pins. - 18:01 Describes a test for sending bytes over UART using the STM32 HAL library. - 18:34 Discusses the manual testing process using logic analyzers and other equipment. - 18:53 Highlights the difficulties of accessing pins and the cumbersome nature of manual testing. *Challenges with Manual and Register-Based Testing* - 19:13 Critiques the manual-based testing approach. - 19:26 Introduces register-based testing as an industry standard but flawed in the context of TDD. - 19:54 Explains the complexity of STM32 reference manuals and using them for register-based testing. - 20:29 Provides an example of testing UART initialization through register values. - 21:17 Describes the complex process of determining register values from the reference manual. - 23:25 Discusses why register-based testing is problematic for TDD due to its white-box nature. - 24:10 Illustrates an issue where tests fail despite correct functionality due to register value changes. *Open Loop Testing: A New Approach* - 25:06 Introduces open loop testing with three main requirements: accessible pins, code, and periphery. - 25:29 Describes the process of writing tests for hardware interactions at the pin level. - 25:50 Highlights that the test system should integrate the specific microcontroller used in the product. - 26:41 Explains that the test system allows writing tests to interact with hardware peripherals directly. - 27:00 Uses Robot Framework for writing tests in open loop test systems. *Demonstration of Open Loop Testing* - 28:00 Demonstrates an open loop test using Visual Studio Code connected to a physical test system. - 28:39 Details a test scenario for receiving UART data on a microcontroller. - 29:04 Shows C++ code for initializing UART and registering a function to process received characters. - 29:50 Explains the requirement for the test system to be able to call functions on the microcontroller chip. - 30:28 Describes the test sequence setup in Robot Framework, including flashing firmware and periphery initialization.

I was a bit skeptical at first, but this analogy she used through whole presentation is actually a great way to present this!

i'm surprised it lets you swap with an empty list, but then i shouldn't be surprised because its C++ lol