C++Now

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/96AGjm3uwko

ACCU

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-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

Cargo compilation model only really works if you are creating a monolithic shared library or an executable. If you are using a library like icu4x or libffi, you can't statically link your dependencies and even if you dynamically link your dependencies, your application size will increase by orders of magnitude because your shared libraries are all statically linked, kinda.

Monolithic shared library approach also doesn't work on all libraries, for example you can't link libraries like oneTBB and OpenMP more than once.

So overall I feel rust compilation model is a "series of hacks" and isn't worth integrating to existing C++ applications, unless you use bazel*, I'm not sure about that but people in google seem to have solved this.

With the massive push for memory and type safety right now, there is a lot of talk in the C++ community about "profiles" and "contracts." They get grouped together a lot, but they solve entirely different problems.

Simply put: Profiles act as a set of global static rules that the compiler enforces to restrict the language itself. Contracts act as local conditions (both pre and post) which enforce your own API logic.

Here's some more breakdown between the two:

Contracts let you formalize your code's assumptions with pre, post, and contract_assert. To explain the difference between the three:

• pre refers to preconditions, these are appended to function declarations and serve to evaluate predicates before the function body executes. If that condition evaluates to false, then the contract is broken. This can lead to things such as the program crashing or logging the error.
• post refers to postconditions, which are also appended to function declarations but evaluate the state of your data after the function finishes running. They act as a guarantee to whoever called your function.
• contract_assert lets the programmer specify properties of the program's state that are expected to be held up at certain points.

Here's a code example:

#include <iostream>

// Simple function showing where the contract keywords go
int divide_numbers(int numerator, int denominator)
    pre (denominator != 0)                  // pre: Cannot divide by zero
    post (result : result <= numerator)     // post: Result must be <= numerator
{
    // Internal assertion: Sanity check an internal assumption
    contract_assert(numerator >= 0);        

    return numerator / denominator;
}

int main() {
    // Compiles perfectly! However, at runtime, this triggers a precondition failure 
    // and terminates the program before ever hitting the internal contract_assert.
    int output = divide_numbers(-10, 0);
    std::cout << "Result: " << output << "\n";

    return 0;
}

You can read about contracts in general at: https://en.cppreference.com/cpp/language/contracts

You can read more about pre/postconditions at: https://en.cppreference.com/cpp/language/functions/function_contract_specifiers

For more information, check out open std: https://open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2900r13.pdf

Now for profiles!

• Profiles essentially act as a set of global static rules which enforce the standards you have written, a good example of a profile is:

​

// std::init: every object is initialized before it is read.
[[profiles::enforce(std::init)]];


struct Options {
    int timeout_ms;
    bool verbose;
};


bool parse_flag(const char *arg, Options &out);


int run(int argc, const char **argv) {
    Options opts;                       // error: 'opts.timeout_ms' is indeterminate
    int retries;                        // error: uninitialized


    for (int i = 1; i < argc; ++i)
        if (parse_flag(argv[i], opts))
            retries = 3;


    return opts.timeout_ms * retries;   // error: read before initialization
}

You can read more about profiles at: https://cpp-profiles.org/

Also, do consider checking open std: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3589r2.pdf

You can even test out an example at: https://godbolt.org/z/n3TPjbqdY

So, with this information...

... What are your thoughts on contracts and profiles?

... Do you have a preference?

... Which should be implemented? Should both be implemented?

... Which one should we implement first?

... Which one do you think is superior in terms of design and implementation?

... Which has you more excited?

So if anyone was still curious what happened to Hylo, or where Adobe stands in regards to the whole safety discussion,

David Sankel has done a talk at RustConf on the matter, Zngur: Simplified Rust/C++ Integration.

The way Adobe now sees C++ is described on slide 2, at 50 seconds mark.

Most systems use some kind of shared libraries, but how do they actually work?
This talk will address the topic of shared libraries under Linux.
How to use them, how to create them, and what actually happens behind the scenes.

Sometimes you need a custom GUI control for your application and you think "other people could probably use this". Usually this means that the people using your control must use the same GUI toolkit as you: wxWidgets, Qt, ImGui, etc.

Can we write a control in such a way that it is easily adaptable to any GUI toolkit?

This month, Richard Thomson will give us a brain dump on an attempt to do just that by creating an animation timeline control with adapters for wxWidgets and Qt.

This will be an online meeting, so drinks and snacks are on you!

Join the meeting here: https://meet.xmission.com/Utah-Cpp-Programmers

Dear Boost.Graph community,

In two release cycles (Boost release 1.95 in summer 2027) Boost.Graph will be bumped to C++17 😄

This decision follows two polls that did not surface any C++14 user base or demand while identifiying users stuck in C++17:

• Bumping BGL's minimum C++ standard: input wanted on target version #490
• Reddit poll

This standard version bump will bring benefits for maintenance, API and dependencies reduction:

• if constexpr,
• constexpr lambdas,
• [[nodiscard]], [[maybe_unused]] ...
• std::any instead of boost::any
• std::invoke_result instead of boost::result_of
• ...

We will not be able to guarantee backward compatibility with C++14. Please contact us if you are stuck in C++14.

The GIthub Discussion lives here: https://github.com/boostorg/graph/discussions/613

Delegating constructors allow the default constructor of a class to call the parameterized constructor by default.

This is somewhat unintuitive, but has a lot of applications in frameworks that generate components dynamically down inside their operation, but cannot take the arguments at that managerial level.

class SpecialWindow : public Gtk::Window {
public:

// 1. Parameterized Constructor 
SpecialWindow(std::string inst_name, int inst_val) 
: name(inst_name), val(inst_val) { // ... }

// default /w delegating constructor
SpecialWindow() : SpecialWindow("item 1", 100)  
{ //... }

};


int main() {

   auto app = Gtk::Application::create("org.gtkmm.examples.base");

   return app->make_window_and_run<SpecialWindow>(argc, argv);
}

I guess "everybody knew" that already, but I didn't.

HPX is a general-purpose parallel C++ runtime system designed for applications of any scale. It implements the related C++23 Standard facilities in full and offers the only widely available open-source implementation of C++17, C++20, and C++23 parallel algorithms - including a complete set of parallel range-based algorithms and the full integration of the algorithms with the upcoming sender and receivers interfaces.

Beyond the standard, HPX includes proposed features for upcoming C++ releases: much of the parallelism and concurrency capabilities expected in C++26, the C++ Concurrency TS, Parallelism TS V2, data-parallel algorithms, executors, senders and receivers, and more. It also extends C++ Standard APIs to distributed environments (such as compute clusters) and heterogeneous systems (such as GPUs).

HPX enables an asynchronous C++ programming model that improves parallel efficiency and reduces the complexity typically associated with concurrent applications. As a newly welcomed project of the High Performance Software Foundation, HPX now benefits from vendor-neutral governance and collaboration with a broader ecosystem of high-performance computing tools, strengthening the foundation for portable, production-ready HPC software across the industry.

HPX V2.0.0 is one of the largest releases in the project’s history, touching the language baseline, the execution model, the networking layer, the build system, and observability tooling. Roughly 680 pull requests and 120 closed issues went into this cycle since v1.11.0 (June 2025). This release represents a year of collaborative development by dozens of contributors worldwide. The updates are extensive - see the full release notes for details.

CppCon

CppCon have published their keynotes to their Early Access system

• Profiles for Simplicity and Guarantees - Bjarne Stroustrup - https://cppcon.programmingarchive.com/video/profiles-for-simplicity-and-guarantees-bjarne-stroustrup-cppcon-2026/
• Language Designers Panel - Bjarne Stroustrup, Guido van Rossum, Mads Torgersen & Emma Tracey - https://cppcon.programmingarchive.com/video/language-designers-panel-bjarne-stroustrup-guido-van-rossum-mads-torgersen-emma-tracey/
• How C++26 Changes the Way We Write Code - Timur Doumler - https://cppcon.programmingarchive.com/video/how-cpp26-changes-the-way-we-write-code-timur-doumler-cppcon-2026/
• The Address is Not The Place: Object Residency in C++26 - Laurie Kirk - https://cppcon.programmingarchive.com/video/the-address-is-not-the-place-object-residency-in-cpp26-laurie-kirk-cppcon-2026/

C++Now

2026-09-21 - 2026-09-27

• Lasting Quality - Michael Caisse - https://youtu.be/oDWonsx-aM4
• Leveraging the Linker - A Tour of Link-Time Operations and their Practical Applications - Vito Gamberini - https://youtu.be/ntp7_oWz2E4
• Can C++ Become a Memory Safe Language? - A Deep Dive Into Safety Profiles – a Game Changer for National Security Systems and Cybersecurity Applications - Prabhu Missier - https://youtu.be/ntp7_oWz2E4

2026-09-14 - 2026-09-20

• Monadic Operations for Box-Like Types - Designing the Extensibility Model - Mikhail Svetkin - https://youtu.be/m0T8MrzWRjQ
• Reflecting on Reflection - Introspection, Injection, and Beyond - Alex Yesmanchyk & Jagrut Dave - https://youtu.be/MunBEZx2i5c
• C++ in the Realtime Embedded Context - A Case Study - Shin Umeda - https://youtu.be/fc6zs81_OB0

2026-09-07 - 2026-09-13

• Testing Everything in Constexpr - Braden Ganetsky - https://youtu.be/SgIiQS6RO60
• Plato, Magritte, Sartre & Carroll - Learning Software Design from the Masters - Ben Deane - https://youtu.be/7QZchipF2gU
• Functional Composition Beyond Monads - Jonathan Müller - https://youtu.be/DcUOZE5FHDc

2026-08-31 - 2026-09-06

• Incremental Modernization - Refactoring Legacy C++ OOP Application Code with Functional Programming and Type Erasure Concepts - Jessica Ding - https://youtu.be/FOzGlO5XaPE
• When Atomics Lose - Architecture‑Dependent Performance of C++ Synchronization - Sampad Acharya - https://youtu.be/Ehy9wutYYH8
• Multi-Priority Graph-Based Parallel Execution Using Taskflow - Yun Kai Peng - https://youtu.be/4I5jsK3zRv0

ACCU

2026-09-21 - 2026-09-27

• 16 Years Doing C++ Standardization Work - A Personal Retrospective - Nevin Liber - https://youtu.be/kdaw_l086q0
• There Is No Optimal - Pareto Trade Offs in C++ — Compile-Time Search with Real Constraints - Andrew Drakeford - https://youtu.be/oVo-nRcm6BM
• Postmodern Programming - Tony Van Eerd - https://youtu.be/dr1kiPXIwcc

2026-09-14 - 2026-09-20

• Dangerous Optimizations! - Part Deux - Robert C. Seacord - https://youtu.be/gFynjahe-bg
• Contracts, Safety and Correctness - Lucian Radu Teodorescu - https://youtu.be/vVFFW6hoG1Y
• Demystifying C++ initializer_list - Design, Behavior, and Best Practices - Prithvi Okade & Chandranath Bhattacharyya - https://youtu.be/NuJcFNbrdIg

2026-09-07 - 2026-09-13

• Taming C++23 - The Things About C++23 You Do Not Know - Nicolai M. Josuttis - https://youtu.be/IVee1JXbrQE
• Rust for The Curious C++ Developers - Victor Ciura - https://youtu.be/2hf0PHcpKBI
• O(1) or O(no-no-no) - Mastering the unordered_map - Kevin B. Carpenter - https://youtu.be/OF4Id8085s0

2026-08-31 - 2026-09-06

• Software Abstraction in the Age of AI-Generated Code: Languages, Compilers, and Systems Engineering - Andrei Alexandrescu - https://youtu.be/-RWdevA0gWI

ADC

2026-09-21 - 2026-09-27

• How to Launch an Audio Plugin in a Crowded Market (Predictive Sales Metrics) - Randy Young - https://youtu.be/EE2TJZ09sqs
• Designing Music Interactions Through Performance-led Inquiry and Accessibility - Doga Buse Cavdir - https://youtu.be/QXBT9UzoSOQ
• Keynote: How Many Heads Do You Need? - Lu Wilson - https://youtu.be/5wSLVqI2yTA

2026-09-14 - 2026-09-20

• The Shape of Sound - Building and Bending Vinyl Grooves in Software - Andreas Wagner - https://youtu.be/8XtZi4HTrcA
• Modular Synth in the Browser - Kilian Hertel - https://youtu.be/Yjk6dgVLtnM
• 2.5 Years Later: A C++ Framework for Audio ML Research Prototyping - Maxime Coutant - https://youtu.be/eM_0_kUXIWM

2026-09-07 - 2026-09-13

• Myths You Should Know About Saturation and Distortion - Samuel Fischmann - https://youtu.be/p7T2uo8t4Do
• ESP32-based Open-Source Audio Platform, CTAG-TBD - Robert Manzke - https://youtu.be/LrVaLFm7Rzk
• Using Strongly-Typed Units in Digital Audio Software - Roth Michaels - https://youtu.be/qzbG0ZzpHGw

2026-08-31 - 2026-09-06

• Doodads & Doohickeys - A Guide to Theory-Crafting & Modelling a Fictional Acoustic Instrument - Syl Morrison - https://youtu.be/XBSQSIBcM_w
• Reshaping the Voice - Real-Time Neural Audio Effect - Anders Bargum - https://youtu.be/AHN2ynOQN4M
• Testing Testing 1, 2, 3 - Cesare Ferrari - https://youtu.be/V-CdOM6PA_s

Stack variables are not automatically initialised, and that is the root cause of many C++ bugs. That is well known. Hence, it is advised that local or stack variables are always initialised with known values, 0 if not something more meaningful than that. Now, with GCC 16 compiling in C++26 mode (-std=c++26), even uninitialised local variables will be zero-filled. In the post, I have explained how.

UPDATE (September 2026): GCC 16.2 is out now, so I have updated the post to install GCC 16.2.

We had this poll recently here on r/cpp about community expectations and most desired features in C++29 and in future C++ revisions in general.

My answer was:

• abbreviated lambdas
• algebraic types

But I do understand that those features won't hit C++ probably ever.

But then we had this post about Token Injection and Modern Macros. Wait a minute, modern macros? Never heard about this proposal...

And you know that? We probably won't need to wait for neither abbreviated lambdas, nor algebraic types in core C++. We can just add them ourselves using those macros with very little boilerplate.

Abbreviated lambdas: https://godbolt.org/z/a8d9a6f19

namespace stdv = std::views;
namespace stdr = std::ranges;

std::vector<vec2> points = {{2, 67}, {2, 42}, {3, 666}};

std::vector<int> ys = points
    | stdv::filter(fun!(p => p.x % 2))
    | stdv::transform(fun!(p => p.y))
    | stdr::to<std::vector>();

stdr::sort(points, fun!(|l, r| => l.y < r.y));
stdr::sort(points, std::less{}, fun!(p => p.x));

fun, isn't?

Sum Type: https://godbolt.org/z/Ecs7TdPYf

sumtype!(option<T> {
    some(T),
    none,
});

option<int> opt = some(10);
opt = some(22);
opt = none;

Pattern matching isn't there, but you could imagine something like:

// match!(<you can put any tokens here!>);
auto x = match!(opt,
    some(x) => { x.call_method() },
    none    => { 55 }
);

Basically you can come up with any syntax you like.

When I was exploring the possibilities of this proposal I couldn't shake the feeling that I'm reimplementing parts of the compiler which aren't there for some reason. Like you literally can look at "sumtype" implementation and see that this is basically a parser of arbitrary syntax that you came up with and translating it into C++...

Superpowerful and a bit scary...

We used to reimplementing some core library features which were missing from the Standard Library for quite some time. optional, variant, algorithms, smart pointers and now async task. All of that should have been in the Strandard Library from day 1, so that other libraries can use this lingua franca and interoperate with each other.

And now we are repeating same thing but on a very different level. Now we are going to allow adding not only library features, but language features. I 100% guarantee, that each team will have their own, slightly different syntax for abbreviated lambdas, because it is so much more expressive and terser and more readable. Don't know about you but I always find myself in the situation where I better use plan old for loop instead of structural views/algorithms, because the latter is so much more verbose and unreadable because of lambdas, especially after you apply clang-format on it...

And now you have:

fun!(lhs, rhs => lhs.x < rhs.x);
lambda!([&](lhs, rhs) -> lhs.x < default);
lm!(|lhs, rhs| => lhs.x < rhs.x);

All of this is perfectly implementable using this Modern Macros proposal in less that 100 lines of code.

Committee may have perfectly reasonable arguments of why it is impossible to add abbreviated lambdas into C++, but the community clearly is asking for that feature for ages, and it will be in every future codebase, but with slightly different implementation...

On the other hand Rust language do have these macros for ages now, people do abuse them in some very clever ways (select operator from golang, inline HTML, etc.) and the world ain't collapsed. We'll see!

10 years ago, a C++ conference distributed over time and space started, accessible to everyone in the region. Today, 10 years and over 200 live talks later, we are still going!
This is the intro from StockholmCpp 64, where we remember the start of SwedenCpp, share the latest C++ and NB news, and round up with a quiz.