Hello everyone!
Here’s the summary of our July session, San Diego C++ Meetup #87, held on Tuesday, July 22nd, 2026.
As always, if you missed the live session, the recording is up on our YouTube channel (link below once it’s shared publicly).
You can also find the specific Luma event details for this session right here: San Diego C++ Meetup #87
C++ Quiz
We opened with three quick ones from cppquiz.org:
- Conditional branching: a tricky one where a false condition sends execution down the H branch instead of G, and H ends up printing twice, once from the branch itself and once when the result gets printed. Sneaky if you’re skimming.
- std::promise / std::future: calling get_future() twice on the same promise isn’t allowed. The second call throws a future_error, since a promise can only ever hand out one future.
- Template specialization with variadics: the compiler picks the most specialized match every time. One argument goes to the single-type overload, two or more go to the variadic pack version. No ambiguity, even though it looks confusing at first glance.
Filtering Containers, the Modern Way
This was the main event: how many ways does the standard library give you to keep only the elements of a container that match a predicate? Turns out, a lot. We walked through several:
- copy_if + back_inserter (C++11): the classic. Simple, but if you don’t reserve capacity up front, you’re at the mercy of reallocations. Worth calling out specifically because this is exactly the kind of detail that’s easy to miss when reviewing AI-generated code, since it compiles and runs fine, it’s just not as efficient as it could be.
- Erase-remove idiom: works, but means copying the whole container up front before trimming it down. Usually not the best tradeoff.
- Ranges ( views::filter): the nicer modern option. No copying happens until you actually iterate. You pipe the container through the filter and get a lazy view back. Once it clicks, it composes really well and reads close to plain English.
- Generators (coroutine-based): pull one element at a time on demand. Powerful, but overkill unless you specifically need that shape. Not a default choice.
The recommendation: reach for C++23 ranges by default. If you’re stuck on C++17 or C++20 without range-v3, copy_if with back_inserter is fine as long as you’re reserving properly. Either way, the erase-remove idiom can probably retire.
Safe Buffer Passing with std::span
Second half of the night was about std::span, still one of my favorite tools for writing safe, container-agnostic buffer-passing code.
The core problem: a lot of APIs (plenty of them straight out of the C++ Core Guidelines) still pass a raw pointer and a length as two separate parameters. It works, but it’s easy to get wrong and doesn’t self-document. std::span gives you a single view type that adapts to std::vector, std::array, C-style arrays, or a raw pointer-and-length pair, all through one set of constructors. Mark it const when you don’t need to mutate through it, and the intent becomes obvious at the call site.
If you’re pre-C++20, GSL or gsl-lite gives you the same shape.
One caveat we spent some time on: never store a span as a class data member. It’s a view, not an owner, so if the underlying container reallocates (a push_back on a vector, say), your span is now dangling and you won’t necessarily know it. Think of span as a contract for temporary access, not a lifetime management tool. C++ doesn’t have Rust’s borrow checker to catch that mistake for you, so it’s on the reviewer.
Bottom line: any time you see a raw pointer-and-length pair in legacy code, or in code an AI assistant just handed you, that’s a solid candidate to swap in std::span.
A Note on Where This Group Goes Next
I want to be upfront about something.
I’m suspending the San Diego C++ Meetup for now.
Nothing dramatic happened, I just need to rethink what this group is actually for. Over the past year and a half, the way I write, review, plan, and design C++ code at work has changed more than it did in the previous decade combined. AI assistants are now part of nearly every step: drafting implementations, catching the kind of subtle bug that used to take a sharp pair of human eyes (missing a reserve(), a raw pointer-length pair that should have been a span), even helping think through design tradeoffs before a line of code gets written.
That’s genuinely exciting, but it also means a monthly meetup built around “here’s a neat C++ feature, let’s go deep on it” doesn’t fully capture what’s actually useful to this community anymore. The interesting questions right now are less about the language quirks (though we’ll never stop loving those) and more about how we teach, review, and reason about C++ in a world where a lot of the first draft isn’t typed by a human.
So I’m taking a pause, not shutting the door. I want to figure out what a version of this meetup looks like that actually engages with that shift, rather than just bolting an “AI mentioned it” section onto the end of every session.
If you’ve got thoughts on what that should look like, I’d genuinely like to hear them. Reach out on Discord.
Thanks for being part of this for 87 sessions. See you on the other side of this rethink.
Kobi