Guillaume Dua

Trip Report - Meeting Cpp 2025

2026-03-13T00:00:00+00:00


Event	Meeting C++ Conference, 2025
Author	Guillaume Dua
Date	11/06/2025 - 11/08/2025
My attendance sponsor	Fairmat
Revision	R1

Introduction
📅 11/06/2025
📅 11/07/2025
📅 11/08/2025
Conclusion
Related posts

Introduction

This year - and like every year: see my trip-report for last year’s conference - I attended Meeting C++ 2025. As always, the conference brought together a vibrant and passionate community of C++ developers, with a strong emphasis this year on safety, security, performance,
as well as the human side of software development: particularly the role of lead developers, mentorship, and empathetic collaboration.

While I joined from home, I still very much enjoyed the experience of participating in discussions, chatting with attendees online, and learning from an excellent lineup of talks.

Also, I would like to sincerely thank my employer - Fairmat - for funding my participation in the conference for the second year in a row.

⚠️ Disclaimer:

The opinions, interpretations, and conclusions expressed in this report - and the “my takeaway”, “disgression”, and “conclusion” sections in particular - are solely my own and do not necessarily reflect the views of my employer.
While my participation in the conference was funded by my employer, they bear no responsibility for the content, opinions, or interpretations presented here.

From this - admittedly far too long - trip report, I hope that if you couldn’t attend the conference this year, you can at least take away a small piece of the experience. And who knows, if you enjoy reading it, perhaps you’ll join in person or remotely next year 😉.

❓ Why spend nearly three months writing a >80 commits, almost 2000-lines trip report ?

First and foremost, this document is for future me. I cannot ctrl+f my own memory, but I can search this report to quickly recover who said what, about which topic, and in what context.
Like any conference report, it cannot fully capture the depth, precision, and nuance of every talk; what follows is therefore my own understanding and interpretation of the speakers’ messages.
Beyond documentation, the act of writing itself matters: it helps me internalize the ideas, connect themes across talks, and turn fleeting impressions into lasting knowledge.

⏩ What’s comming next ?

I’ll make sure to add 🎥 videos and 📄 slides links when available.

Resources:

📅 11/06/2025

🗣️Jens Weller: Welcome Message

The conference opened, as tradition, with a warm welcome from Jens Weller, the founder and organizer of Meeting C++.
Jens provided an overview of what to expect during the event:

3 keynotes
54 talks spread across 4 tracks (plus an additional online-exclusive track)
About 230 attendees onsite and 150 remote attendees

Creating a safe and inclusive environment

Jens reiterated the importance of a welcoming community, referencing the Berlin code of conduct.
A dedicated Trust & Safety Team was available to ensure every participant could enjoy the conference comfortably.

He also acknowledged the continued attention to health considerations, including SARS-CoV2 prevention policies.

In memory of Rainer Grimm

This year’s introduction carried a deeply emotional moment, with the remembrance of Rainer Grimm, who passed away on October 6th 2025, from ALS.
Rainer has been a beloved figure in the C++ community - through his blog, his teaching, his books, and his presence at many conferences.

A small plush mascot named Cippi was on stage next to Jens, as Rainer’s symbolic presence.
Instead of the planned session for this year, the conference replayed his talk from last year: an overview of upcoming C++26 features.

Attendees were encouraged to share messages for Rainer’s family and community via a QR code linking to his website, on Cippi’s tshirt.

Klaus Iglberger (one of my favorite conference speaker) will continue carrying Cippi at future conferences, preserving Rainer’s memory and acknowledging his impact.
This tribute was a heartfelt reminder of the human connections that bind the C++ community together. ❤️

🗣️Anthony Williams: Software and safety (Opening Keynote)

🎥 Video, 📄 slidedeck

Anthony Williams - ISO C++ Committee member (contracts) and low-level library developer at Woven by Toyota - opened the conference with “Software and Safety”, a talk about how principles from safety-critical domains can (and should !) influence all software developments.

What safety means ?

Safety-critical software is any system where failure can cause injury or loss of life: automotive control, aircraft systems, factory and nuclear controls, or medical devices like pacemakers and CT scanners.
But even outside those domains, software failures can cause real harm: financial loss, identity theft, or loss of trust, making safety relevant to every developer.

Standards and mindset

Industries rely on standards such as ISO 26262 (automotive), DO-178C (aerospace), and IEC 62304 (medical).
Even when these don’t apply, their mindset does: anticipate failure, design for resilience, and handle the unexpected gracefully.

Why systems fail ?

Many failures arise from situations developers never considered: “that could never happen”.
Hardware faults, invalid inputs, and corner cases often lead to bugs.
Good design anticipates these events instead of assuming perfect conditions.

Undefined behaviors (UB) and reliability

Anthony connected software safety to undefined behavior (UB) in C++ - “behavior for which the standard imposes no requirements”. In safety-critical code, UB is unacceptable. Preventing it means enforcing memory safety, input validation, and robust testing. Tools like static analysis, sanitizers, and hardened libraries help detect problems both at build time and runtime.

Contracts in C++26 as a safety leverage

C++26 introduces contracts for expressing preconditions and postconditions directly in code:

void func(auto* ptr)
  pre(ptr != nullptr)
{
    auto& ref = *ptr;
}

Contract violations represent real bugs. In safety-critical systems, handlers may trigger a state safe reset (depending on the use-case), while in others, they might choose to continue or abort cleanly.

Defense in depth, using appropriate strategy and tools

Anthony described safety as a Swiss Cheese model: multiple imperfect layers together form a strong defense. No single measure is sufficient, but combined they create resilience thus trust.

Design checks: prevent problems upstream and by-design.
- Initialize all your variables
- Use safe APIs: ranges at instead of operator[], etc.
- No raw pointers: prefer std::span, std::string-view, etc.
- No indexing: prefer range-based for-loops
- Use RAII to manage lifetime
- Use contracts: C++26 contracts, or even just documentation as it’s better than nothing.
Investigate bugs: debugger, stack-trace, core-dump, custom logs of states
Hardened libraries
Testing: problematic inputs like too long strings, negative quantity, SQL query injection attacks, etc.
Fuzzing: American Fuzzy Lop ❤️
Static analysis tools: clang-tidy, CodeQL, SonarQube
Sanitizers

The Arene Base library

Woven by Toyota is developing Arene Base Library (will be available in open-source soon), a foundation for safety-critical software that meets AUTOSAR and MISRA guidelines (so it’s C++14/17 for now 😥 tho).
It includes static containers (inline-vector, inline-map, inline-string, etc.), backports of modern feature like non-owning ranges (span, string-view, mdspan), and enforced precondition checks.

My takeaway

I really enjoyed this talk - it felt 100% legitimate to start the conference by addressing the current “C++ is unsafe” criticism/buzz head-on.

👉 Repeated, loud claims that “C++ is unsafe” contribute to a cognitive bias known as the exposure bias (related to the familiarity principle): when the same simplified message is heard often enough, it starts to be perceived as an unquestionable truth, regardless of context or nuance.
Over time, this shapes collective perception - especially among juniors who lack technical perspective, and among managers or decision-makers who may not have the expertise to challenge such claims. The result is not informed judgment, but decisions driven by repetition, fear, and oversimplification rather than by facts, trade-offs, and real-world constraints.

As this was my first time attending a talk from Anthony Williams, and I was genuinely impressed by how detailed yet fluid and approachable his presentation was.
He managed to cover a technically dense topic with clarity and purpose, setting a strong and confident tone for the rest of the conference.

Moreover, this topic strongly resonates with the engineering practices I advocate for on a daily basis in my professional work, which naturally reinforced the positions and recommendations I drew from these talks.

That said, experience has shown me how challenging it often is to raise awareness - especially among product owners and managers - about the importance of safety, testing, sound software design, code quality, modern development practices, and pragmatism in general.
Too frequently, the focus shifts toward delivering something that merely appears to work, validated by a quick demo covering a narrow, happy-path use case, and pushed to production as fast as possible.

From my perspective, this does not constitute delivering value. On the contrary, it creates false assumptions about the product, fosters a bug-prone environment, and builds software on fragile foundations that will inevitably crumble over time. 👉 This concern is not a matter of developer preference or perfectionism: our responsibility is to deliver durable value, not unstable or misleadingly functional components. If only the simplest scenarios are “tested”, and no appropriate tools are used, how can we confidently claim that the system actually works ?
💡 Addressing these issues later invariably costs far more than doing things properly from the start.

This is why, for me, establishing a clear and shared Definition of Done (DoD) - and actively educating all stakeholders around it - is essential for every project, product, and team. Peter Muldoon delivered an interesting talk about DoD last year, here at MeetingCpp: Software Engineering Completeness : Knowing when you are Done and Why it matters ?.

💡 Too often, short-term delivery - followed by constant patching - are rewarded more visibly than long-term engineering quality. Shipping something quickly and repeatedly fixing issues in production can create the perception of efficiency: such developers are seen as fast, reactive, and indispensable when problems arise.
This visibility aligns well with managerial metrics that favor immediate outcomes and rapid response.

In contrast, developers who invest time in thoughtful design, thorough testing, and safety-oriented practices tend to operate quietly. Their work prevents incidents rather than reacting to them, which makes its impact far less visible. As a result, they are sometimes perceived as slow or inefficient, despite delivering systems that are reliable: robust, maintainable, and resilient to change.

At its core, this is a question of effort visibility and incentives. Reactive work is easy to observe; preventive work is easy to overlook. Yet the real measure of value lies not in how quickly issues are patched, but in how rarely they occur - and in how sustainably the system can evolve over time.

I’ll also make sure to check the ETL library and its Arduino variant, as it offers a complementary solution tailored to best fit the embedded restrictions and needs.

Interesting/valuable inputs from the questions session:

Why would one choose a normal/soften library over an hardened one ? 👉 Optimized for speed vs. optimized for safety.
The vocabulary we use when talking to managers matters: weaken/soften libraries might sounds like something’s wrong, while we’d rather underline what the tradeoffs are.

🗣️Sebastian Theophil: To Err is Human: Robust Error Handling in C++26

🎥 Video, 📄 slidedeck

Everyday mistakes can make software brittle, unpredictable, or just plain frustrating.
Sebastian Theophil (Think-cell) delivered an excellent overview of the current landscape of error management in C++.
His message was clear: error handling is hard, often undervalued, and yet absolutely central to building trustworthy systems.

💡 Key takeaway: 5% of all error handlers handle 95% of problems.

The landscape of error handling: historical perspective

Sebastian began by contrasting reliability with error handling. Reliability demands considering faulty hardware, corrupted RAM, or broken sensors.
Error handling, in comparison, is “easy” - yet/still often done poorly.
Unexpected environments, unforeseen usage scenarios, and simple programmer mistakes are enough to cause cascades of bugs. Bad error handling accumulates technical debt and drains team efforts/time/motivation without delivering customer value.

C error handling: errno, out parameters, ambiguous return codes
C++ exceptions:
- suffer from bad reputation: “glorified gotos”, performances, banned from some codebases, unobvious control flow, etc.
- yet have strengths: any line can fail and unwinding can clean up state automatically.
- 💡Pro-tip: catch exceptions as locally as possible

The modern stuffs: std::expected

Sebastian highlighted std::expected as the likely “next big thing” in C++ error handling:

structured like return values
expressive like exceptions
and backed by a useful monadic API - like std::optional - (transform, transform-error, and-then, or-else, etc.).

This feature encourages deliberate handling without the unpredictability of exception-based control flow,
which from my perspective best in many, many designs.

The modern stuffs: contracts

He then connected this with C++26 contracts, which offer customizable assertion mechanisms for expressing preconditions and postconditions.

This is a great replacement for “documented by not checked” runtime requirements, just like constraints and concepts did for named requirements at compile-time.

Bonus, contracts support exceptions (leading to contract violation), and are supported in constexpr contexts !

Contracts error handling strategy/semantic can be selected/customized at build-time, making them suitable for both debugging and hardened production builds.

ignore: do nothing
observe: call contract violation handler
enforce: call contract violation handler and terminate
quick-enforce: terminate

Crucially, they allow side effects such as logging - provided that these do not alter the program correctness.

int f(const int x)
    pre(x != 0)       // implicitly const
    post(r : r != x)  // r is const, x must be const
{
    contract-assert(0 <= x);
    return x + 1;
}

int f(const int x);   // redecl. without contract is ok

Library hardening in C++26

The upcoming standards - see the standard library hardening proposal - bring enforced pre and postconditions to the standard library itself, turning many previously documentation-only requirements into runtime-validated checks.

Compiler vendors already provide early support, offering (partially) hardened library modes:

Practical rules for real-world code

Sebastian underlined that with so many options to do so, proper error-handling can be challenging.

error handling must be easy, otherwise developers won’t do it
error handling must be tested
error handling must be focused where it matters

He offered a set of rules shaped by ThinkCell’s own engineering experience:

Check everything: every API call, every return value. Use consistent wrappers for various error-reporting mechanisms.
Use noexcept by default and rely on std::terminate and custom terminate handlers for unexpected failures.
Assert aggressively, even in release builds, and treat assertions as diagnostics - not reasons to exit.
Design under the assumption that things usually work to keep the number of code paths manageable.
When checks fail, gather as much informations as possible and attempt to continue safely (aligning with the “observe” contract mode).
Focus efforts where the real problems are: historically, a small fraction of error handlers catch the vast majority of failures.

He also categorized error types:

critical issues (null dereferences, unexpected API failures, assertion failures, etc.)
untested scenarios
“bad expected” (third-party bugs)
and broken environments (weird configurations)

About `ThinkCell`’s error reporting

Sebastian concluded by describing ThinkCell’s comprehensive out-of-process error reporting system.

Similar in spirit to Google’s Chromium Crashpad but designed for all kinds of errors, it generates a context (gathering as many infos as possible) to then allow developers to best investigate issues,
by suspending the failing process, generates OS-specific minidumps, uploads them (when/if user consent), performs server-side symbolication, callstacks localisation, and groups failures by emission sites.

This infrastructure lets pragmatically prioritize real-world issues and allocate effort efficiently,
finding which areas of the codebase emits most problems (in perspective of time, versions, etc.).

My takeaway

I really appreciated how pragmatic and straightforward this talk was. I already use std::expected on daily basis, and it consistently proves its value - especially when wrapping legacy error-code APIs or when I need fine-grained, explicit reactions to likely error cases in a convenient and reliable way.
From my perspective, this style of error handling scales well in real products, and indeed is the “next big thing”.

Contracts, on the other hand, are something I haven’t tried in a professional setting yet, but I eagerly wait to.
Hearing how they can be tuned from “debug aid” to “production hardening” made me genuinely craving to experiment more with them.

One of the strongest takeaways for me was how much real-world engineering depends on robust error handling: the customer-only bugs that never reproduce locally, the tiny set of handlers that end up catching the majority of problems, and the difference between merely showing an error message and actually fixing the underlying issue.

From my experience, far too many projects fall into the trap of only logging errors but never taking meaningful corrective action.
Logs pile up without being even grouped, analyzed, categorized, or qualified, and they become a poor substitute for real error handling - effectively forcing developers to painfuly navigate through them by hand, which is inefficient, frustrating, and most of all, not error handling.

Related to this, I feel that many companies still struggle with non-reproducible or hard-to-reproduce issues (undefined behaviors, non-deterministic behavior, race conditions, unrecorded inputs, etc.), which becomes both expensive and exhausting to diagnose.
Using the right tools - debuggers, static analyzers, runtime sanitizers, and adequate/structured C++ error-handling mechanisms - is essential to improving team effectiveness and overall product reliability.

👉 Sebastian’s examples made it clear that investing in high-quality error handlers is a worthy strategy, over the entire lifetime of a product.

Additional resources: learn more about error handling

🗣️Nicolai Josuttis: Using `std::generator<>` in Practice

🎥 Video, 📄 slidedeck

Nicolai gave an accessible tour of what std::generator brings to C++23, and how it finally sits on top of the coroutine machinery introduced in C++20.
I appreciated how he framed coroutines not as something exotic dark wizardry/witchcraft, but simply as stackless (in C++) - yet stateful -, suspendable/resumable functions.

I was surprised to learn that Melvin Conway coined the term as early as 1958.
It immediately reminded me of Peter Sommerlad’s talk from last year here at the Meeting C++ conference - Collective Amnesia? - which explored how many supposedly “modern” ideas actually have deep roots in earlier programming models, along with several other invaluable insights for developers. (If you haven’t seen it yet, go watch it !).

What coroutines are (and aren’t)

C++ coroutines are functions that can pause and later resumed exactly where they left off.
C++ coroutines are stackless: instead of relying on the stack, their state lives separately, which lets you write code that looks perfectly sequential while actually running asynchronously or producing values lazily-even infinite sequences if you want.

In practice, any function that includes any of the co-yield, co-await, or co-return keywords becomes a coroutine, it’s that simple.

What std::generator brings

The talk really clicked when transitioning from the low-level coroutine model to the high-level std::generator abstraction. Seeing generators used as range-like, lazy value producers made the mechanics intuitive and ready-to-use:

begin() starts running the coroutine until the first co-yield
operator* accesses the yielded value
operator++ resumes execution until the next suspension point

He illustrated this with simple examples such as Fibonacci sequence generation and building a concurrent-queue reader coroutine.
The contrast with old user-defined stateful functors made it obvious how much cleaner and straight-forward generators are.

std::generator<std::string> coro() {
    std::array coll{ "tic", "tac", "toe" };
    for (int i = 0; i < coll.size(); ++i)
        co-yield coll[i]; // suspend with value
}

for (auto value: coro()){
    std::println(value);
}

Ouput:

tic
tac
toe

See example here on godbolt

` in Practice - `std::generator<>`" />

#include 
#include 
#include 

std::generator<std::uint64-t> fibonacci() {
    std::uint64-t a = 0, b = 1;
    while (true) {
        co-yield a;
        auto next = a + b;
        a = b;
        b = next;
    }
}

auto view = fibonacci() | std::views::enumerate | std::views::take(20);
for (auto element : view) {
    const auto & [index, value] = element;
    std::println("{:2} -> {}", index, value);
}

` in Practice - `generator<>` vs. class" />

Pitfalls and caveats

Nicolai didn’t shy away from discussing the limitations, and I genuinely appreciated that. Few things are more frustrating than seeing a conference talk showcase something impressive, only to have it fall apart the moment you try to use it in the real world, immediatly falling from the “peak of mount Stupid” down to the “valley of despair” (Dunning-Kruger effect).

Important points:

Generators are single-pass: iterating more than once is undefined behaviors (like stateful views).
Lifetime matter: you shouldn’t take parameters by reference if they might not outlive suspension.
Yielded values often behave like references.
You cannot iterate a generator when the object is const, since begin() mutates state.
std::generator<> is non-copyable.
Error management: exceptions propagate normally through the generator, back to the caller.

So one should not assume container semantics.

My takeaway

I especially enjoyed this talk from a meta perspective: the way the speaker presented and demonstrated the feature made it feel accessible, simple and approachable, without romanticizing it - just a clear, pragmatic view.

Nicolai’s explanations further reinforced why this abstraction can be so useful/powerful. From a design standpoint, it cleanly decouples value generation from consumption in a way that feels natural in contemporary C++.

The boilerplate required for custom coroutine types is still heavy - my own experience is around 100 lines for something usable - so I’m genuinely looking forward to future coroutine helpers in the standard.
I’m also especially curious about how well this whole model integrates with concurrency and networking scenarios. The idea of coroutine-based pipelines for network message handling or sensor data acquisition is very compelling.

Despite coroutines having been introduced in C++20, I definitely haven’t experimented enough with them yet. This talk left me wanting to spend a lot more time exploring what they can do.

Additional resources: learn more about coroutines

👉 C++ Coroutines Demystified - Phil Nash - ACCU 2025
C++ Coroutines from scratch - Phil Nash - Meeting C++ 2022
C++20’s Coroutines for Beginners - Andreas Fertig - CppCon 2022
And this very fun, simple, and short video by Sy Brand: Coroutines Explained with My Cat

🗣️Sandor Dargo: Code Reviews: Building Better Code and Stronger Teams

🎥 Video, 📄 slidedeck

Sandor’s talk focused on a topic that every developer deals with daily, yet few teams truly master: code reviews.
What I appreciated is that he didn’t treat code reviews as a mere technical gate, but as a human process - one that can teach, uplift, frustrate, or damage depending on how it’s handled. In that way, it reminds me of Kate Gregory’s talk at CPPP 2019 Emotional Code, which is IMO a masterpiece.
He explored why reviews matter, why they can go wrong, and how to make them constructive both for the codebase and the people involved.

The value of code reviews

Sandor broke down code reviews into three complementary roles:

Quality assurance: catching inconsistencies, design flaws, unclear logic, architectural drift, or naming issues.
Not a silver bullet, but an important final human check after all the automation.
Knowledge sharing: spreading API familiarity, explaining context, avoiding the “only the author knows this” trap.
Mentoring opportunity: especially for juniors, reviews can clarify the “why”, not just the “what”, and help them grow with empathy.

He also highlighted review formats: synchronous (pair or mob programming, dedicated review meetings) vs. asynchronous (pull requests).
Pair/mob programming offer immediate feedback and shared understanding, while PRs encourage reflection and diverse viewpoints.

Common arguments and misconceptions

👉 “Reviews slow us down”: true in the short term, but they prevent costly rework and architectural decay.
“Reviews don’t catch bugs”: also true. They’re better at catching design mistakes, complexity, readability issues, or misunderstandings - the subtle stuff tests rarely detect.
Tradeoffs exist, but the long-term payoff is healthier code and stronger teams.

The human aspects

Sandor underlined how important empathy and communication are:

Tone is easily misinterpreted in writing.
Comments should avoid blame, judgement, or condescending phrasing.
Excessive commenting or unclear prioritization overwhelms authors.
Poorly prepared PRs (too large, red, unrelated changes, no description) sabotage the process.

His summary of common pitfalls really resonated: late feedback, nit-picking, bossy language, unclear blocking status/reason, and comments lacking explanation.

Sandor’s AIR methodology

Sandor wrapped up with his own structure for writing comments:

A - Action: what the individual contributor (IC) should do.
I - Information: why it matters.
R - Reference: where to learn more (link to guideline, documentation, etc.) that best justify the feedback

Which results in a simple, predictable shape that keeps feedback actionable, polite, and grounded.

Interestingly, This reminds me of the Gherkin language in Cucumber, used for behavioral specifications (scenario, Given, When, Then),
that I use on daily basis to create backlog entries (features specs, issues, bugs, etc.).
The key idea here is to produce a predictable, narrative format that helps reduce ambiguity and clarifies intent and legitimacy.

My takeaway

I found the idea of delivering a talk about this topic very relevant. For the past decade, a large portion of my role as a lead-developer has revolved around reviewing code, coaching colleagues, and helping teams to deliver value.
So hearing Sandor frame reviews as both a technical practice and a human one strongly resonated with me.

That said, I wished he had gone a bit deeper into the “real-world” part of timely reviews.
He mentioned that PRs should be reviewed shortly after they’re created and should not linger for days, but the talk didn’t offer much practical advice for avoiding the ping-pong effect - especially common with junior developers or contributors unfamiliar with guidelines (or reluctant to follow them).
In my experience, even when the team has clear rules, some PRs naturally drag and slow the entire delivery pipeline.

Many stakeholders and managers still view code reviews as something that slows down delivery. As a lead developer, part of my job is to help them understand why this work is essential - but it’s not always easy. Just like testing, error handling, avoiding undefined behaviors, and building resilient designs, the value of thorough reviews often only becomes obvious when things go wrong.

And who hasn’t heard an IC complain to a manager: “My PR works ! Why is the lead dev blocking it ? I just want to deliver value and reach my monthly performance goal” . But protecting a codebase from accumulating exponential, untracked technical debt is hard to measure, yet absolutely vital. Solid reviews prevent the system from sliding toward a “point of no return,” where changes become prohibitively expensive - or nearly impossible - and development costs rise dramatically.

I also take a different stance on PR presentations. Unlike Sandor, I avoid “let me walk you through the code” meetings, because they tend to introduce biases, anchoring reviewers to the author’s narrative, and reducing the chance of catching misunderstandings.
Instead, I prefer/favor clear PR summaries and design diagrams.

Reviewers’s role then is to evaluate the possible delta between:

what was requested
what the author thinks they delivered
and what is actually in the PR’s diff

When that delta is too large, repetitive, or highlights a recurring technical error, then I second my review with a coaching sessions in order to avoid endless round-trips - thus speed-up the overall value delivery process.

Bonus: How I personally do code reviews

Over the years I refined my own approach:

Use the right tools: for instance if you’re using Microsoft VSCode then you really might want to give the microsoft/vscode-pull-request-github extension a try, so code navigation is available to best understand the code context (types, values, call hierarchy, namespaces, etc.).
Structure comments consistently, for clarity and expectations management:
```
🟢|🟡|🔴|❓|🐞 [categories...] Description
Reason/context, with references
Action requested
```
- traffic lights
  - 🟢 Not blocking
  - 🟡 Consider fixing. Add a tech-debt entry to the backlog otherwise.
  - 🔴 Blocking
  - ❓ Blocking: question (I did not understand something)
  - 🐞 Blocking: obviously a bug
- categories
  - bug
  - business (likely to degrade the users experience)
  - readability
    - naming
    - cognitive-complexity
  - design
  - performances
  - etc.
Add reference links: the C++ standard relevant section, internal documentation, guidelines, etc.
If you’re unsure about something, that uncertainty itself is - and will remain - a maintainability issue, as the IC intent is not clearly translated into code. Never hesitate to ask for clarification.
Be kind, positive and encouraging. Acknowledge the efforts.
Use some emojis like 🙂😊😅 so the user knows you’re not mad.
Include a hint of positive reinforcement in your code-review summaries (👏🥳), especially when an IC successfully applied techniques covered in recent training/mentoring sessions.

This structure keeps expectations clear and helps to keep reviews consistent and fair across all contributors.

Conclusion

Overall, Sandor’s talk was a strong reminder that code reviews are not just about code quality - they’re a social contract within the team.
When done well, they teach, support, and build trust.
When done poorly, they erode relationships.
I left the talk with a renewed motivation to continue investing in review culture and helping teams make the most of it.

🗣️Anders Schau Knatten The Two Memory Models

🎥 Video, 📄 slidedeck

What are the two memory models ?

The programming language memory model

What programming languages (C++, C, Rust, etc.) guarantee
Abstract over the physical reality
Data race rules
What are “observable behaviors”
How atomics provide/guarantee synchronization and ordering
Which reorderings the compilers are allowed to perform

The CPU/architecture memory model

Which load/store orders hardware may produce
How pipelines, store buffers, caches, and micro-ops reorder things
How architectures differ (x86 stricter, ARM/RISC-V more relaxed)

That duality - language vs. hardware - was the core concept of the talk, and understanding how they may not match each other intuitively is key to writing correct concurrent code and avoiding disasters.

At language-level

The standard describes an abstract machine, not real execution.

Compilers may reorder freely as long as observable behavior stays the same.
Data races are UBs
seq-cst gives one global total order
Acquire/release synchronizes like a lightweight mutex handoff
Relaxed atomics don’t give cross-thread ordering.

At CPU-level

CPUs reorder far more than we imagine.

x86 never reorders stores, while ARM and RISC-V can reorder stores to different addresses
Store buffers, pipelines, coalescing, etc. all affect observable ordering
👉 Looking at assembly doesn’t prove your concurrent code is correct

Mental model for developers

Not “did instruction X run before Y ?”, but “does X happen-before Y ?”

My takeaway

🤚 Disclaimer & overall impression

This talk absolutely melted my brain - in the best possible way. While I’ve always found memory ordering intriguing, this session made it clear that I’ve only been barely scratching the surface, which is so exciting.
I’ll definitely need at least one rewatch to get a slice of such a dense yet important topic: Anders covered both the language-level memory model and the CPU memory model, how they interact, and why they’re fundamentally different mental machines.

Even though I already use std::atomic regularly in simple use-cases, this talk left me with a much stronger desire to dig deeper into non-trivial patterns, lock-free reasoning, and the real consequences of memory ordering on correctness and performance.

In a nutshell, this made me realize how shallow my current mental model is around:

Subtle memory orderings
Cross-architecture behavior resilence/consistency
How atomics map to actual hardware
Why I should dig deeper into lock-free algorithms/patterns

I love the feeling of being humbled - if not a bit dumb - by a talk - it means there’s a whole new frontier to explore, thus an exciting room to level up ! 🥰

Additional resources

📅 11/07/2025

🗣️Jens Weller - Good Morning Meeting C++

Jens opened day 2 sharing how he designed and implemented - using Qt - this year’s conference merchs design for T-shirts, hoodies (Spreadshirt) and calendars (Etsy).

He also talked about his ongoing projects, including the Meeting C++ CMS and a small game-like ecosystem simulation with plants and animals acting as agents - which resonated with me, since creating entities simulations, implementing their behaviors and watching them evolve is a genuine passion of mine.
From my perspective, it’s a great way to learn (about ECS, determinism, reproducibility vs. repeatability, software-design, performances, rendering, etc.) while having lots of fun.

From there, he touched on design perspectives like SOA vs. AOS/OOP, and mentioned that the schedule had been slightly adjusted due to Victor Ciura canceling his talk. Jens also highlighted the cool stands this year: Qt’s booth with automotive automation demos, and Flow Traders’s.

He wrapped up by previewing next week’s post-conference workshops:

C++ software design - Klaus Iglberger
(canceled) multi-threading and concurrency in C++: a workshop full of live coding
AVX vectorization workshop - Ivica Bogosavljevic
Intermediate to advanced C++ - Slobodan Dmitrovic
MISRA C++ 2023 guidelines workshop - Richard Kaiser

My takeaway

I’ll definitly watch the trendy talk “More Speed & Simplicity: Practical Data-Oriented Design in C++” - Vittorio Romeo - CppCon 2025 Keynote to dig deeper into the SOA vs. AOS topic, and DOD in general.

And like always, hearing about an ecosystem simulation project reignited my own itch to spin up a fresh entity-based experiment 😅. So many things to do, so little time though.

🗣️ Frances Buontempo - Center Keynote - Stoopid Questions

🎥 Video, 📄 slidedeck

France’s keynote was a deep, reflective dive into learning, teaching, curiosity, and how important the role of so-called “stupid” questions is.
She opened by reminding us that everyone learns differently, and that - despite the internet and LLMs - real learning still takes time, efforts, and explorations.

👉 We’re rarely taught how to learn or how to teach, yet both shape our careers, and ultimately lifes.

A recurring theme was the importance of asking questions: during talks, at work, in classrooms, even when something seems obvious.
This is what I call proactive listening: will watching videos, I regularly find myself talking to the screen, anticipating the points that the speaker may/will address next.

But asking questions directly requires psychological safety and confidence - challenging a speaker, a book, a teacher, or a colleague can feel intimidating, even though they can be wrong too.
In any case, it always worth it: if you have a question, then it means that you have not understood some points as the speaker intended – and probably other participants as well.

France highlighted blockers that slow learning: school baggage, neurodiversity challenges, bad teachers, or simply feeling stuck.
She offered practical solutions/tools like rubber-ducking, shrinking the problem, exploring “what-ifs”, switching to a related task, or simply asking for help.
And just as important: learning must be a fun process - through games, surprises, experimentation, and small wins.

She also touched on emotions in teaching and learning-frustration, boredom, non-linear progress - and the need for teachers to stay patient and adaptive. Finally, she contrasted human learning with the limitations of machines: LLMs don’t learn, they don’t understand, and they often hallucinate.

This should often prompt us to ask more relevant questions, with the aim of finding a potentially relevant answer. Which, at best, is a waste of time, and at worst, a plain loss.

France closed with challenges for everyone:

Ask a question !
Try something you feel terrible at
Read a book
Give a talk.

My takeaway

For me, learning is effective over the long term only when it remains motivating and meaningful, and when it is treated as a daily practice. It should not be perceived as a constant effort or burden, but rather as dedicated time that one genuinely enjoys and values.

In practice, I have encountered many developers who become blocked not for technical reasons, but due to diminished confidence or reluctance to ask for help. Regardless of whether they identify as “junior” or not, some remain stuck for extended periods, choosing isolation over collaboration.
In a fast-evolving ecosystem such as C++, this mindset can significantly hinder both individual growth and overall team effectiveness.

I have also observed a recurring pattern - in schools, universities, and many companies - where those who ask questions are often perceived as lacking competence, particularly on technical topics. Even requesting clarifications or additional specification details may be interpreted as a lack of autonomy.
Such perceptions directly undermine psychological safety and discourage open communication.

🤦‍♂️ Ultimately, a learning culture that equates asking questions with incompetence is counterproductive and toxic.
👉 Sustainable expertise emerges not from silent struggle, misplaced pride, or biased ICs KPIs, but from curiosity, dialogue, and the confidence to seek understanding.

From my experience, side-projects work great and are often under-rated. I always encourage my ICs - and juniors in particular - to build something fun: games, simulations, little experiments, etc. because real problems expose your limits: poor design, performance bottlenecks, spaghetti code, poorly evaluated trade-offs, quick-win-but-slow-loose, etc.
Hitting those walls creates an authentic need to understand and improve, and that kind of learning sticks far better than passive theory, endless katas, or rote exercises.
While this requires time and courage, as confronting failures avoids biases and luring yourself into a false sense of understanding.

My own routine reflects this: I spend at least an hour every day - more on weekends - coding on side-projects, reading standard/books/blogs, browsing GitHub, and/or watching talks.
It’s the balance of practice and passive input that works best for me. Ultimately, as Frances emphasized, everyone needs to discover how they learn before anything else.

👉 Psychological safety is essential: teams need a kind, supportive environment where people can rely on each others without fear of judgment. Misplaced ego or pride only slows everyone down and can even lead to disasters.

🤦‍♂️ I also deeply regret that many companies still treat developer trainings - especially for juniors - as a waste of time.
This fuels the myth of the so-called “full-stack dev-sec-ops 10x engineer” who is magically productive straight out of school, and can perform/achieve any task autonomously/independently in a short amount of time.
Software development is a team sport that requires collaboration, shared understanding, and deliberate investment in people.

👉 Training is not a cost to be minimized, but a prerequisite for building resilient teams and sustainable software.
👉 Real growth requires time, guidance, and a learning culture.

In that spirit, I asked France about something I often struggle with: how to evaluate retention when designing a course, as each step depends on the previous one.

Her answer was simple and practical:

If some point takes longer to teach than expected, it’s a sign something’s wrong.
Make it explicit that everyone must understand before moving on
And (of course) constantly encourage questions

This strongly resonates with my own experience: meaningful practice, supportive peers, and an environment where questions are welcomed are far more valuable than any amount of passive learning.

🗣️ Jonathan Müller - Cache-Friendly C++

🎥 Video, 📄 slidedeck

Jonathan Müller - also known as foonathan - gave an accessible overview about what designing cache-friendly C++ code really means, and why std::vector in particular should almost always be your default container.
This talk is essentially a modern, refined follow-up to his 2018 “Writing Cache-Friendly C++” presentation here back at MeetingCpp.

He started from first principles: CPUs are extremely fast, but memory is not.
Accessing main memory way slower than accessing data already stored in a CPU cache.
This is why CPUs rely on several layers of caches (L1, L2, L3): L1 is tiny but extremely fast, L2 is slower but larger, and L3 is larger still but slower again - yet still much faster than accessing memory.

To run fast code, your data needs to reach these caches efficiently. Which starts with designing cache-friendly code and benchmarking such designs for your targeted architecture.

Cache-friendly code: why does it matter ?

Cache-friendly programming is fundamentally about data locality:

Keeping related data contiguous and in a predictable layout
Minimizing memory footprint so more data fits inside a single cache line
Accessing memory sequentially whenever possible.

If data is well packed and accessed in order, CPUs can prefetch it efficiently and process it with minimal cache misses.

Data structures matter

This is why a sorted std::vector often beats std::set or std::unordered-set:

std::vector is contiguous and/thus predictable
Tree-based containers force pointer chasing and scattered memory access
Open-addressing hash tables do better than node-based ones for the same reason.

Type size and layout affect cache use

Jonathan highlighted how even small layout decisions influence cache footprint:

Reordering struct members reduces padding
Misaligned or sparsely laid-out data wastes precious cache space
Bitfields can sometimes hurt due to extra work the compiler must generate

Prefetching & cache lines

CPUs move memory in cache lines, not bytes.
Sequential access allows the hardware to prefetch aggressively.
Random access breaks that pipeline and forces costly fetches from DRAM.

Code is data too

CPU instructions are stored in memory

Avoid long branches
Avoid indirect jumps
Miniminze the size of hot code

Jonathan mentioned that sum then increments rather than increments the sum can be significantly - if not, way - faster on some CPU, which feels kinda bizard.

Data-Oriented Design (DOD)

He emphasized thinking in terms of algorithms and data flows, not objects.

Process N items together
Re-organize your data to match access patterns
Leverage SoA - rather than AoS - layouts when appropriate

Multicore pitfalls

False sharing - two threads modifying unrelated values that live in the same cache line - can devastate scalability. Padding structs with std::hardware-destructive-interference-size - minimum offset between two objects to avoid false sharing - helps avoid this.

My takeaway

This talk reinforced how critical it is - especially in performance-sensitive code - to think consciously about how data lives in memory. Choosing containers, controlling alignment, avoiding unnecessary pointer dereferencing: these things matter more than most teams realize. Redesigning an entire system because of performance issues is often a long and costly process, so it’s far better to foreacast such problems and address them early.

I’ve long favored cache-friendly containers like std::array and std::vector, and this talk validated that instinct.
std::array remains one of my favorite containers because it behaves both like a tuple and a range while keeping data contiguous 🥰. From experience, std::map and std::set often loose to a simple std::vector> because contiguous memory access beats pointer-heavy tree traversal in many real workloads.
Also, I remember struggling with performances issues when digging into trie containers implementations, which is from my perspective a meaningful illustration of the “size in memory vs. speed” tradeoff.

Jonathan’s insights also made me want to explore Data-Oriented Design more deeply for large-scale or simulation-style workloads - where data locality matters a lot.

I’ll definitely continue digging into cache-friendly programming. It still feels underrated in the industry: too many teams default to pointer-rich OOP AoS designs (“everything is a std::shared-ptr”) without considering the cost on locality, cache lines, and ultimately performances.

This talk was a great reminder to structure programs around access patterns and data, not just obvious-for-humans abstractions.

🗣️ Andreas Fertig - Embedded-Friendly C++: Features That Make a Difference

🎥 Video, 📄 slidedeck

Andreas links: cppinsights.io, Youtube channel, talks slide-decks.

The talk was framed around a simple, relatable scenario: building embedded lightbulb controllers that communicate over a network. Using this example, Andreas walked through a series of common embedded tasks - parsing input, handling raw bytes, dealing with endianness, interfacing with C APIs, and managing memory safely - and showed how contemporain C++ (C++20/23/26) provides clean, safe, and expressive solutions.

Content

Andreas demonstrated a broad range of features, each tied to a concrete use-case:

Safe parsing & input handling: std::span, std::expected, std::from-chars, and std::to-array.
Expressive syntax: user-defined string literals to improve readability.
Safe byte manipulation: std::bit-cast to reinterpret data without undefined behavior (rather than plain reinterpret-cast).
Enum handling: std::to-underlying, std::underlying-type.
Dealing with network data: std::start-lifetime-as to reinterpret packet bytes safely (as opposed to the common reinterpret-cast approach).
Endianness: std::endian and std::byteswap.
Resource management: std::unique-ptr with custom deleters for wrapping legacy APIs.
Modern compile-time features: constexpr, consteval, constinit, if consteval, and static constexpr local variables.

Overall, the talk was a tour of “modern tools solving common/old embedded problems” shown through minimal, digestible and realistic/plausible examples.

My takeaway

As always with Andreas, I was struck by how incredibly didactic and clear he is 🤩.
His teaching style is calm, peaceful, and remarkably effective - a masterclass for any C++ trainer like me.

I especially appreciated how every feature was grounded in a real embedded need, showing not just what modern C++ offers, but why it matters in constrained environments.

Most - if not all - of the examples reminded me of code I’ve seen many times in peer-reviews. In my experience, especially when related to the embedded world, contributors still tend to write old-style, error-prone code using patterns like reinterpret-cast, manual bit manipulations, index-based buffer manipulations, unions, and so on.

This coding style, in my view, often originates from legacy teaching approaches that are still widespread today. These approaches emphasize rigid rules, prescriptive “do and don’t” lists, katas, and patterns. When developers are taught only how to use a hammer, every problem inevitably starts to look like a nail.
This results in two major issues: anchoring knowledge at some point in time rather than keep learning modern incoming features/techniques, and inhibating creativity, flexibility, and utimately pragmatism. This reduces software development to a simplistic pattern-matching exercise, where developers merely choose between predefined solutions instead of engaging in analysis, design, and trade-off evaluation.

The result is code - thus, PR - that is long, hard to read, difficult to maintain, and ultimately less safe and less reliable.

A few personal reflections:

Like always: contemporain C++ really simplifies codebases, including the ones related to embedded.
Tasks that once required brittle tricks-casting bytes, parsing raw packets, converting enums-now have safe, standardized solutions.
The combination of std::span + std::expected + std::from-chars is something I already promote at work. It’s such a clean way to handle raw data and error-cases.
Compile-time features (consteval, constinit, if-consteval) offer a great way to enforce correctness without runtime cost.
- I particularly appreciated the if not consteval { std::println("", ...); } trick that I’ll make sure to reuse, so I’ll extend my constexpr tests to functions that might emit logs and user-notifications.
std::unique-ptr with custom deleters remains an easy and elegant bridge to legacy C APIs.

I’ll make sure to dig into the presented features which I’m not familiar with yet, like std::start-lifetime-as and std::has-unique-object-representations.

I came away with several insights I can apply right away, and an even greater appreciation for Andreas’s teaching style. His approach genuinely inspired me to revisit my own training slide-decks, so I can make my courses more grounded in real-world needs and even more accessible; which might increase my trainings retention rate.

🗣️ Daniela Engert - Towards Safety and Security in C++26

🎥 Video, 📄 slidedeck

Disclaimer: I chose to attend Daniela Engert’s talk instead of Evgenii Seliverstov’s *“Sanitize for your Sanity: Sanitizers tools for Modern C++”, but I’ll definitely watch Evgenii’s session as soon as the recording becomes available.*

“Simplicity is a prerequisite for reliability”, Edsger W. Dijkstra.

Content

Daniela’s session fit perfectly within this year’s recurring theme: tackling fears, misconceptions, and outdated beliefs about C++ being inherently unsafe. She grounded the discussion in real data: around 70% of Microsoft’s and Chromium’s CVEs come from memory safety issues, and the top CWE categories are exactly the usual out-of-bounds read/write access, use-after-free, null dereferences, integer overflows.

She reframed safety in its broad sense: memory safety, functional safety, system safety. And she walked through how contemporain C++ has been steadily strengthening its safety model.

Key points included:

Undefined behaviors are everywhere (about 90 occurrences in language-specific part of the standard), but UBs exist for a reason: so compilers can optimize to generate faster instructions, not to punish developers.
Constant evaluation is becoming a cornerstone of safety: all UBs are detected and refused during constant evaluation.
C++ is getting safer with every standard, every 3 years. constexpr support keeps expanding (remember Hana Dusikova proposal last winter)
Standard library hardening (P3471) brings runtime-checked preconditions to the STL when enabled.
Trade-off: safety vs. performance - but if performance allows it, hardening is an immediate win.
Contract support & partial program correctness (P2900) opens the door to precise diagnostics and better program correctness, coming with
- pre, post, and contract-assert,
- and policy/semantics like ignore, observe, enforce, and quick-enforce.
Observable behavior & checkpoints (P1494) prevent compilers from reordering checks in ways that could undermine contract guarantees.
Beyond C++26: profiles like P3081 (Core safety profiles for C++26) propose opt-in enforcement of type, bounds, lifetime and arithmetic, potentially moving C++ toward even safer subsets of the language.

Overall, her talk showed a clear trajectory: the language and the standard library are evolving toward practical, opt-in safety - without abandoning performance.

My takeaway

Use constant-evaluation to detect UBs

This talk reinforced a strong trend I’ve observed across Meeting C++ 2024: the community is actively challenging outdated narratives about C++ being “unsafe by nature”. Every new standard brings meaningful safety features, better diagnostics, and more predictable execution models.

👉 I’m particularly excited about contracts. I want to start integrating them into my daily work as soon as tooling and compilers stabilize - it’s exactly the kind of self-documenting, correctness-driven mechanism I’ve been waiting for, just like concepts before in another way (like for constrained type-erasures / TEPS).

I’m also eager to learn more about STL hardening, because I suspect enabling it will reveal lots of subtle bugs hidden in many existing codebases: bugs that today manifest only as “mysterious UB”, and which are too often worked-around with dirty/questionable hot-fixes.

In truth, I almost have a kind of PTSD when it comes to undefined behavior 😨.
Years ago - back when I was a junior developer -, I was involved in a project where a team spent nearly a full year chasing one particularly nasty UB issue (involving memory, concurrency, and AFAIR, some SIOF).
It delayed delivery, ramped up pressure on everyone, and left managers baffled - pushing for quick, superficial fixes instead of a real investigation 🤦‍♂️. Over and over again.
There is a French expression that fits such a situation: “confondre vitesse et précipitation” (literally: mistaking haste for effectiveness).
By the time a proper investigation was finally allowed and the full scope of the problem became clear, costs were already high and the organization’s credibility with the client was seriously at risk. At the time, I was still a junior developer, with only a limited understanding of the C++ standard. But that is a story for another day.

Seeing the direction C++ is currently taking when it comes to safety - contracts, profiles, hardened libraries, expanded constant evaluation support - makes me optimistic.
Far from being an old unsafe language - as the gossips and the ignorant says - , C++ is steadily equipping developers with better tools to write safe, robust, modern software.

The beast keeps evolving to meet the need of the industry, and I can’t wait to see what’s coming next.
This talk made that trajectory toward safety clearer than ever, and increased my appetite.

🗣️ Raymi Klingers - 25+ Years of pathfinding problems with C++

🎥 Video, 📄 slidedeck

Raymi’s talk explored more than two decades of pathfinding challenges in the Age of Empires franchise (among the games that most shaped my early interest in real-time strategy as a child), from the early Ensemble Studios codebases to the modern remasters developed by Forgotten Empires.

Content

It was a deep dive into how pathfinding systems evolve over time,
especially when dealing with legacy code, performance constraints, and increasing community expectations.
The talk compared different approaches used in major RTS/MOBA titles (AoE2, AoE3 DE, Age of Mythology, StarCraft II 😍, League of Legends) and highlighted how each game tackles core issues such as:

pushing vs. non-pushing units
bumping vs. non-bumping movement
formation handling
glitches like units clipping through walls
overall pathfinding accuracy vs. performance tradeoffs

Raymi walked through the multi-year process of fixing and improving AoE pathfinding:

intensive fuzz-testing to expose subtle bugs
iterative bugfixing while ensuring no regressions
dealing with floating-point precision loss (and adopting fixed-point to mitigate it)
challenges with convex hull computations and complexity constraints
the costliness of ray-tracing-based approaches

It was also framed in the context of remastering/modernizing old codebases - balancing “don’t break the game the community loves” vs. “fix the long-standing problems players always complained about.”

My takeaway

Even though this talk was engaging - especially because I love simulations and game mechanics - it felt a bit rushed and dense to me (despite tons of cool slides tho !), probably due to time constraints or stress.
As a result, I couldn’t fully grasp the nuances of the thoughts, decision process and algorithms; but the development journey was still fascinating.

Pathfinding has always been a captivating topic to me: I’ve built many small simulations and games on my spare time, but I’ve often avoided using - thus, implementing - pathfinding because I felt underprepared, worried about designing something both correct and performant. Still, the talk reinforced how much I want to learn more about it.

It also made me reflect on how pathfinding shares conceptual similarities (even if loosely) with collision detection engines: spatial reasoning, constraints, approximations, and the “classic” tradeoff between accuracy and performance.

This talk definitely encouraged me to dig deeper into:

How large-scale games keep pathfinding predictable, stable, and maintainable
The tradeoffs between precision and speed
Historical/classic vs. modern pathfinding techniques
How to make path-finding efficient yet testable
Integrals vs. floating-point usage and strategies in performance-critical systems

This is the fourth talk that has sparked/rekindled my urge to build new simulations or games. Resisting the temptation is getting harder each time 😅.

📅 11/08/2025

🗣️ Klaus Iglberger - The Real Problem of C++

🎥 Video, 📄 slidedeck

Klaus opened by addressing a harsh reality: major institutions such as the NSA, the White House / ONCD (source not available anymore), and the European Union (via the Cyber Resilience Act) have publicly claimed that C++ is not appropriate for developing safe softwares.
Journalists amplified this message - often conflating C and C++ under the misleading “C/C++” label - feeding an increasingly widespread belief that C++ is an unreliable and outdated language.
For the record, C and C++ are respectively rated 2nd and 4th most used programming languages according to the TIOBE index in Jan. 2026.

Klaus’s position is clear: C++ is unsafe … if you are still writing C++ like back in 1998.

The real issue is not the language itself, but the mindset of many developers who do not leverage the modern features and tools introduced over the last ~30 years.

Safety vs. performance: an historical tradeoff

“C++ does not give you performance; it gives you control over performance.”, Chandler Carruth.

C++ always leaned toward performance when design tradeoffs had to be made.
But modern C++ allows us to build safety on top of performance, while the other way around is not something intrinsically doable.

👉 We - as developers - must use that control wisely.

Bounds safety

“If you want to improve code quality in your organization, I would say, take all your coding guideline and replace then with the one goal. That’s how important I think this one goal is: No raw loops. This will make the biggest change in code quality with your organization”, Sean Parent

Klaus insists this is the biggest category of avoidable safety bugs. Raw loops are simply outdated, unsafe, thus should be avoided.

Prefer std::ranges and standards algorithms. If you are stuck with pre-C++20 for some reasons, then use the range-v3 library.
The key issue here is not a language problem: it’s resistance/reluctance to changing habits.

Some peoples may have common misconceptions about using ranges over index-based for-loops: “it’s difficult, it’s slow”.
They are wrong: it is not, and that’s what I call pragmatic simplicity. From your perspective, which of the following code is the most understandable for a non-developer ?

// C++98 style
std::vector<int> result;
for (int i = 1; i <= 10; ++i){
    if (i % 2 == 0){
        result.push-back(i * i);
    }
}
std::cout << "result: [";
for (int i = 0; i < result.size(); ++i)
    std::cout << result[i] << (i == result.size() - 1 ? "" : ", ");
std::cout << "]\n";

// C++23 style
auto view = 
  std::views::iota(1, 11)
| std::views::filter(is-even)
| std::views::transform(to-square)
;
std::println("result: {}", view);

See the demonstration here.

😉 I notice such a resistance a lot when training developers, but ultimately they all come to understand that pragmatic simplicity is just better than pattern-recognition, for multiple reasons: less code, less bugs, easier-to-write and easier-to-maintain.

Undefined behaviors: the silent killers

As Daniela Engert mentioned in a previous talk (see the conference previous day, above), UBs appear ~90 times in the C++ standard, but it exists for a reason: it enables aggressive optimizations.

“Evaluation of a constant expression ([expr.const]) never exhibits behavior explicitly specified as undefined in intro through cpp.”
C++ standard, 3.65 [defns.undefined] undefined behavior

However, modern C++ gives tools to catch UB early:

Undefined behaviors are not allowed at compile-time.
Make as much code as possible constexpr.
Use consteval for tests: static-assert(test()).
Test both compile-time and runtime paths.

👉 As constexpr support expands each standard cycle, the space for UB keeps shrinking.

Type safety through strong types

Many bugs come from:

Swapped function arguments
Implicit conversions
Narrowing conversions

Strong types solve this elegantly:

explicit constructors
type constraints (std::same-as)
libraries like rollbear/strong-type, foonathan/type-safe, and mp-units.

Same performance, significantly safer. That’s what such zero-cost abstractions are all about.

Lifetime safety: value semantics over inheritance

Classic/legacy dogmatic OOP design in C++ leads to:

pointer-heavy code
dynamic allocations
virtual calls / vtables
complex lifetime management

Klaus emphasized that value semantics should be our default, which echoes with his previous talks like C++ Design Patterns - The Most Common Misconceptions (2 of N) - CppCon 2024.

For instance, std::variant can replace entire inheritance hierarchies:

no base classes
no raw pointers
no virtual dispatch
fewer allocations
safer code, simpler lifetime management

This captures the spirit of the “modern C++” mindset.
👉 But it’s worth adding a nuance: the goal is not to replace one blindly followed dogma with another.

Speaking of value semantic, I noticed that C++26 comes with std::polymorphic and std::indirect to help promote value semantic.
See p3019 - indirect and polymorphic: Vocabulary Types for Composite Class Design

Conclusion: the real problem is a people problem

“No matter what the problem is, it’s always a people problem.” - Gerald M. Weinberg

Klaus closed with one of the strongest messages of the whole conference:

Millions of C++ developers don’t keep up with modern practices.
Many still write 1990s-style C++ and then blame the language.
Meanwhile, misinformation spreads loudly on social media.

His point was not to shame developers, but to remind the experts - us - to teach, mentor, write, and correct misconceptions.
👉 If we don’t, loud voices will drive the narrative, not factual ones.

My takeaway

I’ve always admired Klaus’s teaching style: deeply pragmatic, calm, rational, and laser-focused on facts over dogmas.
He questions sacred cows, re-evaluates assumptions, and isn’t afraid to challenge outdated habits.
👉 That resonates strongly with my own philosophy as a trainer: break beliefs, fight misconceptions, and replace them with practical, evidence-based reasoning.

This talk felt perfectly aligned with the overall implicit “safety” theme of this year’s conference. It tackled the elephant in the room head-on by naming the NSA, the White House, and the EU’s “C++ is unsafe” claims.
Honestly, I’m fed up (no pune intended) with this narrative, that is leading to some kind of a panick feeling among lots of my peers, but also managers and tech-leads.
😒 And especially when it’s fueled by shallow takes, buzzwords, and biased/bad/malicious analogies.

This strongly echoes with the amazing MeetingCpp 2024 closing keynote “Collective Amnesia ?”, from Peter Sommerlad, in which he warned the audience against trend-driven/cargo-cult decision-makers, as well as simplistic solutions, ignorance and lack of pragmatism in general.

Klaus reminded me that safety in C++ is not a pipe dream. It’s achievable today if we adopt modern techniques:

ranges over raw loops
strong types everywhere
constexpr and consteval to eliminate UBs
value semantics as a default
variants over inheritance
using tools, sanitizers, static analyzers, guidelines.

His talk strengthened my belief that the real issue is not the language - it’s the collective mindset. And as someone who keeps learning, attending conferences, reading papers, and teaching, I’m part of the group that must mentor others.

If we - those who stay up-to-date - share our knowledge, challenge dogma, and counter misinformation, the “C++ is unsafe” rhetoric will fade. If we don’t, we leave the floor to uninformed opinions.

This talk rekindled my motivation to teach contemporain, safe C++; to fight bullshit wherever it comes from - old university teachings, trends, buzzwords, or social-media spread myths - and to push for a community that values evidence and pragmatism over beliefs and dogmas.

👉 From my perspective, the C++ #1 strengh is its standard - the ultimate, formal source of thruth.
However, most C++ developers don’t even know it exists, and favor unreliable sources such as LLMs, forums, SO, etc.

Klaus delivered one of the clearest and most impactful messages of the entire conference, and I’m genuinely grateful for it.
He concluded with a call to action:

We must keep improving the language so that writing safe code becomes easier.
We must communicate and educate more effectively about how to write C++ properly.

Additional sources

The Case for Memory Safe Roadmaps - Why Both C-Suite Executives and Technical Experts Need to Take Memory Safe Coding Seriously, December 2023, CISA

NSA

FBI

ASD’s ACSC

CCCS

NCSC-UK

NCSC-NZ

CERT-NZ.

Software Memory Safety, April 2023, National Security Agency Cybersecurity Information Sheet.
Peter Sommerlad - “Collective Amnesia ?” - Meeting Cpp 2024

🗣️ Roth Michaels - How to become obsolete: a guide to software engineering mentorship

🎥 Video, 📄 slidedeck

Roth framed his talk around a question we - experienced engineers - all eventually face: How to lead effectively, share knowledge, yet still avoid being the bottleneck ?
The talk was heavily inspired by Meeting C++ 2024 themes (Titus Winters on “Fear in C++”, Kate Gregory on “Aging Developers”), and tied to Roth own experience at Native Instruments.
The central metaphor was free jazz - a style built on improvisation, shared leadership, and trust, but also breaking conventions, to get rids of limitations in order to promote creativity.

Why become obsolete ?

The goal of a senior engineer or tech-lead should not be to remain indispensable forever. If the team relies on you for every decision, you will never move on to new opportunities, and the team will never grow.
👉 In free jazz terms: you’re not the conductor - you’re another musician in the ensemble.

Becoming “obsolete” means that:

You’ve successfully shared leadership
The team can run without you
You’ve built resilient structures for decision-making

And when that happens, you gain the space to breathe and ask to yourself : “What’s the next important thing I can achieve/work on now ?”

Shared technical leadership

Roth emphasized pair-leadership, similar to pair-programming but applied to ownership of systems, architectures, and projects directions.
👉 This promotes resilience and stability among the team. Two leaders share responsibilities:

Project oversight
Architectural decisions
Reviewing code
Offering technical expertise

This ensures that if one person is unavailable at a moment (sick or on vacation) then nothing falls apart.
Knowledge redundancy is a leadership achievement.

Mentorship must be part of the onboarding process: new hires should pair with experienced peoples, to be shown:

What the project’s architecture is
How the codebase is organized
What the guidelines, principles and best-practices are
Be taught thought processes - not just tasks (decision-making, weightening trade-offs, etc.)

Identifying and developing leaders

👉 Roth insisted that true leadership often lies in reluctant leaders, not the loudest voices.
Technical leadership should not be exclusive to extroverts or natural talkers, but instead:

Find subject-matter experts
Observe quiet but thoughtful engineers
Rotate projects leaderships
Every project can (and should) have a different project lead.

Practical mentorship techniques

Some key practices Roth highlighted:

Wikis usually fail: too long to write, rarely read -> not cost-effective
Answer questions publicly, not in private channels
Organize live discussions for design decisions -> collective intelligence
Direct questions to subject-matter experts
Provide references, not only answers -> formal sources of truth

Talking through engineering problems, asking them

What is the actual problem?
What is your thinking?
Why is this a good - or bad - idea?

💡 And be transparent about the strength of your ideas: some are strong, some are half-baked.

👉 Leaders’ opinions carry lots of weight; they must communicate uncertainty clearly.

Pair-debugging is an incredibly powerful teaching tool

Ask “show it to me in the debugger”
Place breakpoints, watchpoints
Explore the state together

💡 It lets you teach not only the solution, but your whole investigation and decision-making process.

Code-reviews: differenciate types of comments

Neat suggestions
Educational remarks
Blockers / must-fix

⚠️ He also warned about “LGTM anxiety”: is it genuine approval or avoidance ? When code is complex (TMP, concurrency, etc.), do live walkthroughs, but remain aware of the bias risk (e.g false sense of understanding).

Encourage psychological safety

Roth advocates bragging about mistakes, reminding me of the “monkey of the week” practice, which is encouraging your ICs to laugh about their own mistake - in a public channel, during sprint retrospective, etc.

👉 Teams need a culture where failure is acceptable and even encouraged as a learning mechanism.

💡Leadership = vulnerability + openness + candor.

Q&A

I had the opportunity to ask about presenting complex PRs (TMP, concurrency, multi-threading, etc.) without biasing reviewers.
Roth’s answer was straightforward:

A reviewer must understand every part of the PR.
If they don’t, they should ask and learn.
If people don’t understand a pattern or technics, then write/share minimal examples to teach it to others.

As a lead developer, I have often seen contributors schedule “PR presentation” sessions with me. While well-intentioned, these meetings can - from my perspective/experience - create a false sense of shared understanding and introduce additional pressure to approve the change quickly, often in order to meet deadlines or delivery milestones.

I eventually decided to discourage such meetings altogether, as they too often left me with the discomfortable impression that I had agreed to a change without fully scrutinizing it. In several cases, this resulted in bug-prone and/or hard-to-maintain code making its way into the codebase-despite an apparent consensus reached during the discussion.

These meetings were replaced with design and/or implementation strategy sign-offs, during which developers present their intended approach (for example, how they plan to design a feature or resolve an issue).
Once the pull request is submitted, a follow-up discussion takes place to assess the result and to analyze any delta between the original intent/promise and the final result.

My Takeaway

This talk hit close to home for me, because mentorship and technical leadership have become a growing part of my own work.

I loved how humble and empathic Roth was, and how his analogy with free jazz was relevant: guiding without dictating, structuring without suppressing creativity, and enabling others to improvise confidently.
His emphasis on becoming “obsolete” is something I strongly believe in: leadership isn’t about centralizing authority, but about distributing it so the team can thrive even without you.

👉 Unfortunately, this ideal is often contrasted sharply by what we see in practice.
Too many leaders - especially managers - lacking technical understanding still impose ill-informed decisions with little or no justification.
This kind of unilateral, arbitrary behavior echoes the textbook definition fascism: an authoritarian, arbitrary, and imposing attitude exerted by an individual over a group.
👉 Leadership and respect should not be asserted, but earned by demonstrating kindness, guidance, and mentorship.

His point about reluctant leaders resonated particularly deeply. In many teams, the loudest voices dominate by default, while some of the most thoughtful, reliable, and technically insightful engineers are quieter. Identifying and nurturing them is a huge multiplier for team health.
👉 Extroverts who like to brag and to tell stories are too often favored, to the detriment of competent introverts.

💡 Related to this, I recently had the opportunity to discuss what could be described as courtier/courtesan/sycophant roles: ambitious individuals who are highly articulate, socially adept, and well-regarded by top-level management, yet whose influence is primarily performative rather than grounded in technical reality.

By overpromising outcomes, underestimating complexity, or presenting an overly optimistic view of feasibility and timelines, they create a false sense of shared understanding at the management level.
This, in turn, translates into unrealistic expectations, compressed deadlines, and sustained pressure on engineering teams.
Despite being frequently rewarded and promoted for their apparent effectiveness, such behavior is ultimately detrimental to project delivery, team morale, and long-term trust.

I also appreciated his very pragmatic mentoring techniques: pair-debugging, public Q&A/AMAs, tackle uncertainty, and using discussions as a way to transmit thinking patterns, not just decisions.
From my perspective, building a shared/common understanding of a project’s vision/goal, philosophy, architecture, but also tradeoffs, milestones, and constraints is a key to achieving success.

💡 To use nautical metaphor, a software team is much like a ship’s crew.
When the crew does not know where the vessel is headed, does not trust the captain, or is not given a clear course - its destination, waypoints, and the reasons behind the journey - even the most skilled sailors will struggle. Effort becomes fragmented, initiative fades, and progress turns erratic.

Conversely, when the destination is explicit, the route is understood, and leadership is trusted,
then each member of the crew can act with confidence and autonomy. In such conditions, individual expertise compounds rather than conflicts, and the ship advances steadily toward its goal, even in rough seas.

Overall, the talk was refreshing, human, and deeply practical: a reminder that leadership is less about the cult of personnality, and more about creating ecosystems where others can grow, take ownership, and eventually replace you.

🗣️ Kerstin Keller - Why managing C++ dependencies is hard (and what to do about it)

🎥 Video, 📄 slidedeck

With this talk, Kerstin Keller (AUTOMOVIO) discussed why C++ dependency management is uniquely difficult, and how modern tools - and Conan in particular - can help.
This is a nice addition to her talk back at Meeting Cpp 2024 Clean CMake for C++ (library) developers.

Dependency management matters because most - if not, all - projects rely on many external components,
but keeping everything portable, compatible and scalable is a non-trivial challenge.

She began by explaining that dependencies are usually extracted outside the main repository: projects combining their own code with the full source of all external libraries would simply be too big.

What are dependencies & what is dependency management ?

A dependency is any external component (library, framework, module, service…) required to compile or run.
Dependency management is about orchestrating these components across versions, environments, and build configurations.

Semantic versioning (major.minor.patch) is a contract between library authors and users, and reproducible builds require consistent source, environment, and instructions.

How developers handle dependencies nowadays ?

Source-based vendoring (copying the dependency into the repo) -> not scalable, too heavy, hard to update
Build-system-based (like CMake’s FetchContent)
Dependency managers (Conan, vcpkg, Hunter, Biicode, etc. that are still rarely used in C++ projects)
System packages (Linux distros, like apt, yum, etc.)

💡 Conan feels great

Dependency managers help solve multi-version graphs, transitive dependencies, and mismatched constraints.

💡 Pin major versions, avoid broad ranges.

Why C++ dependencies management is unique and hard ?

Three main challenges:

Binary compatibility: When is an existing package safe to reuse ?
Tools compute a package ID hash (compiler, options, build settings) to detect ABI compatibility.
No standard build system: C++ projects use CMake, Meson, Bazel, custom/hands-written Makefiles, etc.
Conan integration supports most.
No standard package format: Different ecosystems lack a shared way to describe installable artifacts.
👉 The proposed solution: CPS (Common Package Specification) - a JSon-based declarative description of how packages may easily consume each others, from a build perspective.

💡 Both CMake and Meson are experimenting with CPS support.

Inputs from the Q&A

Conan integrates well with JFrog Artifactory.
CMake Package Manager (CPM) still operates at the build-source level, not binary level.
Conan vs vcpkg: Conan supports binary packages out of the box, reducing build times for large dependency graphs.
Conan profiles can live in a central Git repository.
Conan can generate CMake toolchain files.

My Takeaway

In a nutshell:

Dependencies form complex graphs; dependency managers automate retrieval and updates.
Lockfiles are essential for reproducible builds.
Some may complain about the C++ ecosystem lacking a standardized packaging and build tooling, which might make dependency managers harder to implement.
Common Package Specification (CPS) is a promising cross-tooling package description format the community should support.
👉 Use Conan.

I spend a lot of time building resilient/reliable, portable, modular C++ systems (including some with ROS !), and dependency management is often a central pain point.

From my perspective, this talk evangelized strongly about “just use Conan”, but this seems to be a strong and realistic tool to tackle dependency-management related issues nowadays (ABI compatibility, package format standardisation, and build systems homogeneosity, etc.).

Honestly, I mostly use CMake’s FetchContent. Sometime with a front built on top to promote consistency and a better API: CPM or a homemade one.
And it works not too bad: sure, fetching takes time, but then most of my projects take from a fistful of seconds up to 2 minutes to build, even larger ones. Especially because nowadays, most C++ libraries are - or offer some variants as (like fmt with FMT-HEADER-ONLY) - header-only.

👉 Although, I like A LOT the idea of just pressing the build button in my IDE, and let the project(s) take care of its dependency tree all by itself.
Attempting to use, build or contribute to some GitHub projects still often devolves into an iterative cycle of missing dependencies, manual installation, and repeated build failures.

From my experience, still too many companies often manage dependencies with a mix of:

Embbed everything in a Docker (dev)container using the OS package-mananagers (apt, yum, etc.).
git submodules
copy-pasted files directly in the source tree 🤢
CMake FetchContent and/or file(DOWNLOAD …).

The CPS part was especially insightful, as I was not aware of such an initiative: C++ desperately needs a unified package description, and hearing that CMake and Meson are converging on something concrete is encouraging.

Overall, I came out with a clearer overall picture of why dependency managers in C++ feel so rough, why I often struggle with it, and how the ecosystem might evolve in a - hopefully, near - future.
It’ll also make sure to give Conan a decent try when I’ll have the opportunity !

Additional resources

🗣️ Jens Weller - Meeting C++ update

🎥 Video, 📄 slidedeck

Like every year, Jens Weller shared a transparent update on the state of Meeting C++, and the broader conference ecosystem.

While the conference reaches nearly 100000 online visitors compared to about 230 onsite attendees, 2025 has been economically challenging: frozen training budgets, fewer committed sponsors, and rising fixed costs - especially for hybrid events hosted in high-quality venues.
Despite this, Meeting C++ is still standing after 13 years, this iteration being described by Jens as “the best conference in the worst year”, though just barely breaking even. Jens was clear: the conference must continue to evolve & adapt, as running it the same way has become too risky.

What’s next ?

Meeting C++ has already diversified significantly to stay sustainable: online shops (hoodies and tshirts, and calendars), fund-raising initiatives, paid services (trainings, code reviews), live and pre-recorded talks, job fairs, newsletters, blogs, blogroll, and experiments with new online formats like AMAs, livestreams, and speaker interviews (check the youtube channel).

Jens also emphasized the foundational role of C++ user groups, which were key to launching Meeting C++ in the first place and remain central to its mission-supporting new groups, sharing their events, and connecting local C++ communities.

2026 conference

The next Meeting C++ conference is planned for November 26-28 2026, again in Berlin (Andel Hotel), with both onsite and online participation.
Jens encouraged attendees to support the conference early by buying tickets sooner in future years.
The update closed with heartfelt thanks to sponsors, volunteers, speakers, and attendees, and the C++ community.

Hommage to Rainer Grimm

The update ended with an unplanned, emotional homage paid to Rainer Grimm, who recently passed away from ALS (amyotrophic lateral sclerosis), possibly linked to (long) Covid.
Jens also shared the symbolic journey of Cippi the puppet accompanying Klaus Iglberger to conferences around the world, keeping Rainer’s memory alive within the C++ community.

👉 Go check Cippi’s blog !

(I put this screenshot twice on purpose)

⚡Lightning talks

⚡ James McNellis Our most teacherous adversary

🎥 Video, 📄 slidedeck

James humorously reminded us that as C++ developers, we sometime over-trust compilers, which might break our code whenever the standard allows them to.
His example with bool illustrated how seemingly harmless types can behave unpredictably across privilege or ABI boundaries.

To my knowledge, bool suffers from an unstable, implementation-defined representation - as the C++ standard does not fix how it is represented in memory. It just may vary across compilers and plateforms, from 1 byte as bit value (0 or 1), 1 byte (0 or non-zero, like 42), 4 bytes, packed or padded in structs, etc.

bool - integer type, capable of holding one of the two values: true or false. The value of sizeof(bool) is implementation defined and might differ from 1.
cppreference

👉 Takeaway: never use bool in data structures that cross boundaries like files, networks, or IPC.
Stuch a type can be quite pitfall - especially for junior developers -, and safer explicit fixed-width integer types should be preferred.
Beyond the technical aspect, this once again demonstrates how important it is for us developers to be well-aware of the standard, rather than constructing a mental representation that may differ from reality; and for trainers/teachers to not over-simplify things.

💡 This brings to my mind A.Einstein’s quote ”[…] the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.”,
often paraphrased as “Everything should be made as simple as possible, but not simpler”.

From my perspective, that’s what C++ is fundamentally about: continuously expanding what’s possible to achieve with code.

✋Allow me a quick digression: people often complain that C++ has a steep learning curve (and I partly agree), using things like PRNGs as an example. Sure, Python’s random module gives you a simple API - dice-roll = random.randint(1, 12) - and it works. But what’s the seed ? What distribution is being used ? If you’re simulating the sum of two dices, you’d probably prefer a Gaussian-like distribution rather than a uniform one.
Which is perfectly feasible in Python, but not without undermining the fallacious argument of simplicity.

Giving it a quite/naive quick shot (disclaimer: I’m not a Python developer, not into maths):

Python
C++

⚡ Rahel Natalie Engel - let them eat cake

🎥 Video, 📄 slidedeck

Rahel discussed diversity challenges in tech and shared lessons from university diversity and outreach programs.
Many beginners start with visual programming tools like Scratch due to time and accessibility constraints, but this often makes the transition to text-based programming difficult.

As a solution, she presented catpie, an accessible hybrid visual–text tool meant to ease that transition and make early learning more accessible.

💡 A thoughtful reminder that the tools we choose for beginners often shape their long-term learning path.
Making programming accessible & fun is crucial, but we must also ensure learners can gradually grow into full programming languages without unnecessary friction.

⚡ Robin Savenen Soderholm - vector to array: let the compiler turn heap into static storage

🎥 Video, 📄 slidedeck

Robin showed how a dynamic, heap-based design used on a Raspberry Pi could be migrated to a much more constrained Raspberry Pi Pico by leaning on constexpr and consteval.
By letting the compiler evaluate everything at compile time, a std::vector-like workflow effectively turns into static storage without runtime allocation, which meets the target plateform constraints.

In a nutshell, he presented a simple yet effective range-to-array function, inspired by Mikhail Svetkin’s talk “Harnessing constexpr: A Path to Safer C++”.

takes an std::invocable as parameter that return type meets the std::range requirement.
the result type is an std::array which std::ranges::range-value-t is the std::invoke-result-t of the invocable, and size is the range::size of the invoke-result-t.
copy elements generated by the invocable into the array

The implementation was something like:

template <std::invocable auto generator>
  requires std::ranges::range<std::invoke-result-t<decltype(generator)>>
consteval auto range-to-array() {
  using generator-result-type = std::invoke-result-t<decltype(generator)>;
  auto result = std::array<
      std::ranges::range-value-t<generator-result-type>,
      std::ranges::size(generator-result-type)
  >{};
  std::ranges::copy(
      generator(),
      std::ranges::begin(result)
  );
  return result;
}

⚡ Ganest Rengasamy - Meet Qt

🎥 Video, 📄 slidedeck

Rather than explaining what the Qt is, this was a refreshing reintroduction that showed how the framework has evolved to keep up with users and modern industry needs.
The talk highlighted Qt as a broad, end-to-end platform - well beyond just GUIs - covering cross-plateforms, embedded, desktop, mobile, backend integration, modern UI workflows (Figma), and even 3D assets.

Through an industrial vehicle use case, it showcased Qt as an end-to-end ecosystem: from backend services ingesting sensor data via MQTT to Qt-powered UIs designed in Figma and even rendering assets from Blender.

I haven’t really had the opportunity to use Qt since my school days (about 15 years ago), where it mostly meant - as far as I remember - GUIs and signal/slots. Back when I was freelancing, I tended to favor C# with WPF/XAML for GUI development, as the WYSIWYG experience felt more mature and better integrated to me at the time.

Seeing how much broader and more modern the ecosystem has become makes me genuinely curious to revisit Qt and explore what other powerful features it offers today to ease my developer needs.

Additional resources:

⚡ Hannah Lenk - Start teaching C++

🎥 Video, 📄 slidedeck

Hannah argued that much of the criticism aimed at C++ stems from outdated usage and a lack of teaching rather than from the language itself. Echoing several talks at the conference (Klaus Iglberger’s, Daniela Engert’s), she challenged the idea that C++ is inherently complex or unsafe, reminding us that simple does not mean familiar (see Pragmatic Simplicity - Actionable Guidelines To Tame Cpp Complexity - Vittorio Romeo - CppCon 2022) and that C++ remains one of the most widely used languages today (top 4 in the TIOBE index).

👉 From my perspective, C++ doesn’t have a language problem - it has a teaching problem.

If we want better C++ code and fewer misconceptions, we should start teaching comtemporain C++ to learners (beginners and professional developers),
instead of letting loud, uninformed voices dominate the narrative.
Teachers have a huge responsibility here: they should stop teaching C++98 or that so-called “C/C++”, and start teaching modern, simple, elegant and safe contemporain C++. C++ in 2026 feels like another language that C++98.

⚡ Jens Weller - binary trees

🎥 Video, 📄 slidedeck

Jens shared a thought process that started with a simple question: what does the web - including LLMs chatbots- teach us today about trees in C++ ?

Unsurprisingly, most examples still revolve around pointer-based binary trees, often written in a C-with-classes style using raw pointers, new/delete, and little consideration for modern design; which results in inconvenient, error-prone APIs. With developers increasingly turning to AI assistants instead of search engines, these patterns are now being amplified rather than challenged - ChatGPT, Grok, Gemini and similar LLMs tools largely reproduce what they find online, including outdated or incomplete practices.

From there, the talk pivoted toward data-oriented design.
Drawing inspiration from past keynotes Jens explored replacing pointers with indices stored in contiguous containers.

Using indices instead of raw pointers sidesteps incomplete-type issues, enables optional-like semantics, and improves cache locality.
Initial benchmarks (using quick-bench) comparing naive pointer-based trees to index-based implementations showed significant performance differences (about x2). “Not very suprising” - as Jens concluded - yet always worth reminding.

Rather than claiming a definitive/absolute solution, Jens framed this as an exploration. He raised follow-up questions about fairness in benchmarking, allocator effects, and how much of the observed gain comes from cache-friendly layouts versus allocation strategies.
The talk closed by positioning trees as a fertile playground for revisiting long-assumed design choices in the light of modern hardware and language capabilities.

My takeaway

What started as a casual survey of “binary trees on the internet” quickly turned into a lesson in intellectual hygiene.
By showing how most online examples and LLMs-generated answers still promote pointer-heavy, legacy-style implementations, Jens highlighted a deeper issue: many developers, especially juniors, increasingly treat AI tools and forums as a primary source of truth rather than as starting points for critical thinking.

From my perspective, this creates a feedback loop.

👉 LLMs largely reflect the datasets they were trained on, which means they tend to echo and amplify outdated practices. These patterns then get reused for learning, ramp-up, and ultimately copied verbatim into production code and pull requests.
The talk was a timely reminder that contemporain C++ requires discernment: tools can assist us, but responsibility for evaluating design choices - and updating our mental models - still firmly rests with us.

🗣️ James McNellis - Closing Keynote - A little introduction to control flow integrity

🎥 Video, 📄 slidedeck

Speaker: James McNellis, game engine security at ROBLOX About C++ being unsafe (laughs) like about half of the talks here this year.

James McNellis (Roblox) closed the conference with a deep yet tour of control-flow integrity (CFI), grounded in real-world exploitation techniques and modern defenses techs.

He started with a simple & common (and deliberately vulnerable) C example to illustrate how classic buffer overflows can lead to arbitrary code execution, especially when attackers can overwrite return addresses without triggering immediate crashes.

From there, the talk walked through the historical evolution of CFI hacks mitigations: stack canaries, non-executable memory, and address space layout randomization.
While effective, these defenses pushed attackers toward more sophisticated techniques such as return-to-libc attacks and return-oriented programming (ROP), where existing instructions - “gadgets” - are chained together to hijack execution without injecting new code.

This led into “CFI v2”: stronger guarantees even in the presence of arbitrary read/write vulnerabilities.
James explained how shadow stacks (notably Intel CET), ARMs pointer authentication (PAC), and newer mechanisms like ARM’s Guarded Control Stack (GCS), comparing their security properties and tradeoffs.

The second half of the talk addressed (no pune intended) - function pointers and virtual dispatch - covering Microsoft’s Control Flow Guard, Clang CFI, and hardware-assisted mechanisms like Intel’s Indirect Branch Tracking (IBT) and ARM’s Branch Target Identifier (BTI), all designed to restrict execution to valid control-flow targets.

My takeaway

This talk offered an excellent big-picture overview, but it also left me feeling pleasantly overwhelmed - packed with so many new concepts, mechanisms, tools and ideas as it clearly opened far more doors than it could fully cover/explore in one session.

It also made it very concrete how far the industry has gone to harden C++ execution without changing the language itself, and how much modern security is about the overall eco-system, as it relies on a tight collaboration between compilers, kernels, and hardware.
It also reminded me that as always in security, raising the bar for defenders doesn’t end the problem - it shifts it. Each new protection forces attackers to adapt and invent new techniques.

It reinforced the idea that crashes are often preferable to silent exploitation, and that layered defenses - even imperfect ones - dramatically raise the bar for attackers.
As a C++ developer, it also reminded me that understanding these mechanisms isn’t optional anymore: knowing how the code we write code interacts with CFI, indirect calls, and modern CPUs is part of writing responsible, resilient, and production-grade C++.

🤚 Allow me a disgression here

I would like to take this opportunity to share a personal opinion.

I was recently reminded how damaging loud but poorly informed voices can be. A popular French tech YouTube channel, Underscore_, released a video titled “major companies are abandoning C/C++ for Rust“.
Unfortunately, the arguments incriminating C++ relied almost entirely on C++98-style concepts, technics and examples: conflating C and C++, and ignoring decades of language evolution.
By portraying manual new/delete, fragile lifetimes, and unsafe concurrency as the norm, it presents a picture of C++ that simply no longer reflects contemporain practice.

👉 The problem is not disagreement or criticism per se, but the impact of large-scale vulgarization when it is built on shaky premises.
Influencers, federal agencies, and politicians content reaches far beyond engineers; it reaches managers, executives, and policy-influenced decision-makers. When those audiences internalize flawed narratives about C++, the resulting decisions can steer entire organizations - and sometimes the industry - based on fear and misconceptions rather than on facts.

💡 In a nutshell: should we stop coding in C++ in 2026 ?

Yes, if you want to dogmatically obey OCND, CISA and FBI, and follow trends in general with poor or no critical thinking.

If you’re pragmatic on the other end, then no: keep learning, teaching, coding, and creating safe, reliable products ! ❤️

Take for instance those two posts 2025 Will Be the Year of Rust - Why Big Tech Is Ditching C++ and Stop Coding In C and C++, Feds Say. It uses the same - often, fallacious - arguments, claiming:

Argument	My perspective
Rust is not a drop-in replacement for C++	Agree
C++ Build system (CMake) is a pain	Partially Agree. CMake is a de-facto build system for many languages.
C++ does not fit high-risk	Legacy C++ don’t. Contemporain does.
Poor memory safety	Ever heard of `{ type value; }` ? `std::unique-ptr` ? etc.
Tech-debt, maintaining cost endanger teams productivity	Not a language-specific thing
Lack of consistent formatting	`clang-format` and other tools are meant for that
Need to modernize with modern language features	Not a language-specific thing. No need, but one should.
Lack of safe concurrency primitives	STL’s concurrency support library, P2300 sender-receiver, etc.

Also:

C++ syntax is difficult, the error messages are vague, and even writing basic, safe programs can call for thorough understanding of memory management.
Modern developers find C++ antiquated, difficult, and hostile to newbies
Rust’s syntax is expressive

Let’s code

Disclaimer: I am not familiar with Rust yet, and my impressions are based on very limited exposure. As such, my observations may be incomplete or biased, just as some of the criticisms often directed at C++ are when they rely on outdated assumptions, as mentioned above. Please give me credit for mentioning and being honest about these limitations.
Also, comparing programming languages honestly is inherently difficult: each comes with its own strengths and trade-offs, which calls for nuance rather than absolute judgments.

That said, I Googled “production-ready Rust snippet”, found this one in the first results, and played with it on play.rust-lang.org here then godbolt.

👀 Show me the code !

Meeting Cpp 2025 Trip Report

2025-03-13T00:00:00+00:00

Redirecting... Click here if not redirected

Trip Report - Meeting Cpp 2024

2025-03-01T00:00:00+00:00

ℹ️ This post was originally published as a GitHub Gist.
Original comments and reactions remain available there.


Event	Meeting C++ conference, 2024
Author	Guillaume Dua
Date	11/14/2024 - 01/13/2025
My attendance sponsor	Fairmat
Revision	R2

Introduction
- Personnal thoughts about the conference
- Disclaimer
📅 11/14/2024
📅 11/15/2024
📅 11/16/2024
Conclusion

Introduction

Today marks the beginning of the 2024 edition of the MeetingCpp conference, running from November 14th to November 16th.
As a dedicated C++ enthusiast, I’m excited to seize this opportunity to explore emerging trends, deepen my knowledge, and gain insights from leading experts in the field.
Over the next three days, I look forward to expanding my perspectives and enhancing my understanding through a diverse lineup of talks and discussions.

This year, the MeetingCpp conference adopted a hybrid model, combining an onsite event in Berlin with remote participation through the Hubilo platform
(As opposed to the 2021 edition (see my trip report here) with was purely online because of the pandemic).

Notably, this year also marks the 10th anniversary of the conference taking place in Berlin (and the 13th overall anniversary), a significant milestone in bringing the C++ community together to meet, share and grow.

While I’m attending the conference remotely and will miss the in-person experience (socializing & drinks),
I’m grateful to Fairmat for sponsoring my participation at the conference this year.
Their support allows me to stay engaged with the latest in C++ and continue growing professionally.

With multiple tracks running simultaneously, it’s always a challenge - if not a dilema - to decide which talks to attend to.
The diverse lineup makes it difficult to choose, as each session offers unique insights and learning opportunities from interesting speakers. There’s a well-known French saying, often attributed to André Gide, that perfectly captures how I feel when planning my attendance at any conference: “Choisir, c’est renoncer.”.
It translates to “To choose is to give up” - on all the other options.

For the sake of completeness, the only issues occurred on day 2: a minor audio glitch on Track C at 2 PM and a brief streaming issue during Herb’s talk.

Personnal thoughts about the conference

I particularly enjoyed talks/keynotes from Titus Winters, Peter Muldoon, and Peter Sommerlad, as they resonated deeply with the practices I advocate for on daily basis.
From my perspective, much like Kate Gregory’s talks, this is a must-watch for everyone in the tech industry.
Their insights not only reinforced my beliefs but also added fresh perspectives and valuable details, enriching my understandings,
as I have been working on writing on a book about related topics since the first French COVID lockdown (A pragmatic approach of software development & project management: humans, tech-debt, decision-making, etc.).
It will influence how I approach team leadership and technical decision-making moving forward, to help build a more resilient, collaborative, and effective team culture while driving sustainable technical success.

The slides from most keynotes & talks of the conference are already available here,
while videos are already being uploaded on the MeetingCPP youtube channel.

Disclaimer

The last time I wrote a trip report, someone from the C++FrUG (C++ French User Group) playfully teased me,
saying: “This isn’t a report; but the entire trip!”.

He wasn’t wrong: this document is more of a detailed transcription of all the notes I took.
It helps me stay focused and retain information during talks, countering any tendencies toward distraction.

While this is primarily a resource for my future self to easily revisit and retrieve specific details,
I hope reading this will also be profitable to you - dear reader - in some way.

📅 11/14/2024

🗣️ Jens Weller: Welcome Message

The conference began with a warm welcome from Jens Weller, the founder and organizer of Meeting-C++.
In his address, Jens reflected on the journey of the conference, marking its 13th anniversary and the 10th taking place in Berlin, despite the new Berlin COVID variant.

🗣️ Titus Winters: Opening Keynote - Fear in tech

🎥 Video, 📄 slidedeck.

In a nuthshell:

“No code in this talk. The ones who are disappointed can leave now”

Software engineering == programming x time x people

Tech isnt just computers, it’s also peoples. With weaknesses, feelings.

Titus Winters delivered a thoughts-provoking keynote that focused not on technical details, but on the emotional and human aspects of software development.
At a C++ conference, this was a bold and refreshing approach, which made me think of some Kate Gregory’s talks.

By addressing fear, anxiety, and promoting psychological safety within teams,
Titus emphasized the importance of culture, communication, and trust in building sustainable software and effective teams.

Psychological safety over fear & anxiety

Fear of mistakes, judgment, and uncertainty can cripple team dynamics and innovation.
Effective tools, processes, and open communication are essential for reducing these anxieties.
The best teams foster an environment where members feel safe to admit mistakes, ask questions, and share feedback.
Trust and openness outweigh technical expertise alone.

Creating a psychologically safe environment

Encouraging open feedback, where team members can give and receive constructive input, and openly share mistakes without shame, as a cathartic but also information-sharing process.
Reducing fear and control-driven behaviors

Addressing hypes, fear of missing out (FOMO), and authoritarian power, leads to decisions that lack rational grounding.
Ensuring recognition of technical efforts

Bridging the perception gap between managers (~90% acknowledgment) and individual contributors (~25%) by making sure all work is visible and appreciated.

Culture is key

Organizational culture directly impacts 30% or more of a team’s - thus projects - success.
Writing down shared values and expectations, rather than relying on unspoken rules, promotes clarity and reduces fear.

Fostering a culture of gratitude

Actively promoting a “thanks culture” to acknowledge individual contributions and strengthen team cohesion.
Rely on truth and facts

Leverage tools to reduce uncertainty: Integrating and relying on tools as formal sources of truth to enhance predictability and confidence, and to reduce anxiety.
[A.N] “Facts over beliefs” is probably the phrase I say most often. Using more tools will help me avoid becoming an authority figure.

Learning and growth as a team

Continuous learning isn’t a luxury-it’s a necessity.
Senior team members should lead by fostering knowledge-sharing and ensuring others grow alongside them.

Supporting team growth

Providing clear guidance and mentorship to help team members ramp up effectively and feel supported.

Sustainability in software

Fear-driven decisions lead to unsustainable systems (e.g: tech-debt, etc.), where change becomes risky or impossible.
Sustainable projects must adapt to new challenges without fear of failure.

Prioritizing sustainable practices

Incorporating cleanup strategies and technical debt mitigation into regular workflows to maintain long-term project health.
Avoiding hype cycles and buzzwords

Maintaining a critical perspective to ensure decisions are based on practical utility rather than fleeting trends.
Reducing decision-making biases

Striving for fair, balanced, and inclusive decisions that minimize subjective biases.
Focusing on meaningful progress

Emphasizing that speed is not equivalent to velocity and prioritizing long-term impact over short-term gains.

Conclusion

This keynote was a powerful reminder of the human factor/elements in software engineering, beyond code.
As a lead developer, I recognize the importance of fostering psychological safety within my team, encouraging open communication, and focusing on sustainable practices.

🗣️ Andreas Weis: C++ Modules - Getting Started Today

🎥 Video, 📄 slidedeck.

Hello world example available here on compiler-explorer.
Ref. to Daniela Engert “The three secrets spices of C++ Modules - Visibility, Reachability, Linkage”

Andreas Weis provided an insightful deep dive into named modules,
offering a practical perspective on how they improve upon traditional header-based C++ code organization.

Includes limitations

Lack of structure

Includes can occur anywhere, even in the middle of a function body, which can lead to confusion.
Inter-dependency

Headers are not required to be self-contained, which can leads to unexpected situations where the orders matter somehow.
Redundant compilation

Each translation unit re-compiles included files, leading to inefficiency.

How modules address such issues

A module is a self-contained unit of code, explicitly declaring what it exports.
Modules separate visibility and reachability: non-exported entities are still visible within the module but inaccessible externally. However, modules are still vulnerable to ODR violations.

Challenges in adopting modules

Importance of using the latest tools, which have still plenty of bugs and inconsistent behaviors.

CMake: at least 3.28. And at least cmake >= 3.30 for import std.
Ninja 1.11
Clang 19
GCC 14, but consider using trunk

About mixing headers and modules

Mixing traditional headers with modules can lead to unexpected results.
Best practices include importing headers at the global fragment or using modularized legacy libraries (best world: no more include files).
Preprocessor directives cannot be exported, necessitating constexpr replacements.

Practical advice for getting started

Use modules as self-contained units and minimize reliance on header files.
Sticking with the .cpp extension for module files to maintain compatibility with build systems.
Modularize legacy libraries by exporting names explicitly or detaching specific elements from the module.
Always include the standard library before modularizing legacy code.

Conclusion

Modules represent a significant shift in how C++ codebases are structured, aiming to improve scalability, compile-time performance, and maintainability.
Although the tooling ecosystem is still evolving, these advancements promise a more efficient and less error-prone development experience.

🗣️ Philipp Dominik Schubert: The Notorious B.U.G. - The Most Popular Bugs and Code Smells in C and C++

📄 Slidedeck.

Philipp Dominik Schubert (Sonar) explored the most prevalent bugs and code smells in C and C++, leveraging Sonar’s tools and insights.
He offered practical advices on identifying and addressing common pitfalls, tooling, and modern C++ best-practices.

Bug hunting at Sonar

Sonar aims to detect issues in C and C++ code by applying a set of predefined rules that describe undesirable patterns or constructs. These rules are implemented through a combination of:
- AST matchers (Abstract Syntax Trees), which can be use like this in compiler-explorer.
  (In compiler-explorer: source editor panel > ‘+’ > compiler > compiler panel > ‘+’ > AST)
  - as a C++ DSL to query LLVM’s AST for patterns.
- Symbolic execution
  - Simulates execution to analyze control flow paths and states, performing a path-by-path analysis
    (as opposed to merge-first data-flow analysis)
  - Evaluates control flow, state constraints, and path conditions.
  - Unknown values
    - Are evaluated as symbols
    - branches and post-conditions used to contrain values
- Static analysis tools:
  - Identify error-prone paths using clang --analyze -Xclang -analyzer-checker=core, etc..

Challenges while detecting bugs

Exponential path explosion: 2^𝑁 paths for 𝑁 branches in the worst case.
Rice’s theorem (1951, his doctoral dissertation at Syracuse University): All non-trivial properties of programs are undecidable.
Balancing precision (false negatives) and recall (false positives) remains a significant hurdle.

See a live demonstration here on compiler-explorer.

Top 10 bugs and code smells in C++

Uninitialized variables

One should always initialize variables.

Turn compiler warnings on: -Wall -Werror,
even if it might not help in some cases:

void magic_init(int &)
int func(){
  int a;
  magic_init(a);
  return a;
}

Use default initialization when you can
Be careful with default constructors, even with PODs members

Use IILE for non-trivial initializations

int a{};
int b = [&]{
  if (cond()) return 42;
  return 9001;
}();

auto [x, y] = [&]{
  if (p) return std::make_tuple(1, 0);
  return std::make_tuple(0, 1);
}

Buffer overflows
- Avoid C-style arrays. Prefer std::array, std::vector, std::string, or std::inplace_vector.
- Use range-based for-loops and , and
  - For indexes, use std::views::enumerate: const auto [index, value]: std::views::enumerate(range_value)
- Mitigate risks inherent to legacy code by using tools: sanitizers, FORTIFY_SOURCE, stack canaries, ASLR (address space layout randomization), and fuzzing.
Null pointer dereferences
- Prefer references over pointers.
- Always check for nullptr before dereferencing.
- Example: Tony Hoare’s billion-dollar mistake (null refs in ALGOL)
Unreachable code
- Indicates logical flaws and confuses readers.
- Often hides untested and unmaintained chunks of code.
- Example: Apple’s infamous goto fail; bug.
Resource leaks
- Avoid manual memory management: prefer smart pointers and containers.
- Use RAII idiom.
- Use semantic: std::move to transfert ownership/resources, const-qualified types for read-only access.
Identical binary operator expressions
- Often a sign of copy-pasted errors.
- logical expressions can be tricky: simplify it, and use tools when it’s too complicated.
Incorrect return values
- Ensure functions return - appropriate - values on all paths.
- Add compiler warnings (-Wall, -Wreturn-type, and consider using-Werror)
- Use attributes like [[noreturn]], [[nodiscard]].
Identical branches
- Another indicator of logical flaws or copy-paste mistakes.
Destructors throwing exceptions
- Destructors are implicitly noexcept since C++11.
  Throwing exceptions from destructors thus causes abrupt, unclean, implementation-defined termination, effectively calling std::terminate.
- Be extra careful with containers of objects
Loops with at most one iteration
- Indicates serious logical flaws.
- Replace with if-statement for clarity.

Questioning root causes

Legacy code: Many bugs stem from outdated practices and lack of modern C++ features.
Teaching C++ effectively: Are educators failing to teach best practices ?
Default behavior: Should C++ provide safer defaults, like mandatory zero-initialization ?

How to improve code quality ?

Adopt modern C++ practices: Use safer standard library types,
effectively avoiding raw pointers and manual memory management.
Use static and runtime analysis and other available tools:
- Turn compilers warning on (-Wall -Werror) and use static analyzers for blind spots.
- Employ dynamic analysis tools like sanitizers (undefined behavior, address, memory, thread).
- Test and validate your code by running your test suites with tools like valgrind to catch runtime errors and race conditions.
Express your intent clearly: Leverage attributes like [[nodiscard]], [[noreturn]], and [[maybe_unused]]

As a conclusion, Philipp’s insights highlighted that while static analysis can’t solve every problems, combining modern C++ practices with effective tools can eliminate many common pitfalls.

🗣️ Goran Aranđelović: Introduction to Sender/Receiver framework

Goran Aranđelović is a developer in the adtech industry, and founder of the C++ Serbia user group.

In his talk, Goran underlined the differences between concepts often confused with each others: multithreading, concurrency and parallelism.

Concurrency: multiple computations at the same time. Processing tasks on 1 core result in a concurrent but not parallel execution.
Parallelism: multiple calculations/processes running simultaneously. Processing taks on N cores can be concurrent and parallel.
Compared to serial execution, concurrency requires stronger scheduling guarantees, and while parallelism requires weaker ones.
In a nuthshell: concurrency encompass parallelism, while multithreading is a one of the way to achieve concurrency

Why do we need such a new framework ?

C++11 introduced std::thread, atomic, memory_order, (recursive)mutex, future, promise, async, etc., but …
- That was a while ago: we’d better clean up such primitives in our codebase
- We need to focus on expressing intents (what), not low-level implementation details (how)

What are the current proposals ?

What is the current available implementation ?

Nvidia’s stdexec

Introducing senders & receivers, as described in P2300

Key ideas:

A self-contained design for managing asynchronous execution on generic execution resources.
An idiomatic way of expressing async work in C++.
Provides unified, high level abstractions, effectively enabling async API composition

Core concepts:

Schedulers: Lightweight handle that represent strategies for scheduling work on an execution resources (e.g., CPU, GPU).
Senders: Describe some work to be done, as a monad.
- A sender can be choosed at runtime
Receivers: Multiple channels callbacks:
- Value (results).
- Error (exceptions).
- Stopped (cancellations).

Minimal control flow API:

stdexec::on: Specify where the work is executed.
stdexec::just: Lift a concret value into a sender.
Equivalent to pure in Haskell.
stdexec::then: Continuation: chain computations with transformed value from previous sender. Equivalent to fmap in Haskell.
stdexec::let_value(F): Dynamically choose a sender at runtime.
(F is an runtime invocable which returns a sender)
stdexec::sync_wait: Block and wait for the result.

Advantages of senders & receivers when compared with existing models

See a complete example here on compiler-explorer.

straight-forward
Combines async tasks without the overhead of allocations, synchronization, or type erasure.
Composition and blocking (sync_wait) are standard, generic algorithms.
Replace/unifies heterogeneous/disparate async APIs, enabling greater interoperability.

Example

auto s1 = then(just(42), [](int i){ return i + 1; });
auto op1 = stdexec::connect(s1, print_receiver{});
stdexec::start(op1)

Senders & Receivers are not a replacement for coroutines

They complement each other:

All awaitables are senders.
Many senders can trivially be made awaitable.

Key takeaways

The sender/receiver framework simplifies and standardizes asynchronous programming in C++.
It encourages writing clean, composable, and efficient code for managing async workflows.

🗣️ Klaus Iglberger: There is no Silver Bullet

🎥 Video.

Klaus Iglberger delivered an insightful talk that explored the challenges and trade-offs in software design,
focusing on object-oriented programming (OOP) inheritance and its modern alternatives (std::variant, type-erasure, etc.) to implement homgeneous abstractions. Highly entertaining and dynamic talk with a great sense humor, a noticeable hint of irony, and some references to Lord of the Rings ! And like always, he used the classic shape design example, to illustrate how working with massive, legacy codebases can be challenging.

[A.N] Personnal fun-facts:

This talk has the same name as the very first software-design lecture I attended to, when studying in Seoul (South Korea), years ago.

I wrote a few (sometime, clumsy ?) articles myself on related topics:

(2021) Concept-based polymorphism in modern C++

(2018) C++ polymorphism without vtables

Traditional OOP/`vtable` approach

Classic design patterns: Klaus started with a classic OOP solution, leveraging virtual functions and design patterns like strategy. Example: A Shape interface with derived classes (Circle, Square) delegating drawing responsibilities to an injected draw strategy design pattern.
Architectural principle: This separation maintained a clean boundary between
- high-level (stable, low dependencies) shape logic and
- low-level (volatile/maleable, high dependencies) drawing implementation (e.g., OpenGL).
- emphasizing the separation of concerns (SoC) principle.

Critique of classic OOP

Klaus highlighted its dated nature: it mirrors 1996 GoF (Gang of Four) style practices and doesn’t align with truly modern, progressive C++.
Referenced prominent criticisms of OOP, such as:
- Sean Parents - Inheritance is the base class of evil
  ([A.N]: the original upload on channel9.msdn.com does not work anymore)
- Phil Nash - OO considered harmful
- Jon Kalb
  - Why don’t the cool kids like OOP ?
  - Back to Basics: Object-Oriented Programming
- Jonathan gopel: using modern C++ to eliminate virtual functions
Even if as experts we care about our level of C++, we’re living in a bubble: such an approach remains used in a roughly estimated 90% of existing C++ codebases.

Is `std::variant` (a modern) alternative ?

Benefits:

Less and simplier code to write.
Avoids inheritance, pointers, and dynamic allocation - thus, increases performances.
Automatic, elegant lifetimes.
Potentially improves performance.
Functional programming style

Challenges:

Architecturally speaking, using std::variant for runtime polymorphism is a total disaster/failure,
as it violates the open-close (OC, the “O” of SOLID) principle.
He emphasized that std::variant isn’t a silver bullet. It excels in scenarios with a fixed set of types and open operations but struggles with extensibility.

Templates to the rescue ?

Adding template-type-parameters (TTP) to function helps removing some tight-couplings from the library to the userland code
But it is slow to compile, as the compiler needs to instanciate each template function instance.

What about type-erasure ?

Achieving value-based OOP using type-erasure ([A.N]: which I call “opaque type: inheritance as an implementation detail”) might be a middle-ground here.

Changes/extensions works as expected
The architectural boundaries are adhered to
Fewer pointers, fewer virtual functions (only one indirection)
Less inheritance, less manual memory management
Better performance
Small Buffer/Base Optimization (SBO) using std::aligned_storage avoids dynamic allocation (which works fine for small objects).

Conclusion

There is no universal, unique solution that one can use everytime, everywhere. There is always a trade-off, and one technic might suite a specific situation better than the other.

std::variant is not a replacement to virtual function: both are dynamic polymorphism technics, but differs.

OOP and std::variant are the two side of the same coin.

/	`std::variant`	OOP	type-erasure
programming style	functional	object-oriented	object-oriented
set of types	fixed	open	open
sets of operations	open	closed	closed
recommanded architecture level	low	?	higher

Architectural design matters
- Features and language details are secondary to the overall design.
- Successful projects rely on well-thought-out architecture, not individual features.
Document your decisions
- Create an Architectural Decision Record (ADR) to document your decision-making process (e.g, pros & cons, trade-offs, final call, etc.).
- Consider each approach pros & cons. Effective design requires balancing these based on current needs,
  thinking first about the architectural properties of the solution: what do you want to achieve ?

Klaus advocated moving away from the term “modern C++” to “progressive C++,” reflecting its constant evolution.

He then closed with a reminder: “There is no silver bullet”:

The fun - and difficulty - of software design lies in finding the right trade-offs for each unique situation.
The talk emphasized the importance of a pragmatic architectural thinking over dogmatically chasing the latest language features, leaving the audience with valuable perspectives on crafting robust, maintainable C++ code.

📅 11/15/2024

🗣️ Jens Weller: Good Morning Meeting C++

Jens started the second day of Meeting C++ 2024 with a warm welcome and shared updates and reflections on organizing the conference:

Respect for speakers: he emphasized that every speaker deserves an engaged audience, reminding attendees of the effort behind each talk.
Conference recordings: All sessions will be available for viewing after the conference (first on Hubilo for attendees only, then on the MeetingCpp Youtube channel).
- [A.N] I’ll update this trip report when there are available.
Behind-the-Scenes: Jens touched on the complexities of organizing a large event, particularly handling last-minute changes such as speakers unable to attend.

A journey to produce Meeting C++ tshirts

Jens humorously described the challenges (understand, pain) of designing conference T-shirts with C++ code printed on them:

Design hurdles:
- PNG vs. SVG for graphics.
- Issues with colors and floating-point precision during the process.
Tools explored:
- Learned to use build tools like Conan 2.0 and Jason Turner’s CMake starter template (presentation available here on Youtube) with CPM.

🗣️ Hana Dusíková: Center Keynote - my favorite data structures

🎥 Video.

Hana Dusíková delivered a delightful - yet, sometimes mind-bending - keynote, exploring the intricacies of constexpr programming and containers,
highlighting her favorite data structure - but also experience hacking the Clang compiler to address some personal frustrations and deeper her understanding of how things work under the hood.

About the speaker

Hana works at Woven by Toyota - one of the conference sponsor - and is the chair of the reflection and compile-time study group.
Her last talks are about her projects: CTRE, co_curl, cthash (sha-2, sha-3).

[A.N] I loved so much her talk about CTRE at the CPPP-2019, I strongly encourage you to watch it if you haven’t already.

Exploring symbolic execution in C++

LLVM Clang’s ExprConstant.cpp: The core of symbolic execution in C++, essentially a CPU arch independent interpreter written in one file.
APValue: Represents C++ values during constant evaluation,
- encompassing various “stuffs”
  - can be nothing
  - types (int, float, array, unions, struct, pointers).
  - lvalues (references or pointers)
- Detailed description on how arrays, unions, and pointers are represented and their constraints.
- Highlighted how pointer provenance and undefined behavior arise from the lack of symbol ordering in pointers,
  as well as how rvalue are marked as temporary as such a value is about to be destroyed soon, thus one can steal from it, and expressing lifetime concerns in general.
Enhanced safety: the interpreter helps detect violations of the C++ abstract machine, making constexpr code safe and deterministic.

`constexpr` containers in the standard library

Hana analyzed which STL containers are currently constexpr and why:

Supported: vector, array, string, optional.
Not supported (yet): deque, map, set, unordered_map, unordered_set, list, flat_set, flat_map (even if it’s a new feature).

Challenges like exception safety, memory allocation, and reallocation explain these limitations.
Hana calls for more constexpr-compatible containers to leverage C++’s evolving capabilities.

About `constexpr` limitations

The speaker then outlined the historical progress of constexpr features/milestones, and their limitations:

C++14 introduced control flow and variables.
C++17 added lambda calling.
C++20 brought try/catch, trivial initialization, changing active member of a union, and virtual functions.

And what are our future needs, which are mostly covered by the following proposals - that she mostly authored:

P3068: allowing exceptions throwing in constant-evaluation (Hana)
P3378: constexpr exception types (Hana)
P3309: constexpr atimic and atomic_ref (Hana)
P3037: constexpr std::shared_ptr (Paul Keir)
P3125: constexpr pointer tagging (Hana)
P3074: trivial unions (Barry Revzin)
P3372: constexpr containers and adapters (Hana)
P3295: freestanding constexpr containers and constexpr exception types (Ben Craig)
P3367: constexpr coroutines (Hana)
P3391: constexpr std::format (Barry Revzin)
P3449: constexpr std::generator (Hana)
P1974: non-transient constexpr allocation using propconst (Jeff Snyder)

Her favorite data-structure: Hash array mapped trie (HAMT)

A hash array mapped trie (HAMT) is an implementation of an associative array that combines the characteristics of a hash table and an array mapped trie.
It is a refined version of the more general notion of a hash tree. - wikipedia

Usage scenario:

Ideal for snapshot systems due to its structure and efficiency.

Advantages:

O(1) for insert, search, delete.
Linear growth with no rehashing.
Lock-free.
Persistent, compatible with flat storage (using offsets instead of pointers).

Closing thoughts

This keynote - like her other ones - showcased Hana’s deep expertise in constexpr programming and her passion for pushing the boundaries of C++.
Her vision for the future of constexpr includes extending support for all containers, coroutines, and generally speaking bringing most of the C++ runtime world into the compile-time realm; effectively refining C++ as a language for both runtime and compile-time efficiency with no safety compromise.

[A.N] My question: Do you use a specific/dedicated test framework to create unit test for constant-evaluated code, or do you only use some static_asserts ?

Answer:

test suite of LLVM code for such a code

static_assert

Catch2

Issue: measuring code coverage in constexpr code is a hassle

🗣️ Olivia Quinet: Applied modern c++ : beyond type-erasure and visitor design patterns

📄 Slidedeck.

Olivia Quinet’s talk tackled heavily used C++ polymorphism design techniques,
with a focus on type-erasure and the visitor design pattern, questionning such designs scalability and limitations.
Despite being visibly nervous, she successfully presented her design, which echoed with Klaus Iglberger’s talk from the previous day “There is no Silver Bullet”.

Key ideas

What is a software ?

Software processes inputs to produce outputs, relying on models for transformations and error handling.
Building software is analogous to building a factory, with frequent updates and increasing complexity management.

Challenges for flexible architectures: modern software grows in complexity due to:

Increasing number of object types.
Expanding processing pipelines.
Greater number of transformations and actions.

Orthogonality in C++: as the source code is compiled, the amount of types and operations are finite.

More types -> Shall use type-erasure for flexibility.
More operations -> Shall use the visitor pattern.

Revisiting design patterns

Visitor pattern with std::variant + std::visit

Visitors allow operations on the current alternative (of a compile-time set of types) value being held by a given std::variant
Type-deduced visitor: lambda with auto arg.
Type-matching visitor: if constexpr.
Overloaded visitor: using function overloads for type matching.

Pros and cons of the visitor pattern:

Pros: Easy to add new operations to a pipeline.
Cons: Adding a new type requires updating the variant and all related visitors.

Type-erasure pattern:

Provides a value-semantic interface to work with unrelated types (an open set of types).
Using technics such as Pimpl, concepts, and models.
Ideal for adding new types without modifying the existing pipeline.

Combining type-erasure and visitor patterns: Olivia’s hybrid approach

Prerequisites:

Pipeline-based processing.
Known types at compile time for a given pipeline version.
No dynamic library loading.

Requirements:

Non-intrusive implementation.
Value semantics.
Type-erasure for type extensibility, with a common interface
Visitor pattern for adding functionalities.

A complete demonstration is available here on github.com/olivia76/cpp-te. This approach allows for flexibility in both adding types and operations, while retaining most of the advantages of both patterns.

Lessons learned

After performing a live demo and presenting some benchmarks (comparing several ways to implement type-erasure, using either function ptrs, std::function, and/or vtables), Olivia shared her insights:

Promote iterative process: “Think, try, test, repeat.”
Stay updated with evolving C++ standards and features.
There is no universal solution (silver bullet), as trade-offs are inevitable.

🗣️ Kate Gregory: The Aging Programmer

📄 Slidedeck

Kate Gregory delivered an insightful and deeply personal talk on the challenges and opportunities of aging as a programmer.
With practical advice grounded in her own experiences, research, and surveys, she encouraged attendees to think long-term about their careers, health, and happiness.

[A.N] Having been profoundly influenced by Kate Gregory’s previous talks - each questioning & reshaping how I approach my work, and my relationship with code and design in general -,
I was particularly eager to attend this one. It didn’t disappoint: I loved it.

The talk resonated deeply, aligning with personal reflections and offering invaluable insights for tackling the uncertainty - thus, anxiety - of aging (after all, no one gets to grow old twice).
As always, I was struck by her caring, positive, and hopeful ton and outlook.
Her words didn’t just stay with me; I found myself immediately sharing my notes with friends & family, eager to spread the wisdom she offered.

In a nutshell: Embracing the aging process

Aging is inevitable: if you’re not aging, then you’re already dead.
Not everyone gets to be an “old programmer” due to life changes, health, or retirement.
The goal is to enjoy programming into your later years, which requires planning and efforts.

About health: body and mind

Physical health challenges and tips to age better

Eyesight: Regular checkups are essential.
Tools like glasses for different tasks can boost productivity and reduce strain.
Exercise: Strength, stamina, and flexibility exercises improve overall health, reduce pain, and enhance cognition.
Hearing: Protect your hearing now; damage is irreversible.
Hearing loss can isolate you socially and professionally.
Wrists and joints: Ergonomic setups and exercises can mitigate strain.
Night braces or posture adjustments may help.
Injuries and illness: Preventative care, vaccines, and addressing issues promptly are vital to aging well.

Mental and emotional health

Short-term memory: Use habits, routines, checklists, and tools to stay organized and focused.
Avoid multitasking.
Learning new skills: With experience, you’ve already mastered learning-embrace change and connect new concepts to what you know.
Mood and cynicism: Aging doesn’t have to mean grumpiness.
[A.N] After the talk, someone in the audience advised “Don’t let the old in”: One does not have to play that role, it’s not a fatality.
Staying positive requires planning, preparation, and flexibility.

Addressing challenges in the Workplace

Age discrimination: Common in tech, especially for women.
Combat biases, but recognize some environments may not fit.
Physical limitations: Workplace setups often create unnecessary barriers (e.g., stairs, lighting).
Evaluate whether the issue lies with your body or the environment.
Adapting work: Adjusting expectations or shifting roles can keep you engaged.
Retirement or industry changes: Choosing to retire or switch fields is valid and not inherently negative.

Building a long, happy career and life

Practical steps for longevity

Exercise: Supports body, brain, and emotional well-being.
Health maintenance: Regular checkups, a balanced diet, and avoiding harmful habits (e.g., drinking, smoking) are critical.
Finances: Save and invest for long-term stability.

Social connections

Losses are inevitables, but building new friendships through hobbies, work, and community can sustain you emotionally.
Younger friends keep your perspective fresh as you age.

Finding purpose

Hobbies, mentorship, or other activities can provide meaning beyond professional work.

The upsides of aging

Freedom: Aging reduces fear and dependence on others’ opinions.
Perspective: Experience brings confidence and the ability to give up things that no longer serve you.
Resources: Time and money often increase with age, enabling new adventures and priorities.

Kate’s core advices

Take care of yourself: Health, exercise, and nutrition are investments in your future.
Build relationships: Maintain and create friendships throughout your life.
Stay curious: Try new things, embrace changes, and find purpose.

Aging is not a barrier to a fulfilling life or career: it’s an opportunity to grow, adapt, and thrive.
As Kate emphasized: “It’s never too soon, and it’s never too late.”.

🗣️ Peter Muldoon: Software Engineering Completeness : Knowing when you are Done and Why it matters ?

🎥 Video.

“Achieving sustainability should be the main goal of every engineer,
as it means reaching a level of mastery where you can confidently guide decisions and advise your boss - though many may feel unprepared for such a responsibility.”
“Are we done yet ? Probably not ! Why ?”

Context: Inspirations & motivations behind this talk

Stemmed from discussions about the cost of software ownership
Software engineering is not just about writing code but maintaining it over time.
Many struggle with defining when something is done (DoD) or setting realistic completion dates.

About the definition of done (DoD)

What does “Done” mean ? Peter opposed two definitions:

From the dictionary definition: Work until task fulfillment.
From an engineering perspective: Formal declaration that a product meets defined quality standards.

Why shall we define and share a DoD ?

Establishes a shared understanding and unified language for delivering software.
Ensures new employees have access to essential knowledge and expectations.
Encourages acknowledgment of shared responsibilities across teams.

Software value: customer vs. engineering perspectives

Customer-focused software value actualized value when software is:

Available: Accessible to users.
Usable: Practical and user-friendly.
Reliable: Stable and dependable.

Engineering-focused software value includes future-looking value:

Configurable: Easy to adjust.
Flexible: Handles changes gracefully.
Maintainable: Quick issue resolution.
Evolvable: Can adapt to market and requirements changes.

Delivering changes to production

Types of improvements:

New features.
Bug fixes.
Feature flag updates.
Configuration changes.
Technical debt mitigation/reduction (e.g., refactoring, deprecations, etc.).
Infrastructure/environment upgrades (e.g., compiler updates, architecture support, etc.).

Risks introduced:

Broken or missing functionality.
Performance and security issues.
System unreliability.

About acceptance criterias (AC)

What are acceptance criteria ? Conditions a product must meet to be accepted by the user.

Characteristics of good ACs:

Clarity: Easy to understand.
Conciseness: No unnecessary details.
Testability: Results visible to the customer.
Observability: Outcomes measurable.

How to write ACs:

Author: Product owner or team member.
Process: Shared with the team and validated by customer/proxy.
Can follow the Gherkin style: given (context), when (action), then (result).

Problem domains & complexity

Complexity levels influence predictability and risk, thus forecasting:

Unknown: Minimal information, low confidence.
Simple: Well-understood, low risk.
Complicated: Multiple moving parts, requires analysis.
Complex: Many unknowns, dependencies, and risks.

The Cynefin framework is helpful in categorizing problems domains.

Time, scope, and estimates

Why engineers struggle with time estimates:

Misplaced optimism.
Lack of consideration for start dates alongside deadlines.

How to produce better estimates ?

Break tasks into smaller pieces.
Clearly define requirements and scope.
Acknowledge uncertainty and plan for delays.
Communicate updated timelines as new information arises.

Are we done yet ? The software-engineering completeness pyramid

The software-engineering completeness pyramid is like the Maslow pyramid of needs, for software development.

Development done ?

Changes verified and meet all ACs.
All tests passed (unit, non-regression, integration, etc.).
Code reviewed, committed, and ready for release.

Deployment done ?

Code deployed everywhere (not just one site, etc.).
Dependencies tracked and resolved.

Feature flags done ?

Fully enabled and utilized in production.
Removed once changes are stable.

Code health: refactoring, decommissioning, and technical debt

Technical debt:

Accumulated shortcuts in the codebase.
Can be intentional: strategic trade-offs with planned mitigation.
- [A.N] So-called quick-wins requires mitigation planning
Can be unintentional: non-strategic, no plan to resolve.

Refactoring:

Improves internal structure without altering behavior.
Challenges: Time constraints, poor reviews, and lack of planning/forecasting.
Not refactoring leads to system rewrites over time.

Decommissioning:

Process of retiring outdated code.
Identifies unused or redundant functionality.

How to prevent new technical debt introduction ?

Proper timelines, code & design reviews (with appropriate guidelines), coding standards, and documentation.
Track (but try not to add too much items to the backlog) and address debt regularly (e.g quarterly sprints, etc.).
Trainings, best-practices, and knowledge sharing.

Testing and sustainability

Is the testing done ?

Coverage across all levels: unit, integration, system, non-regression, etc.
Lessons from past failures applied as new tests.
Use test automation, triggering alerts (slack, emails, etc.) in case of failure.

Sustainability goals:

Decreasing technical debt.
Structurally maintainable codebase.
Satisfied developers, clients, and stakeholders.

Conclusion

Codebase health/substainability differs from new feature implementations and bug-fixes.

When are you done ?

The feature or bug fix meets all acceptance criterias
- Possibly injects intentional tech-debt to meet the deadline - which must be addressed immediately after.
It is deployed everywhere in production.
Code is maintainable and team-supported.
The tech-debt is decreasing - not increasing
Users and the business are happy.

🗣️ Nico Heidtke: Growing Pains - Lessons from Seeing Codebases Mature

📄Slidedeck.

“Give me six hours to chop down a tree, and I will spend the first four sharpening the axe” - Abraham Lincoln.

Nico Heidtke shared insights into the challenges of growing and maintaining C++ codebases, focusing on lessons learned from real-world experiences.
He emphasized the need to balance technical excellence with team alignment, knowledge transfer, and sustainable practices in general.

As teams expand, new hurdles arise: efficiently onboarding new contributors, mitigating knowledge loss when members depart, and ensuring sustained team alignment requires well-defined processes.

Codebase layout & conventions

Early decisions on structure and standards can have long-lasting impacts.
Clear organization and consistent conventions improve - or help maintain - productivity and onboarding but require ongoing attention.

Knowledge transfer & documentation

Reliance on verbal communication leads to information loss over time.
Good documentation - both code-specific and design/architectural - is essential, and updates must be aligned with code changes.

Development tools & automation

Tools like linters, formatters, and CI/CD pipelines help scale processes and maintain quality.
Early integration of such tools avoids technical debt, and “warning flood/fatigue” must be managed immediatly.

Managing dependencies & abstractions

Portability matters, more than you might think. Favor standard library abstractions rather than plateform-specific code.
When platform-specific logic is unavoidable, encapsulate it within dedicated libraries and ensure your CI/CD pipeline tests across all targeted platform and compiler combinations (e.g using GH-action matrixes). These practices help prevent significant future overhead, keeping third-party dependencies and platform-specific code maintainable in the long term.

Interoperability & localization

Interfacing with other languages and systems is almost inevitable - C remains the go-to for cross-language compatibility.
For globalization, adhering to standards like UTF-8 - for text - and UTC - for time - minimizes future rework.

Conclusion

Overall, the talk highlighted the importance of proactive planning, clear communication, and leveraging tools to navigate the growing pains of maturing codebases.

🗣️ Herb Sutter: Peering forward - C++’s next decade

🎥 Video, slidedeck.

Herb Sutter made a grand entrance, arriving just in time to kick off his keynote:
“Does everybody have a beer ? Do I have until midnight ?”
He set the stage for an exciting journey into the future of C++, comparing C++26/29 to a treasure chest slowly being filled with gems,
each feature being a valuable addition to the language’s evolution.

Herb Sutter presented an insightful and visionary outlook on C++’s evolution, focusing on three key pillars: reflection, safety, and simplicity.
These advances, already shaping C++26 and beyond, aim to revolutionize the way we write and maintain code, while ensuring that C++ continues to meet evolving industry demands.

Reflection

Reflection is an important metaprogramming milestone, allowing programs to - at compile-time - inspect and modify their own structures, thus with zero runtime overhead (to use such informations at runtime, one have to store them).
By making the structure of types directly usable as inputs, it simplifies tasks like options parsing and code generation. Reflection and compile-time programming mark a natural progression in C++’s journey, offering transformative potential for future development patterns.

See the P3096 proposal,
and this live example here on compiler-explorer, which uses the EDG front-end.

Safety

See “C++ safety, in context”, aka the “cold” war, in progress,
also available on tinyurl.com/sutter-safety.

New tools aim to address type, bounds, initialization, and lifetime safety-critical sources of vulnerabilities in C++.
What is nowadays “watch out” features (performance & control by default, safety always available),
will become “opt-out” ones (safety by default, performance & control always available).

Features like erroneous behavior, introduced in C++26, provide defined outcomes for mistakes,
reducing risks like uninitialized values without compromising performance or control.

Erroneous behaviors semantically differ from undefined behaviors: “well-defined as being wrong” vs. “anything can happend”.
These changes improve the safety of existing codebases simply by recompiling, bridging a gap historically filled by manual effort or third-party tools.

Simplicity, through generalization

C++ continues to simplify by enabling developers to directly express intent rather than relying on verbose annotations,
effectively focusing on the “what”, not “how”.

Features such as range-for loops or reflection align with such a philosophy, reducing complexity while maintaining power.
Simplification is achieved not by subtraction but through carefully chosen additions (features) that abstract away common patterns and pitfalls.

Looking ahead

The combination of increased compile-time capabilities and enhanced safety mechanisms promises to make C++ more approachable and robust.
Challenges remain, particularly in ensuring these features are widely adoptable and scalable for existing codebases.
Nonetheless, Herb envisions a future where developers write safer, simpler, and more expressive code, setting the stage for C++ to remain a cornerstone of systems programming for the decade ahead.

📅 11/16/2024

🗣️ Rainer Grimm: An overview on the C++26 highlights

📄 Slidedeck.

C++26 introduces a wealth of features which - from my perspective - meet industry demands, emphazing simplicity, safety, and performances.
These advancements are set to make the language more intuitive and robust, catering to both modern industry challenges and developer expectations. In a nutshell: less code, more value.

Reflection

P2996r5 as a MVP
Introduces the reflection operator ^
Splicer [:…:], and metafunctions (in std::meta namespace), and std::meta::info.

Contracts

Preconditions and postconditions - post(condition)/pre(condition) - as contextual function keywords.
Assertions/invariants contract_assert(condition) as keyword.
Live example available here on compiler-explorer.

Placeholders

Highlights unused variables using _
auto [_, a, _] = func();

Static assertions

static_assert supports user-defined type properties
static_assert(sizeof(S) == 1, std::format("unexpected size: {}", sizeof(S)));

Templates parameter pack indexing

Provides direct access to elements of a pack
T...[0]; values...[0];

`delete(reason)`

clearer function restrictions

void func(double){}
template <typename T> void func(T) = delete("only for double");

String-likes improvements

Compare function results to bool (from_char, to_char)
Improves interfacing (std::stringstream with std::string_view), concatenations (std::strings and std::string_views), and arythmetic overloads (std::to_string and std::format).

`std::inplace_vector`

Drop-in replacement for std::vector in memory-constrained contexts, dynamically resizable with compile-time fixed capacity.
See P0843R8

`std::format`

Expanded support for pointers and newlines.

New views std::ranges::generate_random and std::ranges::concat_view.

More `constexpr` support

, : std::stable_sort, std::stable_partition, std::inplace_merge
: free-function algebra interface based on BLAS

`std::submdspan`

Improvement of C++23’s std::mdspan
See P2630r4

Debugging support

std::breakpoint
std::is_debugger_present
std::breakpoint_if_debugging: if (std::is_debugger_present) std::breakpoint();.

`std::execution` (sender/receiver)

See P2300R10, and the reference implementation NVIDIA/stdexec.
Execution resources represent locations like GPUs or threadpools.
Schedulers represent the execution resource, defined with execution::schedule
Senders describe tasks; receivers handle workflow termination.
Sender types:
- Factories : execution::just, execution::just_error.
- Consumers : this_thread::sync_wait.
- Adaptors : execution::then, execution::when_all.
Receivers support three channels: value, error, stopped.

🗣️ Frances Buontempo: An introduction to swarm intelligence algos

📄 Slidedeck.

Frances Buontempo presented an engaging introduction to swarm intelligence algorithms, blending theoretical insights with practical programming demonstrations. Her talk emphasized the simplicity and creativity behind implementing such algorithms, encouraging attendees to write code for fun and problem-solving.

As someone unfamiliar with such a topic, I found her presentation intellectually stimulating.
The first slide title, “Swarm to get your way out of a paper bag” made me remember her earlier publications in ACCU's Overload journal “How to Diffuse Your Way Out of a Paper Bag”, 2016 and on ResearchGate about Brownian motion, which inspired me years ago to begin experimenting with naive particle simulations and the SFML as a playground.

What is swarm intelligence ?

Swarm intelligence refers to the “emergent collective intelligence of a group of simple agents”.
Inspired by nature - such as flocking birds or foraging ants -, these metaheuristics are designed to tackle intractable optimization problems.

They operate using two fundamental modes:

Exploration: discovering new solutions (unexplored area of the feasble region)
Exploitation: refining existing solutions (search of the neighborhood of a promising region)

Metaheuristic search algorithms are broadly categorized into :

Trajectory-based approaches (e.g., simulated annealing).
Population-based approaches, which are also subcategorized into
- evolutionary computation
- swarm intelligence (e.g., particle swarm optimization & variants)

[A.N] see also AI Search Algorithms for Smart Mobility, 2021, by Alaa Khamis and Yinan Wang

Particle Swarm Optimization (PSO)

Agents (particles) have positions and velocities in a given space.
They adjust their movement based on a formula involving constants.

Ant Colony Optimization (ACO)

Ants traverse grids or graphs, guided by virtual pheromones (numeric values).

Abstract Bee Colony (ABC)

Bees assume distinct roles:

Scouts: exploring new areas for resources, remember the best locations.
Workers: gathering food and investigate nearby.
Inactive: waiting at home to be recruited.

Communication via a “waggle dance” recruits other bees to promising food sources.

Cat Swarm Optimization (CSO)

A playful algorithm simulating cat behaviors.
Steps involve sprinkling cats randomly in the solution space, memory pools for seeking, and tracing.
Incorporates randomness and decision-making for problem-solving.

Implementation & demonstrations

Frances demonstrated implementations using the Simple and Fast Media Library (SFML) , highlighting its simplicity for setting up a game loop and employing discrete distributions to model “how one could get the cat out of the bag.”

Her demo underscored how solving problems in a 2D rendering environment can be both engaging and educational. It showcased the power of creating, experimenting, and learning programming skills in a visually intuitive and fun way.

🗣️ Timur Doumler: Contracts for C++

Timur Doumler provided an in-depth exploration of P2900R10 and the concept of contracts in C++, explaining their role, benefits, and the new mechanisms introduced.

What are contracts and why do they matter ?

Contracts - rooted in the design by contract (DbC) paradigm - define formal, precise, and verifiable interface specifications for software components.
These extend typical function definitions with:

Pre-conditions: conditions that must be true before function execution.
Post-conditions: conditions expected after function execution.
Invariants: conditions that remain constant during execution (e.g., class or loop invariants).

Historically, C++ contracts were expressed as comments and documentations through named requirements, custom assertion macros (based on ), or even if used in conjunction with throw statements.
P2900 “Contracts for C++” introduces contract assertions to express these directly in code, enhancing not only clarity and readability, but also tool support.

The purpose of contracts

Contracts allow programmers to:

Express expectations about program correctness (using pre/post-conditions).
Verify these expectations dynamically to identify defects.
Improve documentation, debugging, and static analysis without altering the program semantics.

While contracts share similarities with unit tests, they are not error-handling mechanisms and focus on specifying program correctness rather than runtime behavior guarantees.

Contracts assertions are redundant, acting as additional layers of verification.

P2900 main features

Keywords
- pre and post for function declarations.
  - post(r : r.isValid()) where r names the returned object
- contract_assert within function bodies.
Seamless integration
- Unlike macros, contracts are fully integrated into the language and support modern C++ features like copy-elision.
  - ret in post(ret: ....) refers to the value in the caller side

Practical implementation and integration

A customizable contract violation handler, defined program-wide.
Integration with the standard library using header , in namespace std::contracts.
Implicit constification of variables in contract predicates to ensure safety.

Evaluation semantics

Contracts can be evaluated with different semantics, allowing flexibility based on performance and safety requirements:

Ignore: Parse but do not check the predicate.
Observe: Check the predicate, call the violation handler on failure, then continue.
Enforce (default): Check the predicate, call the violation handler, and terminate on failure.
Quick_enforce: Terminate immediately on predicate check failure.
(not part of P2900) assume: do not check the predicate and optimise on the assumption that it is try (understand: if false, the behaviour is undefined)

Such a choice is implementation defined, and can be defined either:

at compile-time (e.g -fcontract-semantic=enforce)
at load time
at link time
at runtime (e.g enable with a debugger is attached)

Which means that one can’t - and should not, anyway - rely on side-effect.

Challenges & limitations

Contracts focus on runtime-verifiable predicates and cannot address all aspects of plain-language contracts
(e.g “points to an existing object”, “this function will return a value”, etc.).
They are not substitutes for formal correctness proofs or exhaustive static analysis.

A.N: For exhaustive correctness and formal proof, see TrustInSoft static analyzer.
Writing predicates without side effects is critical to maintaining program semantics.

What’s coming next/post-MVP ?

Referring to “old” values at the time of call in contract checks.

Expanding the scope of contracts to cover more advanced scenarios and improve their utility.

See

P2461 - Closure-Based Syntax for Contracts

P3098r1 - Postcondition captures

Conclusion / takeaway

Contracts provide a structured way to express and verify correctness expectations.
Checks must be carefuly designed and used
They enhance static analysis, documentation, and debugging without altering program behavior.
While limited in scope, contracts - as proposed by P2900 - lay a strong foundation for future extensions and safer programming practices.

🗣️ Jens Weller: Meeting C++ update

Jens provided updates on the Meeting C++ ecosystem,
retrospecting about the platform’s growth over the last past 12 years, its strategic direction, and plans for the future.

Meeting C++ 2.0

Online user groups, job fairs, and books & tools fairs - using meetup.meetingcpp.com and meetingcpp.com/mcpp/online/.
Job fairs: help connecting employers (using job board submissions) with candidates through CV uploads and visibility within the C++ community.
Training
Surveys

The Meeting C++ conference

Continues to refine its hybrid model - since 2020 -, offering both onsite and online experiences - which is a real improvement when it comes to accessibility. And will keep it that way for the 2025 edition.
Expand to more content (LinkedIn newsletter, sponsored blog articles, ads, etc.) and ways to monetized the reach.
2024 recordings will be available to attendees post-conference on Hubilo, then will later be available on the MeetingCPP Youtube channel.
2025 will see enhanced tools like Tito for ticketing and Eventbrite integration.
- The call for paper will start in April 2025, and will probably end in July.

Future vision: Meeting C++ 3.0

Expansion into mentoring and commercial training offerings.
Help more C++ users to create local meetup groups, offering advices on starting and running them.
- Encouraged diverse formats, including C++ quizz, coding dojos, book clubs, and lightning talks, to attract varied audiences.

⚡ Secrets Lightning talks

⚡ Ivan Cukic - a brave new world

Ivan Cukic explored the growing focus on safety, energy efficiency, and the broader societal and environmental responsibilities of software development.
He discussed how governments are beginning to regulate IT by responding to popular buzzwords,
and how the C++ committee is reacting to these changes.

Ivan emphasized that the real challenge lies not in tools but in people.
He proposed that - like Agile principles - safety should be a mindset rather than a strict set of tools and practices.
This mindset should encompass a clear definition and manifesto, education for all developers, integration into the software development cycle, and regulations that genuinely improve outcomes for people.

Ivan concluded with a call to action: to educate developers and embrace this “safe new world” with a proactive and adaptable mindset.

⚡ Hana Dusikova - Hashing

See this lightning talk’s video here.

Hana introduced cthash, her single-header C++ library for compile-time hashing,
designed to offer a modern and user-friendly alternative to cumbersome APIs like OpenSSL’s.

Highlighting the verbosity of traditional C interfaces (e.g., SHA256_init + SHA256_update + SHA256_final),
Hana demonstrated how cthash simplifies the process with clean, modern C++ syntax. Streamlined/monadic API, and user-defined string literals _sha256.

Example from the project’s Github repository:

using namespace cthash::literals;

constexpr auto my_hash = cthash::sha256{}.update("hello there!").final();
// or
constexpr auto my_hash = cthash::simple<cthash::sha256>("hello there!");

static_assert(my_hash == "c69509590d81db2f37f9d75480c8efedf79a77933db5a8319e52e13bfd9874a3"_sha256);

⚡ James Mc.Nellis - My least favorite C++ feature

See this lightning talk video here.

James’s least favorite C++ is not like some peoples template nor RAII, but functions pointers.
Why that ? Mostly for a memory safety reason, which in this case lead to security vulnerabilities: attackers can override function pointers.
James highlighted CFI (Control Flow Integrity) technics, which can be used to make the code crash rather than executing the attacker’s code.

Clang CFI (-fsanitize=cfi)
GCC -fstack-protector
Microsoft control flow guard /guard:cf
Armv8.3 pointer authentification

Where are we on security features? - Kees Cook, Qing Zhao, Linux Plumbers Conference

⚡ Phil Nash - Live Demo using `Undo.io` tool on `Doom`

For this demonstration, the speaker used chocolate-doom (website, github) to illustrate how simple, efficient, and perhaps fun Undo.io’s live-recorder can be.

Started to play doom, while live-recording using Undo’s live-recorder.
Then ran the recorded .undo file, which immediatly stops at the point when the record ended.
Demonstrated how display a frame with the game buffer in memory.
Asked the audience for a (x,y) coordinates: 206 and 148.
Used the undo command line last to find out the last time a specific address in memory was changed,
here the pixel matching the x,y coordinates chosed by the audience last I_VideoBuffer[206+148*320],
effectively rewinding and pausing the execution back to this very moment.
Then find out when was the last time an ennemy was on that pixel, and its matching memory address.
As the ennemy’s health at this moment is 0,
then rewind the record back to the precise moment such thing was alive.

The last thing->health command then lead to target->health -= damage,
with the old value 0 and the new value 5
Show the matching rendered game frame, which is exactly when the player killed that ennemy.

⚡ Titus Winters - On parameter sinks

See this lightning talk video here.

Titus Winters delved into the considerations of API design and parameter passing in contemporary C++.

Rvalue references (&&) and move semantics

Rvalue references may be moved but are not inherently moved - but it’s a common misconception that rvalue references always guarantee a move.
Overload sets are the fundamental unit of API design in C++

“Overload operations that are roughly equivalent”, C++ Core Guidelines, C.162.
Ensure APIs clarify intent, aligning function signatures with how resources are managed.
Functions call cost and move operation cost
- Whether data is too expensive to copy is a property of the type, not of a function.
- Cost of function ~= cost of a move: overload set
```
f(const T&);
f(T&&);
```
- Cost of function > cost of a move: pass by value, don’t care about the extra move operation.
```
f(T);
```
- Maybe move ? Such a function had better returns the information is the parameter were actually moved.

⚡ Jens Weller - Networking

Jens shared some insights on common patterns in his networking code,
emphasizing the importance of async programming and robust data handling in scenarios like authentication protocols.

He mentioned:

Popular libraries like QNetworkManager, POCO, and Boost.Asio to implement asynchronous task jobs.
Data management strategies, included handling formats like JSON, XML, raw binary, and compressed streams
Alongside with error-handling considerations.

🗣️ Peter Sommerlad: Collective Amnesia?

🎥 Video, 📄 slidedeck (shared using a QR code on the first slide of the deck !).

“Pay attention - don’t become the grumpy old man ranting”
[A.N] From my perspective, definitly a keynote every developer should attend to or watch online !

In his talk, - with a notable frank speaking - Peter explored the phenomenon of “Collective amnesia” in software development:
our tendency to forget timeless principles, proven practices, and historical lessons in favor of trends, complexity, or convenience.
He encouraged revisiting and applying foundational concepts to modern development, in order to stop repeating the same mistakes over and over again.

For examples, he mentioned that CO2 causing global warming were something studied more than a century ago - see “On the influence of carbonic acid in the air upon global warming”, 1896, Svante Arrhenius -,
and - as a Godwin’s law point -, that the current rise of fascism one can observe all over the world: world war 2 is NOT a thing to repeat ever (concentration camps, etc.).

Why do we forget ?

Amnesia & nostalgia

Forgetting past insights and overvaluing recent trends.
However, nostalgia leads to overlooking the positive aspects of past practices.

Neglected knowledge

Well-established principles (e.g., modularity, type systems) and scientific evidence are ignored.
Proven practices - like unit testing, DRY/OAOO, refactoring, etc. - are underutilized.

Cultural and structural factors

Advances in hardware promote inefficient software.
Trend-driven development repeats mistakes.
Buzzwords-driven design: e.g AI, ML, VR, cloud, blockchain, XML, Java/EJB, CORBA, etc.
Powerful men influence/impact: drunk by power, money and eagerness for control while being socially irresponsible, which results in too few benefit at the cost of most.
Lack of investment in education and fundamentals: Badly paid teachers/trainers teaching obselete technics, while techs suffer from a long learning curve.

Risk aversion and populism

Following the crowd for safety - e.g “if everybody is doing it, we also should”, “nobody gets fired for buying IBM/Cisco”.
Simplistic (loud) solutions and populist thinking overshadow realistic (calm) approaches.
Ignorance, lack of pragmatism/forecasting: cost & consequences of a trend.

Forgotten foundations

Timeless principles

Simplicity, SoC (separation of concerns), high cohesion, loose coupling, testability, and exchangeability,
which often result in untestable product, and unmaintainable codebase - thus no more delivered value.
Neglecting these principles increases long-term costs and complexity.

Historical insights

Modularization: Independence, changeability, SoC, and hiding design decisions.
“On the criteria to be used in decomposing systems into modules”, 1972, D.L. Parnas
Type systems: Clarity and prevention of misinterpretation.
“A Formulation of the Simple Theory of Types”, 1940, A. Church
Refactoring: Continuous improvement of existing code.
“Refactoring Object-Oriented Frameworks”, 1992, William F. Opdyke & Ralph Johnson
Unit Testing: A proven practice often overlooked.
“Simple Smalltalk Testing: With Patterns”, 1989, Kent Beck

Software architecture and design patterns

“Lower quality is the most expensive thing in software: Good-enough is never good-enough.”

Pitfalls

Often biaised and reduced to 23 GoF design patterns.
Overemphasis on cloud, distribution, and increasing complexity.
Ignoring internal quality and codebase, leading to hard-to-maintain systems.

Dependencies management

Avoid singletons, global variables, and hidden side effects.
Avoid tight-couplings and hidden relationships.
Refactor regularly to improve maintainability.

Caution with patterns

Understand liabilities before adopting patterns.
Layers and tiers must balance abstraction and granularity.
Challenge designs and architecture decisions.

The C++ type system as a key tool

Ensures meaning & safety: associating types with expressions and entities, preventing misinterpretation of data and raising errors when meaningless operations are attempted.
Facilitates efficient & flexible code: detects type errors with strong safety, supports both implicit & explicit conversions, and enables type deduction through features like auto and templates, for a smaller and more flexible code.

Best practices

Testing

Replace interactive debugging with automated testing.
Favor TDD for immediate feedbacks.
Write Good Unit Tests (GUTS).

Simplicity over complexity

Refactor mercilessly, as a demonstration of love to your future self and colleagues.
- Focus on naming, function & classes granularity, parameterization, and algorithms.
Less code equals more software, move value.
Start with the simplest solution, not the newest nor a complicated one.

Conclusion, key takeaway, and broader thoughts

Human/societal lessons

Learn from history to avoid repeating mistakes (e.g., climate crisis, fascism).
Promote responsibility, equity, and sustainable practices.

Developer mindset

Love your codebase by simplifying and improving it for future maintainers.
Prioritize timeless principles over fleeting trends.

Takeaways

Revive and apply forgotten software principles.
Simplify architecture and code through regular testing and refactoring.
Embrace C++’s strengths to write maintainable and efficient software.
Act responsibly in both software and societal contexts by valuing simplicity, sustainability, and human connection.

Additional inputs from questions

Peoples who are not willing to learn continuously should not be doing softwares. Learning is a life-long experience.
Code should not even be consider existing if it not paired with tests.
Question: What are your thoughts about mocking ?
Answer: CppCon-2017: mocking considered harmful. It hides dependencies. Make the codebase less likely to change, in order not to break changes.
Question (me): Any advise for a professional C++ trainer who struggle a lot with juniors strong beliefs,
and the inertia we have in the academic which often make teachers to teach very deprecated content ?
Same to fight dogmas, and bring more pragmatism into leaders/managers mind ?
Answer: There’s no easy answer. Had to quit my jobs before when my values were too much violated.
It’s always hard to solve peoples problems because it involes peoples.
Show love. Peer-programming actually works. Build trust, learn new things. Code katas.

Conclusion

Attending Meeting C++ 2024 was, as always, an very enjoyable and interesting experience.
The event provided an incredible blend of technical depth and thought-provoking discussions on broader topics that resonated with the C++ community current concerns and needs.
I particularly appreciated how some talks and keynotes echoed and complemented each others, weaving a coherent narrative across diverse sessions.
This interplay added significant value to the conference and highlighted the care put into curating the program.

Another standout aspect was the inclusion of more talks that focused not just on technical challenges but also on delivering value sustainably, while preserving developers’ mental and physical health.
These sessions offered underscored the importance of fostering a holistic and pragmatic approach to software development.

I would like to extend my heartfelt thanks to Jens and all the organizers for their dedication and hard work in making this event a success.
My gratitude also goes to the speakers, who shared their insights and expertise, and to the sponsors, whose support made this gathering possible.
Together, they created an environment that inspires learning, collaboration, and growth.

One area for improvement, however, was the scheduling system, particularly for remote attendees managing time zone differences.
While the MeetingCpp and Hubilo platforms allow users to set their own time zones, the feature felt buggy.
For instance, selecting Paris CET resulted in the schedule being shifted one hour earlier, despite Berlin *(where the conference is hosted) and Paris are sharing the same time zone.
Addressing this issue would enhance the remote attendee experience next year.*

Also, while attending the conference remotely, I had a great experience interacting with the online chat during talks,
and really appreciated that some of my questions were upvoted and asked to the speakers.

I definitly look forward for next year’s event (perhaps, on-site !).
The Meeting C++ conference is like fine wine or aged cheese: each year adds depth and character, refining the experience and making it richer, more rewarding, and ever more enjoyable with age.
I’m excited to see what 2025 will bring!

Until then, take care, keep learning & love C++. See you folks !

Guillaume.

If you enjoyed this paper:

👍 Consider leaving a “like” and a comment - at the bottom of this page, and on LinkedIn.
📩 Share this paper with your friends, colleagues, teachers, students.
📖 You might be interested in last year’s: Conference - Meeting Cpp 2024 - Trip report.

Guillaume Dua

Trip Report - Meeting Cpp 2025

Introduction

📅 11/06/2025

🗣️Jens Weller: Welcome Message

Sponsors

Creating a safe and inclusive environment

In memory of Rainer Grimm

🗣️Anthony Williams: Software and safety (Opening Keynote)

What safety means ?

Standards and mindset

Why systems fail ?

Undefined behaviors (UB) and reliability

Contracts in C++26 as a safety leverage

Defense in depth, using appropriate strategy and tools

The Arene Base library

My takeaway

🗣️Sebastian Theophil: To Err is Human: Robust Error Handling in C++26

The landscape of error handling: historical perspective

The modern stuffs: std::expected

The modern stuffs: contracts

Library hardening in C++26

Practical rules for real-world code

About ThinkCell’s error reporting

My takeaway

Additional resources: learn more about error handling

🗣️Nicolai Josuttis: Using std::generator<> in Practice

What coroutines are (and aren’t)

What std::generator brings

Pitfalls and caveats

My takeaway

Additional resources: learn more about coroutines

🗣️Sandor Dargo: Code Reviews: Building Better Code and Stronger Teams

The value of code reviews

Common arguments and misconceptions

The human aspects

Sandor’s AIR methodology

My takeaway

Bonus: How I personally do code reviews

Conclusion

🗣️Anders Schau Knatten The Two Memory Models

What are the two memory models ?

At language-level

At CPU-level

Mental model for developers

My takeaway

Additional resources

📅 11/07/2025

🗣️Jens Weller - Good Morning Meeting C++

My takeaway

🗣️ Frances Buontempo - Center Keynote - Stoopid Questions

My takeaway

🗣️ Jonathan Müller - Cache-Friendly C++

Cache-friendly code: why does it matter ?

Data structures matter

Type size and layout affect cache use

Prefetching & cache lines

Code is data too

Data-Oriented Design (DOD)

Multicore pitfalls

My takeaway

🗣️ Andreas Fertig - Embedded-Friendly C++: Features That Make a Difference

Content

My takeaway

🗣️ Daniela Engert - Towards Safety and Security in C++26

Content

My takeaway

🗣️ Raymi Klingers - 25+ Years of pathfinding problems with C++

Content

My takeaway

📅 11/08/2025

🗣️ Klaus Iglberger - The Real Problem of C++

Safety vs. performance: an historical tradeoff

Bounds safety

Undefined behaviors: the silent killers

Type safety through strong types

Lifetime safety: value semantics over inheritance

Conclusion: the real problem is a people problem

My takeaway

Additional sources

About `ThinkCell`’s error reporting

🗣️Nicolai Josuttis: Using `std::generator<>` in Practice

Traditional OOP/`vtable` approach

Is `std::variant` (a modern) alternative ?