Possible GCC reflection error

Playing with GCC I got a situation like this:

#include <algorithm>
#include <array>
#include <print>
#include <meta>


consteval auto Name(const int integer){
    return std::meta::displaystringof(^^integer);
}
consteval auto Name(const std::meta::info meta){
    return std::meta::displaystringof(meta);
}
// <source>:21:28: error: call to consteval function 'Name(^^int)' is not a constant expression
//    17 |     std::println("{}", Name(^^int));
//       |                        ~~~~^~~~~~~
// But removing const fix it!! (works in Clang P2996)




int main(){
    std::println("{}", Name(3));
    std::println("{}", Name(^^int));


    return 0;
}

I think that this is not the expected behaviour, but is it a known bug to be patched?

https://redd.it/1po9oz2
@r_cpp

Jubi - Lightweight 2D Physics Engine

Jubi is a passion project I've been creating for around the past month, which is meant to be a lightweight physics engine, targeted for 2D. As of this post, it's on v0.2.1, with world creation, per-body integration, built-in error detection, force-based physics, and other basic needs for a physics engine.

Jubi has been intended for C/C++ projects, with C99 & C++98 as the standards. I've been working on it by myself, since around late-November, early-December. It has started from a basic single-header library to just create worlds/bodies and do raw-collision checks manually, to as of the current version, being able to handle hundreds of bodies with little to no slow down, even without narrow/broadphase implemented yet. Due to Jubi currently using o(n²) to check objects, compilation time can stack fast if used for larger scaled projects, limiting the max bodies at the minute to 1028.

It's main goal is to be extremely easy, and lightweight to use. With tests done, translated as close as I could to 1:1 replicas in Box2D & Chipmunk2D, Jubi has performed the fastest, with the least amount of LOC and boilerplate required for the same tests. We hope, by Jubi-1.0.0, to be near the level of usage/fame as Box2D and/or Chipmunk2D.

Jubi Samples:

#define JUBIIMPLEMENTATION
#include "../Jubi.h"

#include <stdio.h>

int main() {
    JubiWorld2D WORLD = JubiCreateWorld2D();

// JBody2DCreateBox(JubiWorld2D *WORLD, Vector2 Position, Vector2 Size, BodyType2D Type, float Mass)
    Body2D *Box = JBody2DCreateBox(&WORLD, (Vector2){0, 0}, (Vector2){1, 1}, BODYDYNAMIC, 1.0f);
   
    // ~1 second at 60 FPS
    for (int i=0; i < 60; i++) {
        JubiStepWorld2D(&WORLD, 0.033f);

        printf("Frame: %02d | Position: (%.3f, %.3f) | Velocity: (%.3f, %.3f) | Index: %d\n", i, Box -> Position.x, Box -> Position.y, Box -> Velocity.x, Box -> Velocity.y, Box -> Index);
    }
   
    return 0;
}

Jubi runtime compared to other physic engines:

|Physics Engine|Runtime|
|:-|:-|
|Jubi|0.0036ms|
|Box2D|0.0237ms|
|Chipmunk2D|0.0146ms|

Jubi Github: https://github.com/Avery-Personal/Jubi

https://redd.it/1prwf8o
@r_cpp

Semantics
Perfect Forwarding
Smart Pointers
constexpr
Initializer Lists
Delegating Constructors

C++14 FEATURES
Generic Lambdas
Return Type Deduction
Binary Literals
Variable Templates

C++17 FEATURES
Structured Bindings
if/switch with initializers
std::optional
std::variant
std::any
Fold Expressions
Inline Variables

C++20 FEATURES
Concepts
Ranges
Coroutines
Modules
Three-way Comparison (<=>)
std::span

MEMORY MANAGEMENT
Stack vs Heap
RAII (Resource Acquisition Is Initialization)
Smart Pointers
- unique_ptr
- shared_ptr
- weak_ptr
Custom Allocators
Memory Pools

EXCEPTION HANDLING
try-catch blocks
throw keyword
Exception Classes
Standard Exceptions
noexcept specifier
Exception Safety Guarantees

FILE I/O
Stream Classes
- ifstream, ofstream, fstream
File Operations
Binary File I/O
String Streams
Formatting

MULTITHREADING
std::thread
Mutexes and Locks
Condition Variables
Atomic Operations
Thread-local Storage
Futures and Promises
async

PREPROCESSOR
Macros
#include
Header Guards
#pragma once
Conditional Compilation

ADVANCED TOPICS
Type Casting
- static_cast
- dynamic_cast
- const_cast
- reinterpret_cast
RTTI (Runtime Type Information)
Operator Overloading
Copy Elision and RVO
Perfect Forwarding
Name Mangling
Linkage

COMPILATION AND BUILD
Compilation Process
Header Files
Source Files
Linking
Build Systems
- Make
- CMake
Compiler Options

Requested a AI to provide a CPP roadmap to know CPP very thoroughly, and it has provided me this roadmap. Do you have additions? Or is this good for modern CPP?

https://redd.it/1pug6hs
@r_cpp

Is modules thought to work seamlessly with external dependencies using #import

Let's say I want to convert my project to use modules instead of #includes. So I replace every #include <vector> with import <vector>?
What happens with all my external dependencies using #include <vector>?

Does this cause conflicts in some way, or does it work seamlessly?



https://redd.it/1q1ekad
@r_cpp

MayaFlux 0.1.0: A Digital-Native Substrate for Multimedia Computation

Hello r/cpp folks,

I am very excited to announce the initial release of my new creative multimedia programming framework. Here is a short release text, you can find the full context on the [website](https://mayaflux.org/releases/)

MayaFlux 0.1.0 is a C++20/23 infrastructure built to replace the 1980s-era architectures still underlying modern creative coding tools. Built with 15 years of interdisciplinary practice and DSP engineering, it departs from the "analog metaphors" that have constrained digital creativity since the 1980s. MayaFlux does not simulate oscillators or patch cables; it processes unified numerical streams through lock-free computation graphs.

## The Death of Analog Metaphor

Traditional tools (DAWs, visual patchers) rely on legacy pedagogical metaphors. MayaFlux rejects these in favor of computational logic. In this framework, **audio, visuals, and control data are identical.** Every sample, pixel, and parameter is a double-precision floating-point number. This eliminates the artificial boundaries between domains. A single unit can output audio, trigger GPU compute shaders, and coordinate temporal events in the same processing callback without conversion overhead.

## Technical Core: Lock-Free & Deterministic

Building on C++20, MayaFlux utilizes `atomic_ref` and compare-exchange operations to ensure thread safety without mutexes. You can restructure complex graphs or inject new nodes while audio plays -> no glitches, no dropouts, and no contentions. The state promise ensures every node processes exactly once per cycle, regardless of how many consumers it has, enabling true multi-rate adaptation (Audio, Visual, and Custom rates) within a unified graph.

## Lila: Live C++ via LLVM JIT

One of MayaFlux's most transformative features is the **Lila JIT system**. Utilizing LLVM 21+, Lila allows for full C++20 syntax evaluation (including templates and `constexpr`) in real-time. There is no "application restart" or "compilation wait." You write C++ code, hit evaluate, and hear/see the results within one buffer cycle. Live coding no longer requires switching to a "simpler" interpreted language; you have the full power of the C++ compiler in the hot path.

## Graphics as First-Class Computation

Unlike tools where graphics are a "visualization" afterthought, MayaFlux treats the **Vulkan 1.3** pipeline with the same architectural rigor as audio DSP. The graphics pipeline shares the same lock-free buffer coordination and node-network logic. Whether you are driving vertex displacement via a recursive audio filter or mapping particle turbulence to a high-precision phasor, the data flow is seamless and low-level.

## Temporal Materiality

By utilizing **C++20 Coroutines**, MayaFlux turns Time into a compositional material. Through the `co_await` keyword, developers can suspend logic on sample counts, frame boundaries, or predicates. This eliminates "callback hell" and allows temporal logic to be written exactly how it is imagined: linearly and deterministically.

## Who is it for?

MayaFlux is infrastructure, not an application. It is for:

- **Creative Technologists** hitting the limits of Processing or Max/MSP.
- **Researchers** needing direct buffer access and novel algorithm implementation.
- **Developers** seeking low-level GPU/Audio control without framework-imposed boundaries.

The substrate is ready. Visit **mayaflux.org** to start sculpting data.

## A quick teaser

```cpp
#pragma once
#define MAYASIMPLE
#include "MayaFlux/MayaFlux.hpp"

void settings() {
// Low-latency audio setup
auto& stream = MayaFlux::Config::get_global_stream_info();
stream.sample_rate = 48000;
}

void compose() {

// 1. Create the bell
auto bell = vega.ModalNetwork(
12,
220.0,
ModalNetwork::Spectrum::INHARMONIC)[0]
| Audio;

// 2. Create audio-driven logic
auto source_sine = vega.Sine(0.2, 1.0f); // 0.2 Hz slow oscillator

static double last_input = 0.0;
auto

MayaFlux 0.1.0: A Digital-Native Substrate for Multimedia Computation

Hello r/cpp folks,

I am very excited to announce the initial release of my new creative multimedia programming framework. Here is a short release text, you can find the full context on the [website](https://mayaflux.org/releases/) or the [git repo](https://github.com/MayaFlux/MayaFlux)

MayaFlux 0.1.0 is a C++20/23 infrastructure built to replace the 1980s-era architectures still underlying modern creative coding tools. Built with 15 years of interdisciplinary practice and DSP engineering, it departs from the "analog metaphors" that have constrained digital creativity since the 1980s. MayaFlux does not simulate oscillators or patch cables; it processes unified numerical streams through lock-free computation graphs.

# The Death of Analog Metaphor

Traditional tools (DAWs, visual patchers) rely on legacy pedagogical metaphors. MayaFlux rejects these in favor of computational logic. In this framework, **audio, visuals, and control data are identical.** Every sample, pixel, and parameter is a double-precision floating-point number. This eliminates the artificial boundaries between domains. A single unit can output audio, trigger GPU compute shaders, and coordinate temporal events in the same processing callback without conversion overhead.

# Technical Core: Lock-Free & Deterministic

Building on C++20, MayaFlux utilizes `atomic_ref` and compare-exchange operations to ensure thread safety without mutexes. You can restructure complex graphs or inject new nodes while audio plays -> no glitches, no dropouts, and no contentions. The state promise ensures every node processes exactly once per cycle, regardless of how many consumers it has, enabling true multi-rate adaptation (Audio, Visual, and Custom rates) within a unified graph.

# Lila: Live C++ via LLVM JIT

One of MayaFlux's most transformative features is the **Lila JIT system**. Utilizing LLVM 21+, Lila allows for full C++20 syntax evaluation (including templates and `constexpr`) in real-time. There is no "application restart" or "compilation wait." You write C++ code, hit evaluate, and hear/see the results within one buffer cycle. Live coding no longer requires switching to a "simpler" interpreted language; you have the full power of the C++ compiler in the hot path.

# Graphics as First-Class Computation

Unlike tools where graphics are a "visualization" afterthought, MayaFlux treats the **Vulkan 1.3** pipeline with the same architectural rigor as audio DSP. The graphics pipeline shares the same lock-free buffer coordination and node-network logic. Whether you are driving vertex displacement via a recursive audio filter or mapping particle turbulence to a high-precision phasor, the data flow is seamless and low-level.

# Temporal Materiality

By utilizing **C++20 Coroutines**, MayaFlux turns Time into a compositional material. Through the `co_await` keyword, developers can suspend logic on sample counts, frame boundaries, or predicates. This eliminates "callback hell" and allows temporal logic to be written exactly how it is imagined: linearly and deterministically.

# Who is it for?

MayaFlux is infrastructure, not an application. It is for:

* **Creative Technologists** hitting the limits of Processing or Max/MSP.
* **Researchers** needing direct buffer access and novel algorithm implementation.
* **Developers** seeking low-level GPU/Audio control without framework-imposed boundaries.

The substrate is ready. Visit **mayaflux.org** to start sculpting data.

# A quick teaser
```cpp
#pragma once
#define MAYASIMPLE
#include "MayaFlux/MayaFlux.hpp"

void settings() {
// Low-latency audio setup
auto& stream = MayaFlux::Config::get_global_stream_info();
stream.sample_rate = 48000;
}

void compose() {

// 1. Create the bell
auto bell = vega.ModalNetwork(
12,
220.0,
ModalNetwork::Spectrum::INHARMONIC)[0]
| Audio;

// 2. Create

No compiler implements std linalg

Tested in visual 2026 with std latest and several other compilers in godbolt with the appropriate c++2026 or latest options, no one accepts #include <linalg>. Did I miss something or no compiler does implement std linalg yet ? (Out of curiosity, as it's really not urgent, it's not like blas/lapack etc are not around since decades.)

https://redd.it/1q6myiw
@r_cpp

C++26 Reflection: Autocereal - Use the Cereal Serialization Library With Just A #include (No Class Instrumentation Required)

I ran this up to show and tell a couple days ago, but the proof of concept is much further along now. My goal for this project was to allow anyone to use Cereal to serialize their classes without having to write serialization functions for them. This project does that with the one exception that private members are not being returned by the reflection API (I'm pretty sure they should be,) so my private member test is currently failing. You will need to friend class cereal::access in order to serialize private members once that's working, as I do in the unit test.


Other than that, it's very non-intrusive. Just include the header and serialize stuff (See the Serialization Unit Test Nothing up my sleeve.


If you've looked at Cereal and didn't like it because you had to retype all your class member names, that will soon not be a concern. Writing libraries is going to be fun for the next few years!

https://redd.it/1qq2npd
@r_cpp

P1689's current status is blocking module adoption and implementation - how should this work?

There is a significant "clash of philosophies" regarding Header Units in the standard proposal for module dependency scanning P1689 (it's not standard yet because it doesn't belong to the language standard and the whole ecosystem is thrown to trash by now but it's de facto) that seems to be a major blocker for universal tooling support.

# The Problem

When scanning a file that uses header units, how should the dependency graph be constructed? Consider this scenario:

// a.hh
import "b.hh";

// b.hh
// (whatever)

// c.cc
import "a.hh";

When we scan c.cc, what should the scanner output?

Option 1: The "Module" Model (Opaque/Non-transitive) The scanner reports that c.cc requires a.hh. It stops there. The build system is then responsible for scanning a.hh separately to discover it needs b.hh.

Rationale: This treats a header unit exactly like a named module. It keeps the build DAG clean and follows the logic that `import` is an encapsulated dependency.

Option 2: The "Header" Model (Transitive/Include-like) The scanner resolves the whole tree and reports that `c.cc` requires both `a.hh` and `b.hh`.

Rationale: Header units are still headers. They can export macros and preprocessor state. Importing a.hh is semantically similar to including it, so the scanner should resolve everything as early as possible (most likely using traditional -I paths), or the impact on the importing translation unit is not clear.

# Current Implementation Chaos

Right now, the "Big Three" are all over the place, making it impossible to write a universal build rule:

1. Clang (clang-scan-deps): Currently lacks support for header unit scanning.
2. GCC (-M -Mmodules): It essentially deadlocks. It aborts if the Compiled Module Interface (CMI) of the imported header unit isn't already there. But we are scanning specifically to find out what we need to build!
3. MSVC: Follows Option 2. It resolves and reports every level of header units using traditional include-style lookup and aborts if the physical header files cannot be found.

# The Two Core Questions

1. What is the scanning strategy? Should import "a.hh" be an opaque entry as it is in the DAG, or should the scanner be forced to look through it to find b.hh?

2. Looking-up-wise, is import "header" a fancy #include or a module?

If it's a fancy include: Compilers should use `-I` (include paths) to resolve them during the scan. Then we think of other ways to consume their CMIs during the compilation.
If it's a module: They should be found via module-mapping mechanics (like MSVC's /reference or GCC's module mapper).

# Why this matters

We can't have a universal dependency scanning format (P1689) if every compiler requires a different set of filesystem preconditions to successfully scan a file, or if each of them has their own philosophy for scanning things.

If you are a build system maintainer or a compiler dev, how do you see this being resolved? Should header units be forced into the "Module" mold for the sake of implementation clarity, or must we accept that they are "Legacy+" and require full textual resolution?

I'd love to hear some thoughts before this (hopefully) gets addressed in a future revision of the proposal.

https://redd.it/1qx7zex
@r_cpp

"override members" idea as a gateway to UFCS (language evolution)

(UFCS backgrounder: https://isocpp.org/files/papers/N4174.pdf )

I have two functions that tell me if a string contains the
characters of a particular integer. They're called hasInt and intIn.
(intIn is inspired by the python keyword in.)
They looks like this:

bool hasInt(const string s, int n)// does s have n?
{
return s.contains(tostring(n));
}

bool intIn(int n, const string s)// is n in s?
{
return s.contains(tostring(n));
}

It would be convenient if I could add hasInt as a member function to std::string:

bool string::hasInt(int n)
{
return ::hasInt(this, n);
}

Then I could use "member syntax" to call the function, like `text.hasInt(123)`.

Of course, that's not possible, because then I'd be changing the header files
in the standard libraries.

Here's an idea for a new language feature:
let's use the `override` keyword to allow us to "inject" member functions
into an existing class, without modifying the class definition. So the code:

override bool string::hasInt(int n)
{
return ::hasInt(this, n);
}

will (in effect) add hasInt as a member function to string.

Thus, this "override member function" feature has a syntax like:

ReturnType ClassName::function(args){...etc...}

HOWEVER..... what if ClassName doesn't necessarily need to be a class, and could be
other types? Then you open the door to override members like:

override bool int::intIn(const string s)
{
return ::intIn(this, s);
}

Which allows code like `(123).intIn(text)`.

This is halfway to UFCS!

Using some macro magic and helper templates, we could define a
MAKE_UFCS macro to convert a non-member function into a member function:

#define MAKE_UFCS(f) \
override \
retType(f) argType1(f)::f(argType2(f) x)\
{ \
return f(this, x); \
}

Thus the non-member functions hasInt and intIn could be "opted in" to UFCS
by the macro calls:

MAKEUFCS(hasInt);
MAKEUFCS(intIn);

Or maybe, if this override-to-UFCS is useful enough, the override feature can be
applied to a collection of functions at once, like:

override hasInt, intIn;

or

override {
#include <cstdlib>
}

To UFCS-ify an entire header file at the same time.

EDIT: this idea would be similar to Scala's "Extension Methods": https://docs.scala-lang.org/scala3/book/ca-extension-methods.html

or C#'s "Extension Members": https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods

https://redd.it/1qyikcg
@r_cpp