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

MigrationManager::GetInstance();
manager.CreateMigrationHistory();
size_t applied = manager.ApplyPendingMigrations();
```

Supports rollbacks, dry-run preview, checksum verification, and distributed locking for safe concurrent deployments.

---

## Backup & Restore

Full database backup/restore with progress reporting:

```cpp
#include <Lightweight/SqlBackup.hpp>

// Backup to compressed archive (multi-threaded)
SqlBackup::Backup(
"backup.zip",
connectionString,
4, // concurrent workers
progressManager,
"", // schema
"*", // table filter (glob)
{}, // retry settings
{ .method = CompressionMethod::Zstd, .level = 6 }
);

// Restore
SqlBackup::Restore("backup.zip", connectionString, 4, progressManager);
```

Preserves indexes, foreign keys (including composite), and supports table filtering.

---

## Supported Databases

- Microsoft SQL Server
- PostgreSQL
- SQLite3

Works anywhere ODBC works (Windows, Linux, macOS).

---

## What's Next

We're actively developing and would love feedback. The library is production-ready for our use cases, but we're always looking to improve the API and add features.

We also consider abstracting away ODBC such that it could support non-ODBC databases like SQLite3 directly without the ODBC layer. That's a longer-term goal, but definitely a goal.

We currently focus on SQL tooling (migrations and backup/restore) as both are quite young additions that are still evolving.

Questions and PRs welcome!

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

Corosio Beta - coroutine-native networking for C++20

We are releasing the Corosio beta - a coroutine-native networking library for C++20 built by the C++ Alliance. It is the successor to Boost.Asio, designed from the ground up for coroutines.

**What is it?**

Corosio provides TCP sockets, acceptors, TLS streams, timers, and DNS resolution. Every operation is an awaitable. You write co\_await and the library handles executor affinity, cancellation, and frame allocation. No callbacks. No futures. No sender/receiver.

It is built on Capy, a coroutine I/O foundation that ships with Corosio. Capy provides the task types, buffer sequences, stream concepts, and execution model. The two libraries have no dependencies outside the standard library.

**An echo server in 45 lines:**

#include <boost/capy.hpp>
#include <boost/corosio.hpp>

namespace corosio = boost::corosio;
namespace capy = boost::capy;

capy::task<> echo_session(corosio::tcp_socket sock)
{
char buf[1024];
for (;;)
{
auto [ec, n] = co_await sock.read_some(
capy::mutable_buffer(buf, sizeof(buf)));

auto [wec, wn] = co_await capy::write(
sock, capy::const_buffer(buf, n));

if (ec)
break;
if (wec)
break;
}
sock.close();
}

capy::task<> accept_loop(
corosio::tcp_acceptor& acc,
corosio::io_context& ioc)
{
for (;;)
{
corosio::tcp_socket peer(ioc);
auto [ec] = co_await acc.accept(peer);
if (ec)
continue;
capy::run_async(ioc.get_executor())(echo_session(std::move(peer)));
}
}

int main()
{
corosio::io_context ioc;
corosio::tcp_acceptor acc(ioc, corosio::endpoint(8080));
capy::run_async(ioc.get_executor())(accept_loop(acc, ioc));
ioc.run();
}

**Features:**

* Coroutine-only - every I/O operation is an awaitable, no callbacks
* TCP sockets, acceptors, TLS streams, timers, DNS resolution
* Cross-platform: Windows (IOCP), Linux (epoll), macOS/FreeBSD (kqueue)
* Type-erased streams - write any\_stream& and accept any stream type. Compile once, link anywhere. No template explosion.
* Zero steady-state heap allocations after warmup
* Automatic executor affinity - your coroutine always resumes on the right thread
* Automatic stop token propagation - cancel at the top, everything below stops Buffer sequences with byte-level manipulation (slice, front, consuming\_buffers, circular buffers)
* Concurrency primitives: strand, thread\_pool, async\_mutex, async\_event, when\_all, when\_any Forward-flow allocator control for coroutine frames
* C++20: GCC 12+, Clang 17+, MSVC 14.34+

**Get it:**

git clone https://github.com/cppalliance/corosio.git
cd corosio
cmake -S . -B build -G Ninja
cmake --build build

No dependencies. Capy is fetched automatically.

Or use CMake FetchContent in your project:

include(FetchContent)
FetchContent_Declare(corosio
GIT_REPOSITORY https://github.com/cppalliance/corosio.git
GIT_TAG develop
GIT_SHALLOW TRUE)
FetchContent_MakeAvailable(corosio)
target_link_libraries(my_app Boost::corosio)

**Links:**

* Corosio: [https://github.com/cppalliance/corosio](https://github.com/cppalliance/corosio)
* Corosio docs: [https://develop.corosio.cpp.al/](https://develop.corosio.cpp.al/)
* Capy: [https://github.com/cppalliance/capy](https://github.com/cppalliance/capy)
* Capy docs: [https://develop.capy.cpp.al/](https://develop.capy.cpp.al/)

**What’s next:**

HTTP, WebSocket, and high-level server libraries are in development on the same foundation. Corosio is heading for Boost formal review. We want your feedback.

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

Modern declarative EDSL for graphic user interface in C++? Not QML or XAML.

Hello everyone,

I have been investigating lately (after using NiceGUI for a real project) and learning Jetpack Compose (not writing any real code with it, would do it with Jetpack Multiplatform if ever).

I am really impressed by Jetpack Compose approach, especially UDF.

I thought there could possibly not be a better way than MVVM tbh, after using it for years.

But after seeing how declarative composition inside the language, not with XAML or QML can be done, I am sold in the amount of boilerplate that can be saved, plus the better integration when the dsl is in the host language.

So I wanted to mention I found this, which I think could be a good start for some experiments, on top of wxWidgets: https://github.com/rmpowell77/wxUI

I think it has a talk in CppCon2025 here: https://www.youtube.com/watch?v=xu4pI72zlO4

Kudos to the author for bringing something like this to C++! Definitely useful.

I would like to hear your opinions on this style of EDSL GUI embedding and pros/cons you find for those of you who do GUI programming all the time.

Also, wild idea: with the power of compile-time C++ programming and C++26 reflection, it would be possible to get existing xaml interfaces and convert it into regular C++ at compile-time via #embed or #include and not even changing the EDSL itself and making it directly embedded and reusable in C++? That would be plenty useful.


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

C++26: Structured bindings in conditions
https://www.sandordargo.com/blog/2026/04/15/cpp26-structured-bindings-condition

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

I built a C++ integer-to-string library based on a new AVX-512 paper

I built a small C++ integer-to-string conversion library based on a new paper by Jael Champagne Gareau and Daniel Lemire, "Converting an Integer to a Decimal String in Under Two Nanoseconds":

- Project: https://github.com/simditoa/simditoa
- Paper: https://arxiv.org/abs/2604.26019

The paper looks at decimal formatting for integers, which shows up in logging, JSON/CSV/XML serialization, database output, and other places where numbers eventually become text. The interesting part, and the part I wanted to experiment with, is that it uses AVX-512 IFMA instructions to extract multiple decimal digits in parallel, avoiding the usual repeated division/modulo loop and avoiding large lookup tables.

The library exposes a small to_chars-style API:

#include "simditoa.h"

char buf[simditoa::MAX_DIGITS + 1];
size_t len = simditoa::to_chars(12345, buf);
buf[len] = '\0';

Current project shape:

- C++17
- int64_t and uint64_t support
- AVX-512 IFMA + VBMI path for supported x86-64 CPUs
- portable scalar fallback
- CMake package/install support
- tests for edge cases, digit lengths, and randomized values
- a simple benchmark against std::to_chars

The README benchmark currently shows simditoa::to_chars at about 15.82 ns/int versus 36.35 ns/int for std::to_chars on the tested setup, roughly 2.3x faster in that run. The paper reports stronger results for its full algorithm and benchmark suite, including single-core performance ahead of other tested methods, but my repo should be treated as a compact implementation based on the paper rather than a full reproduction of every variant in it.

The core trick is neat: for 8-digit chunks, it uses AVX-512 IFMA with precomputed constants based on floor(2^52 / 10^k) to compute digit positions in parallel, then gathers the digit bytes with AVX-512 byte permutation. Larger values are split into chunks.


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