Just got my first LGTM (PR merged into a major C++ library)

(https://preview.redd.it/just-got-my-first-lgtm-pr-merged-into-major-c-library-v0-l3a9cdzguo8h1.png?width=1919&format=png&auto=webp&s=8c324544c9ca43757f982ddf084badcd5ad29c68)
Just wanted to share a not so big of a deal but major personal milestone, i just got my very first pull request merged into the STEllAR Group's HPX parallel runtime library.

I'm an 18 year old undergrad at NITK, and diving into a high performance C++ codebase was honestly pretty intimidating. The bug I was tracking down caused the compiler to completely crash when handling certain parallel operations.

I spent the last few weeks digging through the code, rewriting the validation logic so it safely falls back to a sequential path when it needs to, and writing an automated test suite. Seeing all CI tests finally pass after a thorough code review was the best feeling ever.

The lead maintainer Harmut Kaiser was incredibly supportive and patient with me while i figured out the repos workflow and coding standards. Its wild to think that my code is officially a permanent part of the library now.

If anyone else is hesitant about jumping into open source, definitely go for it. The learning curve is brutal at first, but sticking with it and seeing it get merged makes so worth it.

Github: https://github.com/adhithyaragavan if anyone cares to check it out

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

Libc

So just to confirm my understanding: when I write C code with printf, the linker links my program against printf inside libc, because that function contains the implementation. The compiler itself doesn’t know the implementation details of printf, so it relies on the linker to resolve it and connect it to the actual function in libc. Then, when we look at the implementation, we find that it does formatting, buffering, and then it calls write internally. And write itself contains some assembly that invokes a system call to reach the kernel right?

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

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