An independently reverse engineered C++20 AirPlay 2 sender

I ended up reverse engineering Apple's AirPlay 2 realtime audio sender path and writing it in C++20, and thought the C++ side might be interesting here. it's lifted out of a shipping product and runs daily against a real Apple TV 4K and a MacBook, but it's not yet a turnkey library. The sender still does its networking via Qt, and the roadmap is to move that behind a small transport interface so it builds without Qt. The crypto and wire format core already builds standalone. Corrections very welcome, especially on the security scoping (receiver identity auth is currently log and continue, which I document). https://github.com/akustikrausch/airplay2-sender-cpp

https://redd.it/1ucf7fr
@r_cpp

Boost Review for Capy and Corosio Begins Today

The Boost Formal Review of the Corosio and Capy libraries will begin on June 23, 2026 and will conclude on July 7, 2026.

The review manager for these reviews will be Jeff Garland and the libraries are brought to you by Vinnie Falco. Since this is a two library review the period is somewhat extended from normal.

# Capy

Capy is a coroutine foundation library providing task types, execution contexts, executors, asynchronous synchronization primitives, buffer abstractions, and coroutine composition facilities. It serves as the execution and asynchronous programming substrate upon which Corosio is built.

Repository:

Capy[ GitHub Repository](https://github.com/cppalliance/capy)
docs

# Corosio

Corosio is a coroutine-native asynchronous I/O library for C++20. It provides networking and I/O facilities designed specifically for coroutines, with awaitable operations, executor affinity, cancellation support, and cross-platform implementations based on IOCP, epoll, and kqueue.

Repository:

[Corosio GitHub Repository](https://github.com/cppalliance/corosio)
docs

# Review Questions

Potential reviewers are encouraged to consider the following questions:

1. What is your evaluation of the usefulness of the libraries?
2. What is your evaluation of the design?
3. What is your evaluation of the implementation?
4. What is your evaluation of the documentation?
5. Have you used either or both libraries? What was your experience?
6. Are the libraries ready for inclusion in Boost?
7. If not, what changes would you recommend before acceptance?
8. Do the libraries fit well within the existing Boost ecosystem?
9. Are there API, naming, usability, extensibility, or implementation concerns that should be addressed?

# How to Participate

Please post your review to the Boost Developers mailing list. Reviews from both experienced Boost contributors and first-time reviewers are encouraged. Reports based on real-world usage, experimentation, code inspection, and documentation review are all valuable contributions.

At the conclusion of the review period, the review manager will consider all feedback and determine whether the libraries should be accepted into Boost.

We look forward to your participation in this review.

If you have any questions or need assistance please let me know.

Matt - Boost Review Wizard

https://redd.it/1uck5ne
@r_cpp

What’s your preferred setup for large C++ projects?

trying to put together something that won’t turn into a maintenance nightmare as we scale. sitting at aroubd 200k lines right now with a team of roughly 8 engineers, and were starting to hit some friction. not a disaster, but enough that id rather sort it out now than retrofit later.

current setup is cmake + make, gcc, no real dependency manager (vendoring almost everything),
ccache loosely configured,github actions for CI. it works.full builds are running around 25-30 minutes on a cold runner, which matches roughly what CI sees since we’re mostly doing clean builds on PRs. that’s the sore spot.

a few things i’m weighing: ninja over make at this sclae feels obvious but i want to hear it confirmed, vcpkg vs conan since we have mix of windows and linux devs, wether ccache is doing us any favors on CI or just on local machines. also debating clang vs gcc but no strong reason either way yet.

not looking for the perfect stack, just what people are actually running om codebases that grew past the point of simplicity. what broke first and what actually fixed it?

https://redd.it/1uckkfy
@r_cpp

New C++ Conference Videos Released This Month - June 2026 (Updated to Include Videos Released 2026-06-15 - 2026-06-21)

**C++Online**

2026-06-15 - 2026-06-21

* The Art of API Design - Christoph Stiller - [https://youtu.be/d5djrT4qfHc](https://youtu.be/d5djrT4qfHc)
* Top-Performance Genetic Programming - Can Only C++ Get You There? - Eduardo Madrid - [https://youtu.be/oBQDe56Yi3Q](https://youtu.be/oBQDe56Yi3Q)

2026-06-08 - 2026-06-14

* Monads Meet Mutexes - Arne Berger - [https://youtu.be/AisGDOoF82U](https://youtu.be/AisGDOoF82U)
* Lock-free Queues in the Multiverse of Madness - Dave Rowland - [https://youtu.be/eHmjkFdQl00](https://youtu.be/eHmjkFdQl00)

2026-06-01 - 2026-06-07

* Writing C++ Code is Challenging, Writing Performant C++ Code is Daunting - Dmitrii Radivonchik - [https://youtu.be/R2sm9mailuU](https://youtu.be/R2sm9mailuU)
* Case Study - Purging Undefined Behavior and Intel Assumptions in a Legacy Codebase - Roth Michaels - [https://youtu.be/H-dHTeSR\_n8](https://youtu.be/H-dHTeSR_n8)

**ADC**

2026-06-15 - 2026-06-21

* Scripting Architecture for a DAW-like Plugin - How we Implemented Lua and JavaScript Scripting for Synthesizer V Studio - Kanru Hua - [https://youtu.be/CKOvmBRdHAA](https://youtu.be/CKOvmBRdHAA)
* Patterns of Practice: Live Coding and the Logic of South Asian Traditional Music - Abhinay Khoparzi - [https://youtu.be/n0-XpUhZ7Dc](https://youtu.be/n0-XpUhZ7Dc)
* ADC 2015 to 2035 - Looking Back at 10 Years of Audio Dev, and Peering Forward at the Next 10 - Julian Storer - [https://youtu.be/WvVur2\_aGHU](https://youtu.be/WvVur2_aGHU)
* From DAW to Game Engine - Unfiltered Creativity - Nikhil Dahake - [https://youtu.be/5PtMWJLFjyo](https://youtu.be/5PtMWJLFjyo)

2026-06-08 - 2026-06-14

* Low Latency Android Audio with improved CPU Performance - Phil Burk - [https://youtu.be/DtBrKEu0R0g](https://youtu.be/DtBrKEu0R0g)
* Linux as the Conductor - Driving Pre-Compiled Audio DSP Kernels on C7x for Real-Time Processing - Vishnu Pratap Singh - [https://youtu.be/Auq9WnHNtPo](https://youtu.be/Auq9WnHNtPo)
* Overview of Granular Synthesis - Avrosh Kumar - [https://youtu.be/QpBV24nWg2M](https://youtu.be/QpBV24nWg2M)
* The Agentic Symphony - Multi-Agent Collaboration for Emergent Musical Composition - Meera Sundar - [https://youtu.be/QMUXoImgTIA](https://youtu.be/QMUXoImgTIA)

2026-06-01 - 2026-06-07

* Beyond the DAW - Designing a Procedural Sequencer Powered by Music-Theory - Romy Dugue & Cecill Etheredge - [https://youtu.be/48sH4wQUDAs](https://youtu.be/48sH4wQUDAs)
* From DAW Users to Audio Developers - Teaching JUCE to Creative Minds - Milap Rane - [https://youtu.be/200UrugEanY](https://youtu.be/200UrugEanY)
* Music Design and Systems - Achieving Inaudibly Complex Systems in Video Games - Liam Peacock - [https://youtu.be/R6raBvCNsQo](https://youtu.be/R6raBvCNsQo)
* Developing for Avid’s Audio Ecosystem - Rob Majors - [https://youtu.be/91-7YWVKRE4](https://youtu.be/91-7YWVKRE4)

**CppCon**

2026-06-01 - 2026-06-07

* Lightning Talk: Navigating Code Reviews as a Code Author - Ben Deane - [https://youtu.be/zygtgvHp\_MM](https://youtu.be/zygtgvHp_MM)
* Lightning Talk: Eight Consteval Queens and Compile-Time Printing - Sagnik Bhattacharya - [https://youtu.be/gNPhJrXLiIs](https://youtu.be/gNPhJrXLiIs)
* Instrumenting the Stack: Strategies for End-to-end Sanitizer Adoption - Damien Buhl - [https://youtu.be/TSrymTXw5w8](https://youtu.be/TSrymTXw5w8)

https://redd.it/1ucmu7i
@r_cpp

C++Online 2026 Keynote - I Fixed Move Semantics - Jason Turner
https://youtu.be/TJhMGS9sRlw

https://redd.it/1ucszuo
@r_cpp

I did a programme and uploaded in You Tube related to Cramer's rule for finding intersection points for 2D equations and plot it in C++ via GNU Plot.
https://youtu.be/F2BxeemH0IE?si=vAKX8i8uSR6L_xPz

https://redd.it/1uctm9c
@r_cpp

CppCast: Teaching C++ to Game Development Students in the Age of LLMs with Tom Tesch
https://cppcast.com/teaching_cpp_to_game_development_students_in_the_age_of_llms_with_tom_tesch/

https://redd.it/1ucxbo8
@r_cpp

C++ Lifetime-End Pointer-Zap and OOTA Progress
https://people.kernel.org/paulmck/c-pointer-zap-and-oota-progress

https://redd.it/1ud7zg5
@r_cpp

A first release of the program for Meeting C++ 2026
https://meetingcpp.com/meetingcpp/news/items/A-first-release-of-the-program-for-Meeting-Cpp-2026.html

https://redd.it/1udblca
@r_cpp

C++/WinRT being in maintenance mode means there is no way to develop a modern Windows app (WinUI) in C++?



https://redd.it/1udbgr9
@r_cpp

Removed by Reddit

Removed by Reddit on account of violating the [content policy. ]

https://redd.it/1udd0ql
@r_cpp

Reviewers wanted: Corosio & Capy (coroutine-native I/O + coroutine foundation for C++20) are entering Boost formal review

The Boost formal review of **Corosio** and **Capy** begins today (June 23) and runs through July 7. The esteemed Jeff Garland is the review manager (Jeff also managed the Boost.Asio review back in the day!).

**What these libraries are:**

* **Capy** is a coroutine foundation library providing task types, execution contexts, executors, async synchronization primitives, buffer abstractions, and coroutine composition facilities.
* **Corosio** is a coroutine-native async I/O library built on top of Capy. Networking and I/O operations are designed specifically for C++20 coroutines, including awaitable operations, executor affinity, cancellation support, and cross-platform backends (IOCP, epoll, kqueue).

Together they're a coroutine-native alternative to the callback first model. Async code reads like sync without giving up control over execution, cancellation, or performance.

**Why this review matters:** Boost currently doesn't have a coroutine-native I/O library. If these are accepted, they'd be the first.

If you have opinions about how async I/O should work in C++, now's your chance to put them on the record. Both experienced Boost contributors and first time reviewers are encouraged to participate.

**Links:**

* Corosio:[ GitHub](https://github.com/cppalliance/corosio) ·[ Docs](https://develop.corosio.cpp.al/corosio/index.html)
* Capy:[ GitHub](https://github.com/cppalliance/capy) ·[ Docs](https://develop.capy.cpp.al/capy/index.html)
* Submitting your review: [https://go.boost.org/4vrwPbP](https://go.boost.org/4vrwPbP)

https://redd.it/1udgx1y
@r_cpp

coroutil queues: library-agnostic queues for C++20 coroutines

Repo: [https://github.com/tzcnt/coro\util](https://github.com/tzcnt/coroutil)

Documentation: [https://fleetcode.com/oss/coro\util/docs/queues/index.html](https://fleetcode.com/oss/coroutil/docs/queues/index.html)

coro\util is a collection of data structures for C++20 coroutines that aren't tied to any task or executor library. Each structure is a template that accepts a policy object which binds it to your library of choice. I've include pre-configured adapters for several libraries: YACLib, Boost.Cobalt, Asio, Boost.Capy, libfork, concurrencpp, cppcoro, and libcoro. Adding a custom adapter for your own library is also relatively simple, and I've provided an agent prompt that automates it.

These queues were all written for the TooManyCooks framework, which as far as I know, has the most complete suite of general purpose async data structures of any publicly available library. This first edition only includes the 5 queues. The next batch will include the control structures (mutex, semaphore, etc.). I've decided to port them to be dependency-free in an effort to advance the interoperability of the C++20 coroutine ecosystem, which IMO is too siloed right now. I aim to demonstrate and evangelize for a style of code that is "sans-executor/task".

All of the queues are lock-free and wait-free on the fast path, and offer purely zero-copy operation. They have been rigorously tested and examined over their lifetime in TooManyCooks, and I believe them to be production-ready.

https://redd.it/1udi88p
@r_cpp

Two Indexed Hash Tables
https://vnmakarov.github.io/data%20structures/c/c++/open-source/2026/06/23/two-indexed-hash-tables.html

https://redd.it/1udfuxj
@r_cpp

Building an ECS: Data Oriented Hierarchies
https://ajmmertens.medium.com/building-an-ecs-data-oriented-hierarchies-62fb2847d100

https://redd.it/1udo1us
@r_cpp

A policy-based Dependency Injection framework for C++26

# Looking for feedback on a policy-based compile-time DI framework for C++20

I've been working on a compile-time Dependency Injection framework for modern C++:

https://github.com/steumarok/cppdimanager

The main idea is a policy-based resolution pipeline where object creation, dependency injection, casting, lifetime management and scope creation are handled by independent compile-time policies.

Unlike traditional DI containers that are primarily organized around service lifetimes, the framework is built around the following pipeline:

Requested Type
      ↓
Resolution Policy
      ↓
Creation Policy
      ↓
Injection Policy
      ↓
Cast Policy
      ↓
Returned Type

Current features:

- Constructor injection
- Member injection
- Interface-to-implementation mapping
- Hierarchical containers
- Request-scoped dependencies
- Scoped object lifetimes
- Automatic factory injection (std::function<T()>)
- Compile-time registries
- Configurable resolution and creation policies

Example web application:

https://github.com/steumarok/cppdimanager/blob/main/example.cpp

I'm particularly interested in feedback about:

- Overall API design
- Lifetime and scope management
- Policy architecture
- Compile-time vs runtime trade-offs
- Potential simplifications
- Missing features compared to existing DI frameworks

Suggestions and criticism are very welcome.

https://redd.it/1udrt86
@r_cpp

Automated Unit Testing On-The-Cheap
https://freshsources.com/code-capsules/test-part1/

https://redd.it/1udt4by
@r_cpp

The Barrier in C++ 20 - concurrent programming example...
https://som-itsolutions.hashnode.dev/the-barrier-in-c-20-concurrency-the-programmer-in-me-is-still-thriving

https://redd.it/1ueapjq
@r_cpp

How to Create an MCP Server Aspect in C/C++
https://github.com/IBM/tsar-mcp/blob/main/mcp/doc/MCPServer_AspectGuide.md

https://redd.it/1ued912
@r_cpp

From-scratch C++ correlation-filter tracker for object detection, tracking and redetection (without OpenCV) for Raspberry Pi 5 targeting 100+ FPS - looking for advice from people who've pushed similar systems further.

Hey everyone,

I'm currently building a **real-time object tracker from scratch in C++17** for the **Raspberry Pi 5**, with the goal of achieving **100+ FPS** on CPU-only hardware. The project is based on **correlation filters** and **FFT-based signal processing**, with **no machine learning, no neural networks, and no OpenCV** in the core tracking pipeline.

The motivation is simple: a straightforward OpenCV-based implementation on the Pi only gets me around **15 FPS**, which seems far below what this class of algorithms should be capable of. From both the literature and projects I've come across, the gap appears to be in implementation and system overhead rather than the underlying tracking method itself.

# Current approach

Right now, my plan is to build the pipeline around:

* A custom image loading and preprocessing path to avoid unnecessary OpenCV decode/resize overhead.
* **FFT-based correlation in the frequency domain** for fast target localization.
* Adaptive online filter updates so the tracker learns appearance changes over time.
* **PSR (Peak-to-Sidelobe Ratio)** based confidence estimation for occlusion and tracking failure detection.
* A modular architecture that can later be extended with features like scale estimation and automatic re-acquisition.

The area I'm currently spending the most time researching is the FFT layer. I'm trying to determine whether the best approach on the Pi 5 is:

* a hand-written radix-2 FFT,
* aggressive **NEON/SIMD** optimization,
* or using an existing library such as **FFTW** or **kissFFT**.

# Other approaches I've been studying

To better understand the design space, I've also been looking into modern transformer-based visual trackers. They jointly process information from a target template and a search region, making them much more semantically aware and capable of handling challenging scenarios such as partial occlusions or target disappearance with automatic re-acquisition. The downside is that they are significantly heavier computationally and can be difficult to deploy efficiently on constrained edge hardware.

On the more classical side, I'm currently reading about **Discriminative Scale Space Tracking (DSST)**. One of the main limitations of basic correlation-filter trackers is that they often assume the target size remains constant. DSST addresses this by learning a separate correlation filter across multiple image scales, allowing the tracker to estimate changes in object size efficiently while still maintaining real-time performance. It seems like an elegant way to improve robustness without giving up the speed advantages that make correlation filters attractive in the first place.

Exploring these different approaches has been interesting because they represent very different trade-offs: transformer-based methods emphasize robustness and semantic understanding, while correlation-filter methods prioritize simplicity, efficiency, and extremely high throughput.

# Looking for advice from people who've built similar systems

If you've worked on **correlation-filter trackers**, **embedded computer vision**, **real-time image processing**, **high-performance C++**, **drone tracking**, or **ARM optimization**, I'd really appreciate your perspective.

Some questions I'm hoping to get insight on:

* Where did the biggest performance bottleneck actually end up being? The FFT itself, memory layout, cache locality, camera capture, frame copies, synchronization, or something else entirely?
* On Raspberry Pi 5 specifically, is hand-vectorizing FFTs and pointwise complex operations with **NEON** worth the effort, or do mature FFT libraries generally outperform custom implementations?
* If you've implemented trackers such as **MOSSE**, **ASEF**, **UMACE**, **DSST**, or related adaptive correlation-filter methods, what optimizations made the biggest practical