moc: Properly handle modules

When moc'ing module interfaces and partitions, we make the generated cpp
file part of the respective module.
We do not support Q_OBJECT & friends in implementation units and private
module fragments, as our generated source file will not have access to
the respective classes, and we certainly do not want to carry over our
file inclusion hacks into the module world.

[ChangeLog][moc] moc now supports C++ modulesmoc: Properly handle modules

Note there is still a lot of work to be done: https://codereview.qt-project.org/c/qt/qtbase/+/767846 and I can't seem to find the PR where they fixed some qtbase code to make it work with modules. I guess most other qt modules will need some small fixes to work with modules as well.

C++Now

2026-08-31 - 2026-09-06

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

ACCU

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

What if AI could do more than suggest code, and actually drive hardware-in-the-loop test cycles on real systems? This talk looks under the hood of a practical agentic AI workflow for embedded C++ development.

I recently did a big update to my ankerl::unordered_dense::map which now features several optimizations, bug fixes, and most importantly an SSE optimized lookup which brings the lookup speed quite close to the fastest competitor which is boost::unordered_flat_map. Get it here: https://github.com/martinus/unordered_dense

Since it is not easy to decide what map is best for one's usecase, I have redone and improved the benchmarks I did a while ago, crunched some numbers and tried to compress everything into a quiz that helps you figure out what to use.

While doing the numbers, a few things surprised me:

• My random access benchmark was not random enough. The CPU was able to optimize the branch predictor in a way I did not think was possible. I have fixed this for the new numbers. Clever girl.

• Even though the absl maps are very similar in concept to the boost maps, they perform badly if you expect lots of misses. 1.6 times slower than boost.

• I didn't think SSE optimization of my unordered_dense map would be any benefit. Thanks to AI, I found a way to speed up random access a lot, it is now very close to boost::unordered_flat_map.

• Heavy insert & erase on flat maps require rehashing every once in a while due to the accumulation of tombstones. That means some insert/erase operation will have very high latency. This does not happen for a robin-hood hashmap like my unordered_dense map.

It would be nice if there was a single place to see where, for example, the keyword "SFINAE" shows up across the content of all papers, not just titles. Thanks!

I know this is something that pops up quite often, but I was wondering if I could get your guys' opinion on a fixed ordering of qualifiers. This is my current thoughts after recently trying to formalize my personal style:

static -> thread_local -> inline -> constexpr -> friend -> virtual

My reasoning for each:

1. static first. Inside a class, its basically javas static. There is a pretty strong consensus in java for static first. Its very important context, for both functions and variables. Outside of classes, its more of a linkage specifier, which is arguably more important/nasty if you mess it up. The fact that it has this dual behaviour in C++ in my opinion makes an even stronger argument for including it first, your brain is able to parse it first thing. i.e okay this is static, we are in a class? -> its java static, we are in global scope -> its static linkage.
2. thread_local directly after static, and then inline, then constexpr/consteval. This way, qualifiers which impact storage and or linkage are stuck together. I personally like to write inline even for constexpr/consteval functions, as its sometimes easy to forget the implicit inline. I used to do this for member functions with definitions in the class, but I feel the implicit inline there is a bit more well known/easier to intuit.
3. The rest I'm far less opinionated on, since I barely ever use inheritance or the friend keyword. . I could go both ways on virtual/friend, so i default to alphabetical/aesthetics.

What do you guys think? I know this is pedantic and a very well explored topic but I wanted to know if you guys had any particular wisdom to sway me either way, mainly on the ordering of the first few.

C++Now

2026-08-24 - 2026-08-30

• No Compiler Required - Hand-Rolling C++20 Coroutines in C++17 - Johannes Kalmbach - C++Now 2026 - https://youtu.be/WabG-ku-Osk
• Optimizing Bishop, Rook, and Queen Move Generation in a Chess Engine - Aryan Naraghi - C++Now 2026 - https://youtu.be/beo7kPRoZyY
• What is your Algorithmic Core? - Egor Suvorov - C++Now 2026 - https://youtu.be/NYClJyMVtk8

2026-08-17 - 2026-08-23

• Coroutines for Dummies - Dominic Fischer - https://youtu.be/apLDto3FUVA
• Compile-Time Borrow Checker with Stateful Metaprogramming - Alon Wolf - https://youtu.be/3hL8mh0K8-I
• Algorithms for Trees - Foldable, Applicative, Traversable - Steve Downey - https://youtu.be/vfXKH7Uj170

2026-08-10 - 2026-08-16

• After Reflection: The Runtime Story - Saksham Sharma - https://youtu.be/bUmt9K1o1d0
• A Little Introduction to Control Flow Integrity in C++ - James McNellis - https://youtu.be/FNHMwi_0psQ
• Towards Async Everything Part 1 - Senders as the Lowest Layer - Robert Leahy - https://youtu.be/3PI31yqjI_w
• Towards Async Everything Part 2 - Scopes, Construction, and Destruction - Robert Leahy - Robert Leahy - https://youtu.be/Hgdikbfu9UE

2026-08-03 - 2026-08-09

• How To Make Formal Methods A Software Quality Solution That Can Actually Be Used In The Industry - Steve Barriault - https://youtu.be/OYwDdMCCDIM
• Link What You Include - Maintain a Coherent CMake Target Model - Frank Miller - https://youtu.be/ssTG6uzxXm4
• Scaling beman.exemplar - Eddie Nolan - https://youtu.be/xylmqy1VAwo

2026-07-27 - 2026-08-02

• Beautiful C++ Code - Told Through the Eyes of A Failed AI Prompt - Erich Lohrmann - https://youtu.be/Kq4W3Y5gTI8
• A Path to Practically Safe C++ - Yitzhak Mandelbaum - https://youtu.be/fi6csDXvve0
• When Abstractions Fix Too Much - Towards Flexible Library Design - Patrick Roberts - https://youtu.be/IKIyFUcVvis

C++Online

2026-08-24 - 2026-08-30

• Lightning Talk: It’s Emulators All the Way Down - Koen Samyn - https://youtu.be/7DFSCTNBecc
• Text Processing in C++ - The TProc Library - Amlal El Mahrouss - https://youtu.be/INugVdT5EAE

2026-08-17 - 2026-08-23

• Lightning Talk: Bazelizing a C++ Project - Paulo Chiliguano - https://youtu.be/agAbiQydcOQ
• Lightning Talk: Can We Still Find Joy in Programming? - Sandor Dargo - https://youtu.be/WxqeLwyw0KM

2026-08-10 - 2026-08-16

• Lightning Talk: Saving Time With Runtime and Having Registry Level Synthesis of Your Software As You Write It - Michael Hubbard - https://youtu.be/B0JJwWMUzzw
• Lightning Talk: 2 New Nice CMake Features I Learned in 2025 - Lieven de Cock - https://youtu.be/YnWJyHxHpBc

2026-08-03 - 2026-08-09

• Lightning Talk: Your Docs Have a New Reader (and It Hallucinates) - Paul Wicking - https://youtu.be/DbL6XPMlw-o
• Lightning Talk: RPC With Coroutines, RAII and Callable Weakpointers - Edward Boggis-Rolfe - https://youtu.be/m70hb5YgabQ

2026-07-27 - 2026-08-02

• Dynamic Asynchronous Tasking with Dependencies - Tsung-Wei (TW) Huang - https://youtu.be/4LzQHw7jz2g
• C++/sys - A Standard Library Projection to Facilitate the Verification of Run-time Memory Safety - Karsten Pedersen - https://youtu.be/dF7RwJw_G8c

ADC

2026-08-24 - 2026-08-30

• Modern Feedback Delay Networks for Realistic and Creative Reverberation - Gloria Dal Santo - https://youtu.be/P604tjJURLc
• Cross-Platform Framework for Textural Granular Processing - Aman Jagwani & Victor Lazzarini - https://youtu.be/lQq9HT4Pgv4
• It’s Just a Phase - Exploring Synthesis With the Phase Vocoder - Cameron Thomas - https://youtu.be/t07jphjIA0Y

2026-08-17 - 2026-08-23

• How To Distribute Your Plugins - Using MuseHub as the Engine To Get Your Audio Tools in the Hands of Millions - Khaled Said - https://youtu.be/CQTblE1xHto
• Incline - Topographic Microsound Explorer - Cristián Vogel - https://youtu.be/lJA00sRFhGg
• Optimizing UI Rendering Performance in Cubase and Nuendo - Erich Krey - https://youtu.be/Oz1dZLcXVjs

2026-08-10 - 2026-08-16

• Measuring and Improving UI Performance with the JUCE C++ Framework - Anthony Nicholls - https://youtu.be/0n9x6R0fheo
• Real-Time Raytraced Acoustics for Games: Dynamic Reverb with IR Synthesis & Time-Varying Convolution - Anton Lundberg - https://youtu.be/iT0olrM1iyU
• Building an Optimized DSP Framework in Modern C++ - Scott Carver - https://youtu.be/k4yxNxNCo0k

2026-08-03 - 2026-08-09

• Commercialising Audio Plugins - Going From Development to Sales and Beyond - Tobias Lønnerød Madsen - https://youtu.be/SWPLyDDBU38
• Capturing and Transferring Expressive Microtiming in Drumming - Eemi Fagerlund - https://youtu.be/4ZAJHl02X7s
• How I Learned to Love the Docs - Documentation As Design Process for Music Tech Products - Astrid Bin - https://youtu.be/7MpDAHd7rbw

2026-07-27 - 2026-08-02

• Workshop: Programming Music and Synthesizers on-the-fly with Pharo - Domenico Cipriani - https://youtu.be/v95QYyUHNJ8
• PolyBLEP & PolyBLAMP Demystified - Nis Wegmann - https://youtu.be/_bW8TfgEqRM
• Modernizing Legacy Audio Plugin Codebases - Lessons from FL Studio’s Plugin Suite - Tomas Medek - https://youtu.be/zY8uHzAdnzk
• How to Write Scalable, Deterministic Audio Engines - Janus Lynggaard Thorborg - https://youtu.be/3FXQQmQa-ak

The intro from August's StockholmCpp Meetup: news about C++ in Sweden from the NB and the community, some words from our event sponsor, and, of course, a quiz!

I am far from presuming myself a compiler expert, and no this was not AI, I promise. I'm simply a long-time user of gcc/g++, and it's not everyday I am confident enough that a bug is not in my code but with the tool, haha. I'm pretty warning-sensitive so this kind of thing catches my attention. Wondering if I'm missing something, so asking it here first.

g++ version: g++ (GCC) 16.2.1 20260819 (Red Hat 16.2.1-2) (I'm on Fedora 44)
C++20

Given lines like this:

cpp std::uint16_t count = 0; // int other_var set elsewhere count += (other_var == 5); // <-- -Wconversion flags this

specifically, the warning is:

bash <file>:<line>:<col>: warning: conversion from ‘int’ to ‘uint16_t’ {aka ‘short unsigned int’} may change value [-Wconversion] <line> | count += (other_var == 5);

-Wconversion /w either -O0 and -O3 (my usual build optimization lvls to catch optimization-dependent warnings), this gets flagged.

Well, the result of a boolean expression is 0 or 1, so obviously, there should not be a conversion. Even with the accumulate op here and integer promotion, there shouldn't be a warning (you can do count += 1 or count++ and it definitely doesn't flag -Wconversion). And more notably, the below code doesn't get flagged:

cpp std::uint16_t count = 0; // int other_var set elsewhere bool match = (other_var == 5); count += match;

I also noted that clang with -Wconversion and the same optimization lvls does not flag this. I also know I've done this before in C with other versions of gcc and don't get flagged with this.

So, am I missing something or am I right to suspect this is a possible bug with at least my version of g++?

If you're trying to define two pointers in a single statement (what is in general a bad idea), you may want to do it like this:

#include <print>

int main()
{
    int x = 10;
    int* a, b;
    a = &x;
    b = &x;
    std::println("a={:#x}, b={:#x}", uintptr_t(a), uintptr_t(b));
}

However, it doesn't work as you expect, and won't compile. Because int* a, b; declares only a as int*; b, and all the rest variables will be int. The correct one-statement declaration of two pointers is int* a, * b;

main.cpp:8:9: error: invalid conversion from ‘int*’ to ‘int’ [-fpermissive]
    8 |     b = &x;
      |         ^~
      |         |
      |         int*

b has type int

This behavior is the reason why some people prefer putting the asterisk next to the variable name, not next to the type

I can understand the logic, that C authors had while making this syntax. It's a sort of reversive/deduction logic. You kinda declare what type it will be after using the dereference * operator, instead of declaring the type being a pointer itself. But I find this logic very-very strange, and overthought

The funny thing, that even the compiler in the error message above, treats * as a sort of type modifier, that is inseparable from int. But, apparently, the C creators had a completely different vision on what pointers are

I personally don't think that this behavior justifies reteaching yourself to write * in front of variable names, and especially in front of function names. I think it's just a not well-thought decision made very long ago in 1970s