I just attended the C++ Under the Sea 2-day conference. I really enjoyed it. Watch out for talks from Hana, Matt and Kevin Henney. Really good keynotes

Matt presented his v4 version of this ZX Spectrum emulator: https://github.com/mattgodbolt/specbolt

Both Kevin Henney's and Hana's talks were new; at least I haven't seen a version of them before. These keynotes were really, really good. Hope it comes on YouTube soon.

Personally, I was a bit let down by talks from people who work for AI companies. The talks became more like a product user guide than anything to do with C++ or Programming.

Overall, an amazing conference. If you are in or around the Netherlands, you should plan to attend.

Systems targeted by C++ toolchains vary a lot even though C++ constantly changes. If you rely on operating system STL for your application code, following things may happen:

• If your platform A supports C++20 and your platform B supports C++14 and your platform C supports C++11, you will either force C++ <= 11 to all your libraries, or use macro magic etc, to use one set of features each platform.

• If you operate in a specialized domain, such as real-time systems, you may need a standard library built with specific configuration options, such as disabling exceptions or RTTI. Relying on the system-provided STL leaves you dependent on how it was built, which may not meet your requirements

If you build your STL of choice you solve all these issues:

• You can use the highest C++ standard possible, you no longer have to think about each operating system state extensively.
• You can configure your STL to match your needs

In nearly all modern system languages you build standard library yourself, I don't see any reason why C++ developers shouldn't consider this.

Hi, one of the MSVC dev leads here.

The 14.52 MSVC Release Candidate is now available. If you are on the Visual Studio Insiders Channel and upgrade, you'll see that the default MSVC toolset has upgraded from 14.51 to 14.52. The blog post covers the features & fixes the team has landed in that timeframe.

C++23 is ready for production use, and available with the /std:c++23 compiler option. See the blog for more details.

We'll resume our monthly MSVC Preview (version 14.53) blog post series next month.

New video from Utah C++ Programmers.

C++23 - The Complete Guide is now also available as paperback version.
You can order it, for example, at Amazon.

The book explains on 500 pages all new features of C++23 (covering both the core language and the standard library) with motivation, conceptional introduction of all aspects, and many examples of how to use the new features in practice.

The book is part of my "The Complete Guide" Series, trying to explain a programming language that is now so overwhelming that as a programmer it is hard to keep track of all its new features, benefits, and pitfalls.

Enjoy

Nico

Blog post: https://kemalbektas.dev/ai-modern-features/

I tested whether coding agents would actually use C++23 ranges without being told.

They mostly didn’t. What changed things much more than the surrounding codebase was a short AGENTS.md asking for modern C++.

C++Now

2026-10-05 - 2026-10-11

• Signal Trees - A Deep Dive into a High-Performance Alternative to Queue-Based Task Scheduling - Michael Maniscalco - https://youtu.be/ZRd_XN3LGxo
• Object Oriented Programming in Contemporary C++ - Steve Downey - https://youtu.be/m7gwSr27m74
• Cutting Some Slack for our Programs - Lisa Lippincott - https://youtu.be/xwnRPyRK5h4

2026-09-28 - 2026-10-04

• What Every C++ Programmer Needs to Know About AI - Jody Hagins - https://youtu.be/ZBXHPKVCa8E
• SPL - Open Source, Constexpr Library for Composing Algorithms - John Bandela - https://youtu.be/96AGjm3uwko
• Senders For Existing Asynchronous Interfaces - Dietmar Kühl - https://youtu.be/KB5Nfofgu2k

ACCU

2026-10-05 - 2026-10-11

• Real-time Safety in C & C++ - Guaranteed by the Compiler! - Anders Schau Knatten - https://youtu.be/FeYEO3PhEVY
• Modernizing Legacy Codebases Without Stopping the World - Peter Muldoon - https://youtu.be/w9k-L0GLLKM
• Our Journey Toward a Fully Backward-Compatible, UB-Safe, ISO C++ - John Lakos - https://youtu.be/whFzmXXhG5g

2026-09-28 - 2026-10-04

• Refactoring Towards Structured Concurrency - Roi Barkan - https://youtu.be/ttoQfPP_Gkg
• Design Patterns - The Most Common Misconceptions (3 of N) - Klaus Iglberger - https://youtu.be/bAsJvmtYZOg
• One Lib to Rule Them All and in the Darkness bindgen… - Antonello Palazzi & Kay Hicketts - https://youtu.be/9BpVjPKv02s

ADC

2026-10-05 - 2026-10-11

• BEEPS and PORTS - Annoy Everyone in Your House While Building An Audio Synthesizer - Joseph Stewart - https://youtu.be/bnIV2nyh-rg
• Hardware DSP Asset Inheritance and Evolution - Takeshi Kuwahara - https://youtu.be/yYukJpiFOOU
• Field Recording - In Search for Perfect Sounds - Malin Arvidsson - https://youtu.be/L5iZDi71VWU

2026-09-28 - 2026-10-04

• Designing Interactive Music Experiences in XR - Kasson Crooker - https://youtu.be/J3sVHT8luKs
• When (Not) to Patent Audio Software - Simon Hestermann - https://youtu.be/stBB1JoKQiY
• Distribution Strategies for Indie Audio Developers - From Plugin to Product - Dani Karanyi - https://youtu.be/Piar49uTjtg

Release cppreference C++ v2025.12.01 · cristianadam/cppreference-doc

This is useful for the Qt Creator users that use it for C++ development.

I was thinking, wouldn't adding equality comparison support between std::variant and one of its unambiguous alternatives help simplify potential pattern matching designs?

For example, imagine something like this (hypothetical syntax):

std::variant<int, std::string> v = 42;

match (v) {
    case 42      => handle_int();
    case "hello" => handle_string();
    case _       => handle_other();
}

The idea would be to take advantage of something C++ already has: operator==. At the end of the day, matching is fundamentally a comparison, so why not build on the existing equality semantics?

For std::optional, we can get this with its existing comparison operators and the most trivial pattern matching compiler support:

std::optional<int> o = 42;

match (o) {
    case 42           => handle_value();
    case std::nullopt => handle_empty();
    case _            => handle_other();
}

// Which would translate to:

if (o == 42)
    handle_value();
else if (o == nullopt)
    handle_empty();
else
    handle_other();

And if we had something like std::match_projection<Subject, Pattern>, we could also extract the actual matched value instead of having to manually call std::get, dereference an optional, etc.

Basically, after a successful comparison, match_projection would tell the compiler what to extract based on the subject and pattern types and we could optionally bind that value using something like a as <declaration> syntax.

For example:

std::optional<int> o = 42;
std::optional<int> other_opt = 42;

match (o) {
    // No binding needed
    case 42 => foo();

    // match_projection<optional<int>, int> -> int&
    case 42 as int& x => use(x);

    // match_projection<optional<int>, nullopt_t> -> void
    case std::nullopt => handle_empty();

    // match_projection<optional<int>, optional<int>>
    // -> optional<int>&
    case other_opt as auto& x => use(x);
}

The same would apply to std::variant, assuming we also extend its operator== to support comparisons with individual alternatives:

match (v) {
    case 42 as int& x => use(x);
    case "hello" as std::string& s => use(s);

    // Only need to define operator== for this helper for this to work
    case indexed<0> => handle_any_int();

    // Or under this form for the sake of disambiguation
    case indexed<0>(10) => handle_ten();

    // Also provide match_projection<indexed<0>> to enable binding
    case indexed<0>(20) as int& x => use(x);

    case _ => handle_other();
}

Here, indexed<> would just be a hypothetical helper for explicitly selecting which alternative to compare against. It would only need an appropriate operator== to work with matching, and a corresponding match_projection specialization if we also wanted to extract the alternative.

This way, the matching itself wouldn't need to know anything about variant, optional or even user-defined types. It would just use their equality operators, while match_projection would tell it what to extract when we actually want to bind something, which is just syntactic sugar.

I'm curious what you think about this approach. It feels like we could get quite a bit of useful pattern matching functionality without introducing too much new language machinery or convoluted new language traits and APIs.

Also do you think std::variant being equality comparable with instances of its alternatives would be an useful addition on its own?

std::variant<int, std::string> v = 42;

if (v == "not my string") ...

// Which is simpler than
if (std::holds_alternative<std::string>(v) && std::get<std::string>(v) == "not my string") ...

Syntax seems nice on its own...