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.

Hey everyone,

I wanted to share some architecture insights from a large hobby project I have been developing in modern C++ (C++17/20): an execution environment and compiler runtime called Uranium.

Rather than wiring up heavy third-party backends like LLVM, the goal was to build the entire systems layer directly in C++ to understand execution mechanics at the hardware level.

Key C++ architecture details:

1. JIT without external libraries (src/native_jit_x64.cpp): Implemented a lightweight assembler in C++ that allocates executable pages (VirtualAlloc on Windows, mprotect on POSIX) and emits raw x86_64 opcodes directly for hot numeric loops and branch patching. It detects hot execution paths via loop back-edge tracking in the interpreter dispatch loop.

2. Generational GC and Memory Management (src/heap.cpp): Instead of generic smart pointers or standard allocators, memory is managed through an anti-fragmentation object pool using placement new. It features a two-tier generational Mark & Sweep (young nursery vs full sweep) guarded by pointer write barriers (writeBarrier) to maintain remembered sets.

3. Concurrency & Native Subsystems: Built a cooperative async task scheduler, custom socket abstraction for raw TCP, and embedded SQLite3, all unified within the C++ runtime.

Repository: https://github.com/bruhgit/Uranium-Programming-Language

I would love to get feedback on the modern C++ idioms, memory layout, or any potential architectural bottlenecks from fellow C++ systems developers!

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

It's been just over a year since our last significant release, and this one ended up big... honestly, maybe a bit over-stuffed. 😅 We did tackle both of the biggest requests from the last post: we no longer swallow compiler errors (see our new compiler warnings philosophy doc for more details), and we have worked examples. Besides these, some of the remaining highlights are:

• Full vector and matrix support: everything except mixed-units in a single vector/matrix
• First-class Eigen support --- the first units library to preserve Eigen's full performance in all cases
• CUDA (and HIP) are now supported out of the box
• More powerful/flexible user-defined literals compared to other libraries (see this fascinating Abbreviated Quantity Construction discussion doc for the nuances here)
• More ergonomic integer division: divide_using_common_unit(a, b) is almost always what you want for same-dimension inputs
• Constant and Magnitude now get arithmetic and comparison operators whenever the results are computable, making them much more ergonomic

We also refreshed our C++ units library comparison page. It's awesome to see all the progress on the other leading libraries, as well as ours!

We hope you find the new release useful and fun, and we're excited to hear any feedback you may have!

Hey guys,

I recently started going through Professional C++ (6th Edition). The book teaches C++23, and in the very first chapter we're introduced to modules.

I'm not a complete newbie to C++, but I'm also definitely not very confident in my knowledge yet. I wanted to get this simple example compiled:

import std;

int main() {
    std::println("Hello World");
    return 0;
}

And gosh, it took way longer than I expected.

First, I tried getting it to work natively on my Mac and eventually gave up (both Claude and I 😅).

Then I installed Ubuntu ARM 26 and finally managed to get it compiling. But now Clang/IntelliSense is complaining about the `import std`
This is what my CMakeLists.txt currently looks like:

cmake_minimum_required(VERSION 4.0)

# set(CMAKE_EXPERIMENTAL_CXX_IMPORT_STD ON)

set(CMAKE_EXPERIMENTAL_CXX_IMPORT_STD "d0edc3af-4c50-42ea-a356-e2862fe7a444")

project(CppProject LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 26)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)

set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

add_executable(exec main.cpp)

set_property(TARGET exec PROPERTY CXX_MODULE_STD ON)

The code does compile successfully, but CMake still gives me a warning that import std support is experimental.

So I'm genuinely curious:

Why is import std still considered experimental?

I understand that C++ modules themselves have been around for a while, but import std feels like something that should be much more straightforward by now. Is there any solution of this now ?

--------------
Edit

Thanks to u/PhysicsOk2212 tip I was able to compile my project on mac as well using the following options
```
cmake -S . -B build \

-G Ninja \

-DCMAKE_CXX_COMPILER="$(brew --prefix llvm)/bin/clang++" \

-DCMAKE_CXX_STDLIB_MODULES_JSON="$(brew --prefix llvm)/lib/c++/libc++.modules.json"

```

TICKETS AVAILABLE TO PURCHASE

The following conferences currently have tickets available to purchase

• Last Chance – CppCon (12th – 18th September) – You can buy standard tickets until August 29th at https://cppcon.org/registration/
• C++ Under The Sea (14th – 16th October) – You can buy early bird tickets at https://sales.ticketing.cm.com/cppunderthesea2026/
• ADC – (9th – 11th November) – Tickets for ADC can now be purchased at https://ti.to/audio-developer-conference/adc-bristol-2026
• Meeting C++ (26th – 28th November) – You can buy early bird tickets at https://meetingcpp.com/2026/

OPEN CALL FOR SPEAKERS

There are currently no open call for speakers

OTHER OPEN CALLS

• CppCon Call For Open Content – CppCon are looking for presenters to give open content sessions during the conference which takes place from September 14th – 18th. For more information including how to apply visit https://cppcon.org/cppcon-2026-call-for-open-content/
• ADC Call For Online Volunteers Now Open – Interested volunteers have until September 27th to apply to volunteer online at ADCx Gather which is scheduled to take place on 16th October and/or ADC 2026 online conference which is scheduled to take place from 9th – 11th November. To apply visit https://docs.google.com/forms/d/e/1FAIpQLScpH_FVB-TTNFdbQf4m8CGqQHrP8NWuvCEZjvYRr4Vw20c3wg/viewform?usp=dialog
• ADC Call For Posters – ADC is looking for
  • Virtual Posters for ADCx Gather which is scheduled to take place on 16th October and/or ADC 2026 online conference which is scheduled to take place from 9th – 11th November. Find out more including how to apply at https://conference.audio.dev/virtual-posters/
  • Physical Posters for ADC 2026 which is scheduled to take place from 9th – 11th November in Bristol UK. Applications can be made by filling out the following form https://docs.google.com/forms/d/e/1FAIpQLScKteDljM9Dc4tgQ6HC9xaPEaYfW7oe_Qr21y-1Jxn5s9eAIg/viewform?usp=dialog

TRAINING COURSES AVAILABLE FOR PURCHASE

Conferences are offering the following training courses:

CppCon Online Workshops

9th – 11th September

1. Modern C++: When Efficiency Matters – Andreas Fertig – 3 day online workshop available on 9th – 11th September 09.00 – 15.00 MDT – https://cppcon.org/class-2026-when-efficiency-matters/
2. System Architecture And Design Using Modern C++ – Charley Bay – 3 day online workshop available on 9th – 11th September 09.00 – 15.00 MDT – https://cppcon.org/class-2026-system-architecture-and-design-using-modern-cpp/

21st – 23rd September

1. C++ Fundamentals You Wish You Had Known Earlier – Mateusz Pusz – 3 day online workshop available on 21st– 23rd September 09.00 – 15.00 MDT – https://cppcon.org/class-2026-cpp-fundamentals/
2. C++23 in Practice: A Complete Introduction – Nicolai Josuttis – 3 day online workshop available on 21st– 23rd September 09.00 – 15.00 MDT – https://cppcon.org/class-2026-cpp23-in-practice/
3. Programming with C++20 – Andreas Fertig – 3 day online workshop available on 21st– 23rd September 09.00 – 15.00 MDT – https://cppcon.org/class-2026-programming-with-cpp20/

26th – 27th September

1. Using C++ for Low-Latency Systems – Patrice Roy – 2 day online workshop available on 26th– 27th September 09.00 – 17.00 MDT – https://cppcon.org/class-2026-low-latency/

CppCon Onsite Workshops

All onsite workshops will take place in the Gaylord Rockies in Aurora, Colorado

12th & 13th September

1. Advanced and Modern C++ Programming: The Tricky Parts – Nicolai Josuttis – 2 day in-person workshop available on 12th & 13th September – 09:00 – 17:00 – https://cppcon.org/class-2026-tricky-parts/
2. C++ Best Practices – Jason Turner – 2 day in-person workshop available on 12th & 13th September – 09:00 – 17:00 – https://cppcon.org/class-2026-best-practices/
3. How Hardware Gets Hacked: Breaking and Defending Embedded Systems – Nathan Jones – 2 day in-person workshop available on 12th & 13th September – 09:00 – 17:00 – https://cppcon.org/class-2026-hardware-hack/
4. Mastering `std::execution`: A Hands-On Workshop – Mateusz Pusz – 2 day in-person workshop available on 12th & 13th September – 09:00 – 17:00 – https://cppcon.org/class-2026-execution/
5. Performance and Efficiency in C++ for Experts, Future Experts, and Everyone Else – Fedor Pikus – 2 day in-person workshop available on 12th & 13th September – 09:00 – 17:00 – https://cppcon.org/class-2026-performance-and-efficiency/
6. Talking Tech – Sherry Sontag – 2 day in-person workshop available on 12th & 13th September – 09:00 – 17:00 – https://cppcon.org/class-2026-talking-tech/

 13th September

1. AI++ 101 : Build a C++ Coding Agent from Scratch – Jody Hagins – 2 day in-person workshop available on 12th & 13th September – 09:00 – 17:00 – https://cppcon.org/class-2026-AI101/
2. Essential GDB and Linux System Tools – Mike Shah – 1 day in-person workshop available on 13th September – 09:00 – 17:00 – https://cppcon.org/class-2026-essential-gdb/

19th & 20th September

1. AI++ 201: Building High Quality C++ Infrastructure with AI – Jody Hagins – 2 day in-person workshop available on 19th & 20th September – 09:00 – 17:00 – https://cppcon.org/class-2026-ai201/
2. Function and Class Design with C++2x – Jeff Garland – 2 day in-person workshop available on 19th & 20th September – 09:00 – 17:00 – https://cppcon.org/class-2026-function-class-design/
3. High-performance Concurrency in C++ – Fedor Pikus – 2 day in-person workshop available on 19th & 20th September – 09:00 – 17:00 – https://cppcon.org/class-2026-high-perf-concurrency/

OTHER NEWS

• (NEW) Schedule Announced For CppCon – The schedule has been announced for CppCon. Visit https://cppcon2026.sched.com to view the full schedule.
• (NEW) Schedule Announced For ADC 2026 – The schedule has been announced for ADC 2026. Visit https://conference.audio.dev/schedule to view the full schedule. More sessions and workshops will be added over the next few weeks
• (NEW) ADCx Gather Announced – ADC have announced ADCx Gather which is a free online event which will take place online on October 16th. For more information visit https://audio.dev/adcx-gather-info/ and if you would like to attend, please fill out the registration form https://docs.google.com/forms/d/e/1FAIpQLSeg0twh4PbYqCqcoPpl5cnFBeU6y5Ea3921V2kl3F7Wy03umw/viewform?usp=dialog  
• Boost Documentary screening at CppCon 2026 – Boost Libraries have announced that they will be screening a documentary on the history of Boost at CppCon 2026. Watch the trailer here https://youtu.be/myQRC4f9jTE

Finally anyone who is coming to a conference in the UK such as C++ on Sea or ADC from overseas may now be required to obtain Visas to attend. Find out more including how to get a VISA at https://homeofficemedia.blog.gov.uk/electronic-travel-authorisation-eta-factsheet-january-2025/

Some libraries try to support:

• Header/Source
• Header only
• Header only + Module Wrapper
• Header/Source + Module Wrapper
• All standards between and including C++11 and C++23
• Exceptions and noException
• RTTI and noRTTI

At the same time.

These libraries are very very hard to read and thus they get less and less contributions over time.

What should be done:

• Libraries should support only one mode of compilation, header only header source etc
• Libraries should support exactly one standard, and that standard includes extensions, gnu++23 and c++23 are not the same thing
• Libraries should very clearly have boundaries on what belong in a toolchain and what belongs to project. For example a library should not set flags related to exceptions that's a toolchain issue.

Some extra stuff:

• C++ libraries without C API's should not be consumed via system package managers at all, and public libraries shouldn't try to adhere to that.
• Libraries shouldn't try to use tools they build to build themselves, rather they should export packages like wayland::scanner etc and use that.