Coder Legion - Recent posts tagged cpp

Tuesday Coding Tip 27 — Aliasing and ‘using’ in C++

Tue, 20 Oct 2026 09:59:00 +0000

Tuesday coding tips are super short posts about various tidbits mainly from C++, but also from other programming languages I use. You can also follow the #TuesdayCodingTips hashtag on Mastodon and Linkedin.

Every hello world tutorial starts with the command using namespace std;. This command is dangerous as it allows you to bring all standard symbols into your namespace where they can collide with your own symbols. Depending on the kind of collision, the compiler might not tell you, nor can you be sure which version will be used.

#include <stdexcept>

int min(int a, int b)
{
    std::terminate();
}

#include <cmath>

int main() {
    using namespace std; // dangerous
    // better to import specific names like:
    using std::max;

    return min(10, 20); // which min will be called?
    // ::min would disambiguate to the local function
    // std::min would disambiguate to standard
}

It is better to use the using keyword to selectively bring symbols into the scope or even alias them to be sure they’re unique (note that namespaces alias differently).

#include <filesystem>

// Aliasing namespace works differently
namespace fs = std::filesystem;

// from aliasing classes
using Path = fs::path;

bool fileExists(const Path& path)
{
    return fs::exists(path);
}

The keyword can also be used to expose class template parameters for common usage.

template<class T>
class Foo {
public:
    // Exposing template type saves time
    // to those who need to get to it
    using DataType = T;

    T getItem() const { return T{}; }
};

int main() {
    Foo<int> foo;
    decltype(foo)::DataType item;
    item = foo.getItem();
}

And since C++20, you can bring enum values (selectively or in group) for better ergonomics in enum-based branching.

enum class EmployeeType {
    JuniorDev,
    MediorDev,
    SeniorDev,
    ScrumMaster,
    ProductManager
};

std::string to_string(EmployeeType et) {
    switch (et)
    {
        using enum EmployeeType; // Since C++20
        case JuniorDev: return "junior";
        case MediorDev: return "medior";
        // ...
    }
}

std::string to_string(EmployeeType et) {
    using EmployeeType::JuniorDev;

    if (et == JuniorDev) return "junior";
    // ...
}

The missing break behind Digimon World’s evolution rules

Fri, 16 Oct 2026 19:39:38 +0000

title: The missing break behind Digimon World’s evolution rules
published: true
description: Digimon World’s decompiled evolution code reveals a four-point scoring system, a surprising tie-break rule, and a path toward a PC port.

tags: reverseengineering, c, gamedev, cpp

You fed it, trained it, cleaned up after it. You had a plan. Then it evolved into Numemon, a walking pile of sludge, and the game never told you why.

No menu. No hint. No stat screen saying here is what went wrong.

Players filled that silence with wikis, calculators and arguments about whether care mistakes helped or hurt. They inferred the rules from what happened on screen. Now we can read the code.

The Digimon World decompilation project has reconstructed the evolution code. One rule comes from a loop with no break: when several stats share the highest value, the game picks the last one in its array.

Here is how the scoring works, what that tie means, and what I learned while testing a small PC port prototype.

The missing break

Here is the real code that picks which of your stats the game examines. It's in src/main/evolution.c, and it runs over the six stats hp, mp, offense, defense, speed, brain:

for (i = 0; i < 6; i++) {
  int8_t isHighestStat = 1;
  for (j = 0; j < 6; j++) {
    if (statsArray[i] < statsArray[j])
      isHighestStat = 0;
  }
  if (isHighestStat == 1)
    highestStat = i;
}

For six stats, the nested loop is cheap. But look at what is missing: there is no break after the assignment. The loop keeps going after it finds a maximum, so a later tied stat overwrites an earlier one. When stats tie, the highest index wins.

I ran the same selection logic with a few inputs:

all six tied      -> brain
offense highest   -> offense
off+def tied high -> defense
brain highest     -> brain

Reading the array order backwards gives the full tie-break priority: brain > speed > defense > offense > mp > hp.

With all six stats tied, the game selects brain as the highest stat. You could infer this from enough experiments, but the code makes the reason clear. Whether the missing break was intentional is unknown; its effect is observable.

{% card %}
Worth being careful here: I first suspected highestStat was read uninitialized, which would be a genuine bug worth reporting upstream. It can't be — a maximum always exists among six values, so the flag is always set at least once. Check before you claim.
{% endcard %}

The scoring system: four checks, three needed

That tie-break feeds a larger system. Every Digimon has up to six possible evolution targets. For each candidate the game computes a score out of 4, and a candidate needs at least 3 points to be eligible at all. Below 3 it isn't considered.

Here are the four checks.

Care mistakes, and the flag that inverts them

if (isMaxCM == 0) {
  if (partner->careMistakes >= reqs->care)
    reqPoints += 1;
} else if (partner->careMistakes <= reqs->care) {
  reqPoints += 1;
}

Read the comparisons closely. There's a flag bit that reverses the test, so some evolutions want your care mistakes above a threshold.

Neglect isn't a punishment in this game. For certain paths it's a requirement. Care mistakes can therefore help qualify a candidate. Whether that explains any particular Numemon depends on the other checks and available targets.

Weight is a window, not a floor

if (reqs->weight - 5 <= partner->weight &&
    partner->weight <= reqs->weight + 5)
  reqPoints += 1;

A band of ±5 around a target. Overfeeding fails this check exactly as hard as underfeeding. A precise target weight matters because both sides of the window have a limit.

Stats, where the stage changes the rule

if (DIGIMON_DATA[target].level == 3U) {
  /* Champion: only your single HIGHEST stat is examined */
} else {
  /* everything else: ALL six stats must clear their thresholds */
}

Most evolutions need every stat above its requirement. Champion-level targets check only your highest one — which is where the missing break above actually bites. For Champions, one selected highest stat matters; other targets require all six thresholds.

The bonus point: any one of five

if (reqs->digimon    != -1 && current == reqs->digimon) isBonusFulfilled = 1;
if (reqs->discipline != -1 && /* ... */)                isBonusFulfilled = 1;
if (reqs->happiness  != -1 && /* ... */)                isBonusFulfilled = 1;
if (reqs->battles    != -1) { /* also invertible */ }
if (reqs->techs      != -1) { /* mastered moves */ }

Any single one of these grants the fourth point. Battle count carries the same inversion trick as care mistakes: some evolutions want you to have fought fewer than N battles.

The rule that quietly steers your collection

One more piece, and it's the one that made me sit back:

if (reqPoints >= 3 && currentBest != -1) {
  isTargetRaised = hasDigimonRaised(
      EVO_GAINS_DATA[target].targetDigimon);
  isCurrentBestRaised = hasDigimonRaised(
      EVO_GAINS_DATA[currentBest].targetDigimon);

  if (isTargetRaised == 1 && isCurrentBestRaised == 0)
    reqPoints = 0;      /* you already have this one: disqualify it */

  if (isTargetRaised == 0 && isCurrentBestRaised == 1)
    reqPoints++;        /* you don't have this one: push it ahead */
}

The game remembers which Digimon you have raised. When it compares two eligible candidates, this code favours the one you have not raised: it can zero the already-raised candidate’s score or add a point to the new one. The outcome still depends on candidate order and the surrounding selection logic.

It is a small but deliberate way to steer players toward more of the roster.

Who actually did this

I did not decompile the game. I forked the repository, ran parts of its code on a PC, and measured a few pieces a port would need. The decompilation work belongs to its contributors.

{% embed https://github.com/jype0/dw_decomp %}

jype0/dw_decomp started in March 2026 and is MIT licensed. It passed a milestone most decompilation projects never reach: zero INCLUDE_ASM stubs left in src/.

If you haven't worked on a decomp, that needs explaining. INCLUDE_ASM is the marker for "we haven't figured this function out yet, here's the raw assembly instead." Most decomps carry hundreds of them for years. The source tree no longer relies on those assembly placeholders. That milestone alone does not establish that every function matches the retail binary.

Credit isn't evenly spread, and shouldn't be reported as if it were. As of today the contributor counts are:

Contributor	Contributions
Pekka Jylhä-Ollila (jype0)	409 — maintainer, and the bulk of the project
juandav	37 — matching functions and data across overlays
ChonkMode	22
kingzmanh	11
fmil95	7
ThirstyWraith	6
SydMontague	5 — struct and naming reference work
paulohpfilho	4

Those are the repository’s contribution counts at the time I checked, not a measure of each person’s work or proof that every regional build is complete.

I asked about the roadmap in an issue. juandav relayed jype0's four points: clean up the hacks and name things properly; match all 10 regional versions; maybe a PC port, blocked because psyq and psycross don't currently implement libgs or libsnd; and then a DW1 mod of epic proportions — new maps, story, Digimon.

The ambitious mod is the long-term goal. The decompilation makes that work possible.

Running their code somewhere it has never run

My question was narrower: can this code run off the PlayStation at all?

evolution.c is 1,087 lines. Compiling it on x86-64 produced exactly one error:

libgte.h: No such file or directory

That's Sony's geometry coprocessor header. So I grepped evolution.c for VECTOR, MATRIX, gte_, RotTrans — nothing. The evolution logic doesn't touch the GTE at all. It only inherits the header through entity.h.

I wrote type-only stand-ins for the four PsyQ headers. It compiled clean, then ran:

EvoRequirements = 28 bytes (PS1 layout: 28)
fresh(1)       -> 2
in-training(3) -> 5

That 28 matters more than it looks. The game reads its data tables as raw structs, so if the layout shifted by even one byte on a 64-bit host, every evolution requirement in the game would decode as noise. It doesn't, and I pinned it with static_assert so nobody can break it quietly later.

Measuring the GTE instead of guessing at it

A major piece of a PS1 port is the GTE, the fixed-point geometry coprocessor.

My first instinct was to size the problem with a grep. I got 181 and quoted that number publicly. It was wrong — my pattern was matching a header that defines every GTE macro whether the game calls it or not. Measured against src/ alone:

632 call sites, 29 distinct operations, 34 of 126 files

The call sites are concentrated:

Operation	Sites	Cumulative
`ApplyMatrixSV`	103	16%
`RotMatrix`	51	24%
`RotMatrixZYX`	44	31%
`RotMatrixYXZ`	44	38%
`ratan2`	43	45%
`gte_rtps`	42	58%
`ScaleMatrix`	39	71%
`TransMatrix`	37	77%
`ApplyMatrixLV`	23	81%

The nine operations shown account for about 81% of these call sites. That gives a useful starting point, though call-site count does not measure implementation difficulty.

I implemented a software subset covering those common operations. The contract is strict: matrix entries are 1.3.12 fixed point (4096 = 1.0), angles run 4096 to a full turn, and results saturate rather than wrap. That last one isn't optional — a wrapped coordinate throws a vertex to the far side of the screen, which is exactly the class of bug that ships unnoticed.

Then I measured the number that actually decides anything. "0.17% trigonometric error" is a useless statistic; nobody can tell you whether that's visible. So I measured pixels — how far a projected vertex lands from where double-precision maths puts it, across 2,528 vertices and a full rotation sweep:

mean error:             0.825 px
worst error:            1.896 px
vertices off by > 2px:  0.00%

In that test, the error stayed under two pixels. This measures one projection sweep; it does not guarantee every game scene will look the same.

And the honest half: it is not bit-exact. The real GTE uses lookup tables; my polynomial approximation looks identical and is numerically different. That's fine for a port and useless for verifying a decompilation, whose entire premise is reproducing the original binary byte for byte. Confusing those two would be the expensive mistake, so I put the warning in the test output rather than in a comment nobody reads.

{% details Drawing a frame: primitives and the ordering table %}

The game's rendering is all PsyQ primitives, counted across the source:

POLY_FT4  386    (textured quad)
POLY_F4    30
POLY_GT4   17
POLY_FT3    6    (textured triangle)

The two textured primitive types in this excerpt account for 392 call sites, making them a useful first rendering test. I built them with the game's own setXYWH and setUVWH macros lifted from src/main/utils.c, and rasterised them in software.

One thing I deliberately did not fix: the texture mapping is affine, not perspective-correct. The PS1 had no perspective correction, and that wobble is part of how the console looks. Correcting it would make a port feel wrong.

Then the ordering table, which is how the PS1 sorted by depth. The name misleads, so it's worth saying plainly: an ordering table is not a sorting algorithm. It's a bucket array — one slot per depth value, each holding a linked list, with AddPrim pushing to the front. O(1) insertion, zero comparisons. That's how a 33MHz console depth-sorted a scene every frame, and reimplementing it with qsort would be slower and wrong, because the order of equal-depth primitives depends on the original insertion and traversal rules.

I built the occlusion test so it couldn't pass by luck: submit the near quad first, then the far one.

normal:          centre pixel r=16  g=104    (near/green occludes)
depths swapped:  centre pixel r=120 g=16     (far/red now occludes)

Same submission order, opposite result. The table is doing the work, not the sequence of my function calls.

{% enddetails %}

Where I got things wrong

Two corrections, because they're more useful than a clean story.

The GTE count. I said 181 in public. It's 632. I estimated with a grep and then quoted the estimate as a measurement, which is a bad habit and I did it anyway.

A test that failed for the right reason. I asserted the far square would peek out around the near one. It doesn't: the near quad spans x=75..245 and the far one x=123..197, so full occlusion is correct physics and my sampling point was badly chosen. I checked the rendered image before touching any code, which is the only reason I didn't "fix" working code to match a broken expectation.

What this does not prove

One logic file out of 126. I picked evolution.c because it looked dependency-free. Best case, not a representative sample.
The GTE is approximate. 18 of 29 operations unimplemented, and the trig is polynomial rather than table-driven.
No model loading. GsSortObject4 has 42 call sites and walks TMD models. The ordering table is ready for it; the format reader isn't written.
Nothing validated against the retail binary. That needs the MIPS toolchain and a disc image.
The assets are still Bandai's. Models, textures, music, text. A possible distribution model is an engine that requires players to supply their own game data; the legal details would need separate review.

Where my work and jype0's roadmap touch: his stated blocker for a PC port is that psyq and psycross don't implement libgs or libsnd. libgs is one of the four headers I stubbed. I'm not claiming that solves his problem — only that it's the same wall, and it's climbable from at least one side.

What we finally understand

Twenty-five years of wiki edits, spreadsheets and arguments, and the answer is a few hundred lines of C:

3 points of 4 to be eligible at all
Care mistakes and battle counts are invertible — some evolutions want neglect
Weight is a ±5 window — overfeeding fails like starving
Champions check your highest stat only; everything else checks all six
Ties favour the last tied stat in array order, with brain last
Previously raised targets can lose a head-to-head comparison against a new one

Your Numemon had an explanation in the game’s rules. The exact reason in any given run depends on the candidate scores and selection path.

That is what makes the decompilation exciting: the rules are readable and testable. It also gives modders a foundation to build on.

My four experiments live on a branch in my fork. Each runs with one command and needs only gcc, plus libsdl2-dev for the two that draw — no PlayStation toolchain, no disc image.

If you've worked on a decomp: how do you decide when an approximation is good enough to ship in a port, given it can never be good enough to verify a match? The bit-exact line is the part I'm least sure I drew correctly.

I Built a C++ CLI That Hunts Down Secrets Hiding in Your Git History

Wed, 14 Oct 2026 22:57:01 +0000

We've all done it. You commit a .env file by accident, catch it a few commits later, delete it, and breathe a sigh of relief. Except... it's not gone. It's still sitting in your Git history, one git log -p away from anyone who clones the repo.

That's the problem GitHub Secrets Watcher is built to catch.

What it does

GitHub Secrets Watcher is a command-line tool written in modern C++20 that scans your GitHub repositories - public or private (with a token) - and walks back through commit history looking for accidentally committed environment and config files: .env, config.js, and similar patterns that often carry API keys, database credentials, or other secrets.

For every hit, it gives you a direct link to the exact commit where the file appears, so you're not stuck digging through history manually to remediate it.

Importantly, it's strictly read-only. It never modifies, deletes, or rewrites anything in your repositories - it just reports what it finds so you can decide what to do next (rotate the secret, scrub the history, etc.).

Key features

Scans all repos for a given GitHub username, public by default, private too if you pass a token
Walks a configurable depth of commit history across branches
Skips noisy directories like node_modules, .git, and dist
Validates commit hashes before generating links, so you never get a broken URL
Multi-threaded scanning - set the thread count to match your hardware
Three output formats: human-readable text (with color-coded terminal output), JSON, or CSV
Stream-based processing to keep memory usage low even on large histories
Modern, safe filesystem operations: Uses C++20 std::filesystem for all path handling, eliminating platform-specific path issues and improving security
Direct Git integration: Leverages libgit2 for efficient, safe repository operations without spawning subprocesses

Example output

[1/7] Scanning: ccas-website
[INFO] Cloning repository (depth=100)...
[INFO] Scanning history...
[WARN] Found 5 potential environment/configuration files:
     - client/assets/js/config.js
       [LINK] https://github.com/.../blob/c7e0fba.../client/assets/js/config.js

Each finding links straight to the offending commit, so remediation is one click away instead of a history-diving expedition.

Getting started

git clone https://github.com/gerald-mathew/github-secrets-watcher
cd github-secrets-watcher
mkdir build && cd build
cmake ..
make

Then run a scan:

./github_secrets_watcher scan --username YOUR_USERNAME

Add a token for private repos and higher API rate limits:

./github_secrets_watcher scan --username YOUR_USERNAME \
  --token YOUR_PERSONAL_ACCESS_TOKEN --include-private

You can tune the scan with --depth, --max-repos, --threads, --format, --verbose, repo(s) <repo name(s)> and --output.

Why C++20

This isn't a wrapper around git log piped through grep — it uses libcurl for GitHub API calls, libgit2 for direct Git repository access, nlohmann/json for parsing, and C++17 std::filesystem for safe, portable path operations, with modern C++20 features throughout. It builds cleanly with CMake or a provided build script on Linux, macOS, and Windows (via MSYS2).

Try it out

It's MIT-licensed and open source. If you've got repos going back a few years, there's a decent chance something's buried in there that shouldn't be — I'd genuinely be curious what people find.

🔗 github.com/gerald-mathew/github-secrets-watcher

Feedback, issues, and PRs welcome.

Update - Sep 3:

Based on feedback from the community, I’ve replaced the filesystem handling with std::filesystem and am now using libgit2 for Git operations instead of popen. Thanks to @hailiang194 for the suggestions!

I Tried to Build Persistent Compute on an Xbox SSD. The Failed Tests Changed the Architecture.

Mon, 12 Oct 2026 21:54:26 +0000

The Xbox wrote 8 GiB of persistent data.

I still couldn't call the experiment successful.

The bytes were there, but the operation failed because a completely different part of the system had timed out. In another test, the worker correctly refused to allocate more storage even though its configuration technically allowed a much larger workload.

Eventually, the experiment passed. But getting there required much more than writing files to an SSD.

I had to investigate how Xbox processes share resources, build a separate coordination component, introduce a recoverable page store, survive real application restarts, and learn which failures were bugs and which were legitimate platform boundaries.

This is one of the experiments behind XCP that I hadn't explored in the previous articles.

The five-part XCP series ended with the platform becoming open source. This bonus chapter goes back into the original Xbox research to explain how I approached persistent computation inside the Developer Mode sandbox.

The problem wasn't just memory capacity

In the earlier experiments, XCP measured an application memory budget of 5 GiB in one Xbox Series X Developer Mode configuration.

That was useful. It gave us an actual resource boundary for the worker rather than a number inferred from the console's hardware specifications.

But it also raised another question.

What happens when the work I want to execute is larger than the memory I can keep resident?

I wasn't trying to bypass the sandbox or convince the Xbox that its SSD was additional physical RAM.

I wanted to build something different: an execution system that could keep data and completed work in persistent storage, bring bounded pieces into memory, process them, and continue from a valid checkpoint after an interruption.

Before building the storage layer, though, I had another hypothesis to investigate.

Could a second process help?

First, I investigated the Xbox process model

XCP already had a foreground worker capable of running CPU and GPU workloads.

I wanted to understand whether another process inside the same UWP package could perform useful background coordination without consuming the worker's entire resource budget.

The candidate was an out-of-process App Service.

On desktop Windows, creating another process might seem straightforward. On Xbox Developer Mode, I wasn't going to assume that the desktop behavior applied unchanged.

So I started measuring.

The first live probes established that the worker and an auxiliary App Service could run with distinct process and activation identities. They exchanged messages, maintained independent heartbeat activity and retained touched, verified memory during overlapping execution windows.

That was already useful.

But it did not prove that we had discovered a second independent 5 GiB memory budget.

To investigate properly, I built an eleven-phase matrix covering CPU execution, verified GPU execution, simultaneous activity, progressive memory pressure, bidirectional storage visibility, suspension, termination, restart, redeployment and cleanup.

And this is where the testing started getting complicated.

The first failures weren't even storage failures

Worker .150 reached the Xbox but exposed incomplete measurement data. It could report IPC latency summaries, yet the acceptance contract required the underlying distribution, including median, p95 and bidirectional throughput.

There was no legitimate way to reconstruct missing measurements afterward.

So that run remained diagnostic.

Worker .151 produced another interesting failure: 79 of 81 preflight checks passed.

The two failures came from heartbeat validation.

The foreground heartbeat ran at 25 ms intervals. The auxiliary broker used a 100 ms timer. During an approximately 935 ms observation window, the broker produced nine ticks.

The test incorrectly expected 32 because it had reused the foreground count.

The broker wasn't failing to run. Our expectation was wrong.

That candidate stayed failed, and the next version corrected the measurement contract.

Worker .152 passed the preflight, but memory-pressure testing exposed another gap. The Xbox refused a bounded allocation, yet the error didn't carry enough structured information to establish the responsible component, observed headroom, applied reserve and cleanup outcome.

A text error saying that memory allocation failed wasn't sufficient to classify the platform behavior.

Worker .153 added the missing observations.

The completed matrix passed all eleven phases, retaining fourteen actual attempts in its evidence history.

The separate classification step selected Case B: a distinct but resource-limited useful process.

That result changed the design.

I didn't have evidence for a second large compute process. But I had enough evidence for a small coordination service.

That was what I built.

The second process became a coordinator

Instead of creating another general-purpose worker, I gave the auxiliary process a narrower responsibility.

It could participate in lifecycle observation, heartbeat management and storage reservations.

The main worker still controlled execution admission, semantic verification, recovery authorization and final result publication.

This separation mattered because the broker could disappear and restart independently.

A reservation could not simply be assumed valid because some old record said it existed.

The worker had to validate the reservation identity, generation and storage plan before accepting new work.

Worker .154 tested this arrangement on the physical Xbox.

55 of 55 checks passed, with zero violations.

The useful result wasn't more RAM.

It was an operational coordination mechanism on which persistent computation could be built.

Next, I needed storage that could survive failure

Writing a file is easy compared with deciding whether that file represents completed computation.

Imagine a workload producing hundreds of output pages.

The application writes a page, updates some metadata, and then disappears.

After restarting, which pages can be trusted?

Did a page finish writing? Does its recorded hash match the bytes? Was its journal entry committed? Can the computation resume from that point without silently skipping or duplicating work?

For XCP, I built the storage system around content-addressed data and an append-only journal.

Each committed page had an identity derived from its content. The journal recorded ordered transitions, with records linked through hashes.

A page was not considered committed just because its file existed.

The system had to verify the relevant content and metadata before including it in the committed sequence.

Recovery worked from the longest valid committed prefix. Anything beyond that boundary could not silently become trusted state.

That approach allowed the runtime to distinguish a completed checkpoint from bytes left behind by an interrupted operation.

Then I tried breaking it

Worker .155 exercised the page store and recovery system on Xbox.

The tests included truncated journal entries, corrupted hashes, missing pages, incomplete root manifests, conflicting page identities, exhausted quotas, stale reservations and repeated cleanup.

The live campaign also tested recovery after worker restart, auxiliary restart and package redeployment.

One deployment experiment uncovered an unexpected problem.

An in-place installation using the same package version left the application running, but Xbox Network Isolation silently dropped the inbound worker connection.

The correction was not to pretend the storage operation had succeeded.

We used a clean uninstall with application data preserved, reinstalled the exact package, restored connectivity and verified that the committed storage root had survived.

The complete .155 campaign eventually passed 248 of 248 checks.

At this point I had a storage substrate capable of preserving committed data through the tested failure and lifecycle scenarios.

But I still hadn't demonstrated useful persistent computation.

That required the next experiment.

Running computation through persistent storage

For the first workload, I reused an existing XCP test called Provable Worlds.

It produces a deterministic field of 1024 × 1024 unsigned 32-bit values.

The complete result is only 4 MiB.

That may sound small for an SSD experiment, but this test wasn't intended to prove beyond-RAM scale yet.

I wanted to establish that computation could be divided into independently checked units, committed in order, interrupted and resumed correctly.

The field was divided into 256 tiles of 16 KiB each.

Each tile had a known global position in the output. The signed CPU Capsule could compute its bounded portion, and XCP compared that result against the CPU reference.

The runtime used bounded output buffers rather than requiring the complete result to stay resident.

The important condition was that the durable cursor advanced only after a page had been committed successfully.

The first uninterrupted runs passed. Restart failed.

Worker .156 completed two uninterrupted executions.

Then I tested the restart path.

Both real-restart resume attempts failed.

The problem was the reservation lifecycle.

After the foreground interruption, the system attempted to continue using the old coordinator lease. But that lease belonged to the previous activation.

This contradicted what the earlier process-topology experiments had already shown.

Persistent data could survive the interruption.

A live process reservation could not be treated the same way.

So I separated those two concepts.

The committed journal retained its original storage identity and generation. A resumed worker had to obtain a fresh live reservation, with a newer generation, and reauthorize the persisted work before continuing.

Worker .157 implemented that correction.

The test deliberately committed the first 128 tiles, computed the next tile without committing it, and interrupted execution.

After the real restart, the worker verified the committed prefix, skipped those first 128 tiles and computed the remaining 128.

It reproduced the expected final field hash.

The uninterrupted tests, restart/resume path, cleanup and same-package regression checks passed.

XCP admitted that specific bounded persistent-compute capability.

One distinction is worth keeping: the tiled execution used the signed CPU Capsule, not a newly implemented GPU-tiled engine. The existing GPU path was checked separately. Nor did this test demonstrate performance gains from asynchronous I/O overlap.

It demonstrated correct bounded computation and recovery.

Now I wanted to investigate the storage scale.

Eight gigabytes, and another failed experiment

For the scale test, I moved to a different page geometry.

Instead of the 16 KiB computation tiles, the storage characterization used 4 MiB pages.

The target was 8 GiB: exactly 2,048 pages.

I also defined a progression through 256 MiB, 512 MiB, 1 GiB, 2 GiB, 4 GiB and finally 8 GiB.

The data was generated deterministically, with page-specific content, so the test could verify distinct pages without treating a single repeated blob as proof of physical growth.

And there was a safety condition: the operation had to preserve 16 GiB of reported available storage as a reserve.

Then came worker .158.

The worker materialized the full 8 GiB.

But the operation failed.

After more than 163 seconds of storage work, the coordinator attempted to release its reservation using an IPC deadline that had been established at the beginning of the operation.

That deadline was only 30 seconds.

The data had been written, but the protocol could no longer complete the operation correctly.

This was not an accepted result.

I corrected the lease-release timeout handling, added an explicit cleanup path for the failed run and tested again.

Worker .159 successfully committed all 2,048 pages.

The measured seed operation took approximately 164 seconds.

That is an end-to-end operation time, including page generation, hashing, storage and journal work. It isn't a raw SSD throughput benchmark.

But .159 was not the final success either.

The 64 GiB attempt was refused

The broader storage policy allowed much larger declared reservations, so I also tested what happened when the system attempted to continue beyond the 8 GiB seed.

The remaining planned growth was 56 GiB.

The platform-reported filesystem space was nowhere near sufficient for that growth plus the required 16 GiB safety reserve.

The worker returned:

STORAGE_SCALE_PLATFORM_HEADROOM_REFUSED

And crucially, it refused before writing additional data.

The existing workspace remained unchanged. Cleanup subsequently removed the 8 GiB seed and a second cleanup confirmed that the namespace was already absent.

This result did not establish that the Xbox SSD had a 64 GiB limit, or that the entire physical SSD was visible to the application.

The application had observed a much smaller storage filesystem, approximately 32.2 billion bytes of reported capacity in that test.

The configured storage quota was not the same as actual platform capacity.

The refusal was correct.

Instead of trying to force a larger allocation, I froze the demonstrated 8 GiB size as the target for the final characterization.

The result: worker 0.1.160.0

Worker .160 was built and signed as a new exact package and tested on the physical Xbox.

This time, the process completed the full storage lifecycle.

It committed 2,048 distinct 4 MiB pages, totaling 8 GiB, then released the reservation.

I returned to the Xbox Home screen and resumed the worker without power-cycling the console.

The resumed worker obtained a fresh reservation generation, recovered the persisted namespace, reread and rehashed the complete 8 GiB, and committed the ordered root without allocating another storage rung.

A separate verification operation then read the complete data again under another fresh lease and reproduced the same root identity.

Finally, cleanup removed the 2,048 unreferenced blobs and all 8 GiB of their content.

A second cleanup found nothing left to remove.

The complete .160 lifecycle passed its checks.

That was the accepted storage-scale result.

Not 64 GiB. Not the console's full SSD. Not virtual RAM.

Eight GiB of bounded, recoverable, content-verified persistent storage, measured through the actual Xbox worker lifecycle.

What this proves, and what it doesn't

The completed experiments establish two related capabilities.

First, XCP demonstrated a persistent-compute workflow in which deterministic tiled execution could survive a real worker interruption, verify previous committed work and resume without recomputing the valid prefix.

Second, it demonstrated an 8 GiB persistent storage namespace with recovery, full-root verification and cleanup on the physical Xbox.

These were separate tests.

The 4 MiB computation experiment did not prove that an arbitrary dataset larger than RAM could be processed end to end.

The 8 GiB storage experiment did not prove an 8 GiB GPU or CPU workload, transparent paging, unrestricted SSD access or a performance-optimized streaming engine.

In fact, the recorded streaming runtime exposed no measured prefetch/compute overlap advantage. The bounded buffers, ordered commits and recovery path were the capabilities being established.

Combining those pieces into larger real workloads is further engineering work, not something I can claim was already completed.

But the distinction between demonstrated components and future integration doesn't make the result less interesting.

It tells me which parts of the problem are actually solved.

Why the failed tests mattered more than the number

Looking back, there wasn't one dramatic failure.

There were several small, independent ones.

The auxiliary process existed, but didn't prove an independent memory budget.

The heartbeat worked, but the test expected the wrong number of ticks.

Memory pressure produced a refusal, but not enough structured evidence to classify it.

The storage layer survived, but an installation sequence disrupted the worker connection.

Computation succeeded uninterrupted, but couldn't resume under the old lease.

Eight gigabytes were written, but the IPC timeout invalidated the operation.

And a larger storage request was refused because the available space could not satisfy the reserve.

Each result forced a different correction.

Some changed the implementation. Some changed the measurement contract. One changed the resource-topology decision. Another changed the scale we were prepared to claim.

I think this is one of the most interesting aspects of XCP.

It didn't become more capable by assuming the Xbox restrictions were irrelevant.

It became more capable by discovering which capabilities could be combined reliably inside those restrictions.

The result was not a magic way to make SSD behave like RAM.

It was a storage and recovery architecture that allows computation to have a durable history independent of the process that produced it.

The code is now open source

The original Xbox experiments were performed in the historical XCP research environment.

The public repository contains reconstructed reference implementations and the source needed to inspect the design, including:

The distinction between the original historical results and the newly reconstructed development packages remains important.

The public source lets developers inspect and rebuild the relevant components. The historical hardware results belong to their original package versions and evidence records.

Newly reconstructed packages do not automatically inherit those physical-Xbox results. They require their own device validation.

That boundary is explained in the public reconstruction audit.

Beyond the SSD experiment

XCP started as an attempt to make an Xbox Series X a programmable execution target.

The project eventually expanded into a virtual machine, CPU/GPU execution, agent-driven development, a desktop studio and tools for adapting and building software.

The SSD experiments explored another necessary part of that picture.

A useful execution target needs more than the ability to run a program once.

It needs a way to preserve work, recover from interruption and continue under a new execution context without pretending that the old one still exists.

The most valuable result of this experiment wasn't the eight-gigabyte figure by itself.

It was the realization that the lifetime of a computation does not have to be identical to the lifetime of the process executing it.

On this particular Xbox, we demonstrated some concrete parts of that idea.

And as with the rest of XCP, the next meaningful step is to take those capabilities into a more demanding workload and find out where they stop being sufficient.

XCP is open source

GitHub: https://github.com/Daniele-Cangi/xcp-xbox

XCP Studio: https://xcpstudio.com/

How a single 1-bit shift bug stayed hidden in NASA's communication protocol for years.

Sat, 10 Oct 2026 09:03:21 +0000

When developing flight software for spacecraft and rovers, standards are everything.

NASA’s F Prime framework powers autonomous flight control and deep-space telemetry. While analyzing the CFDP (CCSDS File Delivery Protocol) implementation inside F Prime, something in the metadata serialization caught my eye.

According to the official CCSDS 727.0-B-5 standard (Table 5-9): The closure_requested flag is specified at bit position 6 (mask 0x40).

However, inside MetadataPdu.cpp, the serialization code was doing: closure_requested << 7 (masking at bit 7, which is 0x80).

A single-bit discrepancy. In deep-space operations, this meant:

The closure request bit was never set where the CCSDS standard expected it.
If the peer receiver relied strictly on the international specification, transaction closure signals would simply be misinterpreted or dropped.

When I submitted the fix to NASA's repository, Core Maintainer Thomas Boyer-Chammard reviewed it and confirmed: "This seems like a bug that was inherited from the cFS implementation."

The PR (#6143) is now officially tagged as a bug fix in C++/CFDP, passed all automated unit tests and CI suites, and is queued for integration.

The biggest takeaway for me as a systems engineer: Never take legacy codebases for granted—even space-grade frameworks. Always verify against first principles and the raw specification.

PR details: https://github.com/nasa/fprime/pull/6143

Write C++ like it's SQL

Tue, 06 Oct 2026 12:59:20 +0000

A lot of C/C++ developers build complex data structures as if database theory never happened. And then they spend months maintaining pointer contracts that a schema could have made obvious.

Let’s take a graph structure as an example.

A common pattern looks like this:

struct Node;
struct Edge;

struct Node {
    uint32_t id;
    std::vector<Edge*> out_edges;
    void* payload;     // depends on node type
    uint32_t type;
};

struct Edge {
    Node* from;
    Node* to;
    void* payload;     // depends on edge type
    uint32_t type;
};

Looks flexible. In reality, it is a tiny undocumented database with manual referential integrity.Everyone must remember things like:

which Node::type maps to which payload struct
which Edge::type maps to which payload struct
whether payload == nullptr is allowed
who owns node payloads
who owns edge payloads
whether deleting a node invalidates edge payloads
how to serialize pointer graphs without losing meaning

And when requirements change, the whole thing turns into archaeology. Now let’s model the same problem like people who know schemas exist.

Start with identity:

using NodeId = uint32_t;
using EdgeId = uint32_t;

Then the core tables:

struct NodeRow {
    NodeId id;
};

struct EdgeRow {
    EdgeId id;
    NodeId from;
    NodeId to;
};

That alone already gives you something huge:

edges are explicitly relations between nodes
serialization is trivial
deletion rules can be formalized
validation is possible

Now add typed data associated with nodes:

struct TransformNode {
    NodeId node;
    float x, y, z;
};

struct LabelNode {
    NodeId node;
    std::string text;
};

struct ColorNode {
    NodeId node;
    uint8_t r, g, b, a;
};

And typed data associated with edges:

struct WeightEdge {
    EdgeId edge;
    float weight;
};

struct CapacityEdge {
    EdgeId edge;
    uint32_t max_flow;
};

struct StyleEdge {
    EdgeId edge;
    uint32_t line_style;
};

Now the model tells the truth.

A node may have a transform, or a label, or both, or neither. An edge may have a weight, a capacity, or some other attribute. No void*. No “if type == 3 cast to Foo”. No comment-based schema.

Need multiplicity rules?

Make them explicit:

one TransformNode row per node
zero or one WeightEdge row per edge
many LabelNode rows if your model allows multilingual labels
no EdgeRow may reference missing nodes

That is database thinking.

And it buys you real benefits even in plain C++:

strong typing instead of tribal knowledge
explicit foreign keys instead of raw pointers
easy serialization
easy validation
better data locality with arrays of records
queryable structure

Examples of useful queries:

find all edges whose to node is missing a transform
find all nodes with outgoing edges but no label
find all weighted edges crossing between two node groups
find dangling relations after a delete
find all data attached to a given node or edge

Try doing that cleanly in a pointer soup.

This is why I keep saying:

Many C/C++ codebases are just badly normalized databases with manual
memory management.

The irony is that game developers already stumbled into one good answer:

ECS. (or Entity-Component-System)

Entities are IDs. Components are typed tables. Systems are queries.

That idea is not limited to games. Graphs, CAD tools, compilers, pipelines, simulation systems, scene graphs, workflow engines — all of them can benefit from the same data-first thinking.

The real lesson is simple:

Before you design your structs like a C programmer, design your data
like a database engineer. Then make it fast like a systems programmer.

“Nice theory… but won’t this be slow?”

That’s the first reaction when you suggest modeling C++ data like a database. Fair question. Also mostly wrong.

Let’s take the graph model from the previous post and talk about how you actually make it fast.

First mistake people imagine:

“Tables + IDs = like SQL = slow joins”

No. You are not building a database engine. You are building arrays with structure.

Storage: SoA beats pointer soup
Instead of scattered heap objects:

Node* -> Edge* -> Node* -> payload*

You store dense arrays:

std::vector<NodeRow> nodes;
std::vector<EdgeRow> edges;
std::vector<TransformNode> transforms;
std::vector<WeightEdge> weights;

Now:

sequential memory
predictable access
prefetch-friendly
no pointer chasing

This alone often wins before you optimize anything else.

Aside of pure performance the inspection and debugging of such data organization is way simpler than chasing void* pointer soup.

IDs are cheaper than pointers (in practice)
A pointer graph:

random memory access
poor cache locality
hard to batch

An ID-based graph:

NodeId -> index lookup -> contiguous data

Yes, you pay an indirection. But you remove cache misses. On modern CPUs, that’s usually a net win.

“Joins” are just loops
Example:

find all edges with weights where from node has a transform

You don’t need SQL.

You do:

for (auto& w : weights) {
    auto& edge = edges[w.edge];
    if (has_transform[edge.from]) {
        // process
    }
}

That’s it.

no virtual dispatch
no pointer casting
no branching on “type”
no cache-miss lottery

Just tight loops over arrays. Eventually you may even come up with an idea of implementing a language integrated query (LINQ) framework.

Build indices where needed
If something is frequent, index it:

std::vector<std::vector<EdgeId>> edges_from_node;

or:

std::unordered_map<NodeId, TransformNode>

or even better:

sorted vectors + binary search
dense bitsets
sparse sets

You choose the structure per access pattern. Not everything needs to be O(1). Everything needs to be predictable.

Optional data without branching hell
Instead of:

if (node->payload && node->type == TRANSFORM)

You use:

presence in table
or a bitset mask

if (has_transform[node_id]) { ... }

Branch becomes predictable. Data becomes separate. Code becomes honest.

Memory management becomes trivial
Pointer model:

who owns what?
who deletes what?
what invalidates what?

Table model:

vectors own memory
IDs stay stable (or use handles/generations)
bulk free is trivial - serialization is dump-and-load, computing diffs is trivial (multiplayer game state synchronization anyone?)

You stop fighting lifetime bugs.

You can still go “full performance mode”
Nothing stops you from:

struct-of-arrays layouts
SIMD over columns
chunking (archetypes like ECS)
custom allocators / arenas
memory mapping
compression of columns

In fact, this model makes those optimizations easier, not harder.

The uncomfortable truth
Pointer-heavy designs feel “low level”. But they often produce:

worse cache behavior
harder reasoning
fragile invariants
slower real-world performance

Because modern performance is not about pointer flexibility. It’s about data layout and predictability.

The mental shift
Stop thinking:

“What does this object point to?”

Start thinking:

“Where does this fact live, and how do I iterate it efficiently?”

Database-style modeling is not about SQL.

It’s about:

explicit structure
normalized data
predictable access

And that’s exactly what high-performance C++ needs. Next time you reach for *void + enum** …ask yourself: Am I designing a data structure?
Or quietly building a database without admitting it?

Database-style modeling is powerful in C++. But it is not always the right tool. This matters, because every good idea becomes harmful when people turn it into a religion.
So when should you not model everything as tables + IDs?

When behavior matters more than data
Sometimes the central thing is not “what facts exist?”
Sometimes the central thing is:

“What operation should this object perform?”

Example:

struct Shape {
    virtual float area() const = 0;
    virtual void draw(Renderer&) const = 0;
};

If you have a small, stable set of objects with rich behavior, polymorphism may be cleaner than forcing everything into component tables.

A table model is great for querying data. An object model is often better for encapsulating behavior.

When the hierarchy is real and stable
If your domain naturally has a closed hierarchy:

Circle
Rectangle
Triangle

Then std::variant can be excellent:

using Shape = std::variant<Circle, Rectangle, Triangle>;

No void*. No fake database. No dynamic allocation required. Just a type-safe tagged union.
This is much better than pretending every tiny hierarchy needs an ID table.

When object identity is not important
Tables shine when identity and relationships matter. But not everything has identity.

A Vec3, Color, Matrix, Rect, Range, or BoundingBox is usually just a value. Do not give every value object an ID. That way lies madness.

Sometimes the right model is simply:

struct Color {
    uint8_t r, g, b, a;
};

Not every struct is secretly a table row.

When the data is tiny and local
If a structure is:

small
short-lived
private to one algorithm
not serialized
not shared across systems

Then simple direct structs are often best.
Example:

struct Candidate {
    float score;
    uint32_t index;
};

No schema needed. No registry. No component store.
Just code.

When traversal is the whole point
Some structures are naturally pointer-shaped.
Examples:

intrusive linked lists
trees with parent pointers
arena-allocated AST nodes
graph algorithms optimized around adjacency

A table representation can still work, but it may not be worth the extra ceremony.
If the dominant operation is “walk this exact shape,” direct references can be perfectly reasonable.
The mistake is not using pointers. The mistake is using pointers as an undocumented schema.

When lifetime is simple and ownership is obvious
If ownership is clear:

std::unique_ptr<Node> root;

and the whole structure dies together, then a pointer graph may be fine.
Especially with arenas.
A compiler AST is a good example:

build it
analyze it
maybe transform it
destroy it all at once

That can be simple and fast.

When the abstraction boundary is behavior-based
Sometimes the whole point is to hide the implementation.

Example:

struct StorageBackend {
    virtual void write(std::span<const std::byte>) = 0;
    virtual std::vector<std::byte> read(Key) = 0;
};

You do not want callers reaching into tables here.
You want an interface.
Data-first design is not an excuse to destroy encapsulation.

So what is the rule?
Use table/ID/database-style modeling when:

identity matters
relationships matter
serialization matters
validation matters
many systems touch the same data
the model evolves over time

Use object/value/polymorphic design when:

behavior matters more than relationships
data is local
hierarchy is small and stable
ownership is simple
encapsulation matters more than introspection

The real enemy is not OOP. The real enemy is informal contracts.
*void + enum + comment** is not a design pattern.
It is a schema that gave up.

Good C++ is not “always objects.” Good C++ is not “always tables.”
Good C++ is choosing the representation that makes illegal states hard, common operations fast, and future maintenance survivable.

Tuesday Coding Tip 25 — User-defined literals

Tue, 06 Oct 2026 09:59:00 +0000

C++ has many built-in literals for disambiguating types of constants, such as u for unsigned, f for float, or time-related literals from the chrono header (like ms, h, or min).

The really cool thing is that you can define your own literals (since C++11) to make your domain-specific constants more legible. All these literals overload the operator“” with your custom _suffix. The data type that is supposed to be before _suffix is then determined by the function parameter type (consult the documentation for allowed parameter types: https://en.cppreference.com/w/cpp/language/user_literal ).

Thanks to compile-time computing, these literals don’t have to imply any runtime overhead for your code.

// Language-provided literals
const auto foo = 100u; // implies unsigned int
const auto bar = 10.f; // implies float instead of double

// Library-provided literals
#include <chrono>
using namespace std::literals;

const auto baz = "hello"s; // implies std::string instead of const char*
constexpr auto day = 14d; // If the value > 255, then the stored value is unspecified. 
constexpr auto twoDays = 48h;
constexpr auto week = 24h* 7;
constexpr auto my_duration_unit = 108ms;
constexpr auto theYear = 2021y;

An interesting use-case that I found is that literals can be leveraged to make described bool constants without having to wrap them in a temporary.

// Literal that describes a constant in pixel units
[[nodiscard]] consteval unsigned long long operator""_px(unsigned long long value) {
    return value;
}

const auto SCREEN_WIDTH = 1280_px;

#include <cstddef>

[[nodiscard]] consteval bool operator""_false(const char*, std::size_t) {
    return false;
}

[[nodiscard]] consteval bool operator""_true(const char*, std::size_t) {
    return true;
}

foo("isWindowOpen"_true, "isFullscreen"_false);

Semantic Search in C++ without Python, libtorch or ONNX Runtime

Wed, 30 Sep 2026 21:39:52 +0000

title: Semantic Search in C++ without Python, libtorch or ONNX Runtime
published: true
description: Run a transformer model from C++ in four commands. No libtorch, no ONNX Runtime, no Python, no model conversion. Works from C++11 upward.
tags: cpp, machinelearning, rust, opensource

canonical_url: https://kjarni.ai/blog/cppinference/

Ask how to run a transformer model from C++ and you get two answers: link libtorch, or convert the model and link ONNX Runtime. Both work. Both are large, both want a toolchain of their own, and both put a second inference engine inside your process.

There is a third answer, and it takes four commands.

mkdir kjarni-quickstart && cd kjarni-quickstart
curl -sL https://github.com/olafurjohannsson/kjarni/releases/latest/download/kjarni-x86_64-linux.tar.gz | tar xz
curl -sO https://raw.githubusercontent.com/olafurjohannsson/kjarni/main/crates/kjarni-ffi/examples/cpp/hello.cpp
g++ -std=c++23 hello.cpp -I. -L. -lkjarni_ffi -Wl,-rpath,'$ORIGIN' -o hello && ./hello

related:   0.5510
unrelated: -0.0630

That is a transformer model, downloaded, loaded and run, from an empty directory. No package manager, no Python, no model conversion step. The archive holds the shared library, kjarni.h (the C ABI) and kjarni.hpp (a header-only C++23 wrapper). macOS and Windows
builds are on the same [releases page(https://github.com/olafurjohannsson/kjarni/releases).

Here is what hello.cpp contains:

#include "kjarni.hpp"
#include <print>

int main() {
    // Downloaded once and cached under ~/.cache/kjarni, then loaded from disk.
    auto embedder = kjarni::Embedder::create({.model = "minilm-l6-v2"});
    if (!embedder) {
        std::println("{}", embedder.error().message());
        return 1;
    }

    auto question = embedder->encode("How do I get my money back?");
    auto related = embedder->encode("What is your refund policy?");
    auto unrelated = embedder->encode("The weather in Reykjavik is unpredictable.");

    // No shared words with the question, but the same meaning.
    std::println("related:   {:.4f}", kjarni::cosine(*question, *related));
    std::println("unrelated: {:.4f}", kjarni::cosine(*question, *unrelated));
}

"How do I get my money back?" and "What is your refund policy?" share no words at all, and score 0.55. The sentence about the weather scores below zero. That gap is the entire idea behind semantic search.

How semantic search works

An embedding model reads text and returns a vector, an array of floats, 384 numbers for the model above. Text with similar meaning produces vectors that point in similar directions.

"refund policy"  -> [0.12, -0.34, 0.56, ...]  (384 numbers)
"get money back" -> [0.11, -0.33, 0.55, ...]  (384 numbers)  <- close
"weather today"  -> [-0.45, 0.23, -0.12, ...] (384 numbers)  <- far

You compare two vectors with cosine similarity, which measures the angle between them and ignores their length. It runs from 1 for identical direction to -1 for opposite.

What you actually link against

This is the part that decides whether the approach is worth anything, so it is worth checking rather than believing. Ask the linker:

$ ldd hello
    linux-vdso.so.1
    libkjarni_ffi.so => /home/you/kjarni-quickstart/libkjarni_ffi.so
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
    /lib64/ld-linux-x86-64.so.2
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2

Kjarni, the C++ runtime, and the parts of glibc every program already uses: libc, libm, libgcc, libpthread and libdl. That is the whole list. No libtorch, no onnxruntime, no Python, no CUDA runtime. The binary is 283 KB and the library is 19.4 MB, which includes the tokenizer, the model loaders and every kernel.

The -Wl,-rpath,'$ORIGIN' in the build line is what makes that first entry resolve to the library sitting next to your binary rather than something in /usr/local/lib. Keep it, and
the directory you built in is a directory you can copy somewhere else and run.

A dependency you cannot see in ldd is a dependency that cannot break you on a machine that is not yours.

Errors are values

Every fallible call returns std::expected<T, kjarni::Error>. Nothing in the header throws except std::bad_alloc.

auto embedder = kjarni::Embedder::create({.model = "minilm-l6-v2"});
if (!embedder) {
    std::println(stderr, "could not load model: {}", embedder.error().message());
    return 1;
}

Whether a missing model file is exceptional depends on the program. A batch job should die; a desktop application should show a message and carry on. Returning the failure lets the caller decide, and puts it in the signature where it cannot be missed.

The options are a designated-initialiser aggregate, so a call names only what it changes:

Embedder::create({.model = "mpnet-base-v2", .gpu = true}).

Searching a corpus

Encode the documents once, encode the query at search time, sort by similarity.

#include "kjarni.hpp"

#include <algorithm>
#include <print>
#include <ranges>
#include <string_view>
#include <vector>

int main() {
    auto embedder = kjarni::Embedder::create({.model = "minilm-l6-v2"});
    if (!embedder) {
        std::println(stderr, "could not load model: {}", embedder.error().message());
        return 1;
    }

    constexpr std::array docs = {
        std::string_view{"How do I reset my password?"},
        std::string_view{"What is your refund policy?"},
        std::string_view{"Do you ship internationally?"},
        std::string_view{"How do I update my billing address?"},
        std::string_view{"Where can I track my order?"},
    };

    std::vector<std::vector<float>> corpus;
    corpus.reserve(docs.size());
    for (std::string_view d : docs) {
        auto v = embedder->encode(d);
        if (!v) {
            std::println(stderr, "encode failed: {}", v.error().message());
            return 1;
        }
        corpus.push_back(v->to_vector());
    }

    constexpr std::string_view query = "I need to change my login credentials";
    auto q = embedder->encode(query);
    if (!q) {
        std::println(stderr, "encode failed: {}", q.error().message());
        return 1;
    }

    std::vector<std::pair<float, std::string_view>> scored;
    for (auto [i, doc] : std::views::enumerate(docs))
        scored.emplace_back(kjarni::cosine(q->values(), corpus[i]), doc);

    std::ranges::sort(scored, std::ranges::greater{},
                      &std::pair<float, std::string_view>::first);

    std::println("query: \"{}\"", query);
    for (auto [score, doc] : scored)
        std::println("  {:.4f}  {}", score, doc);
}

query: "I need to change my login credentials"
  0.5981  How do I reset my password?
  0.4067  How do I update my billing address?
  0.0767  Where can I track my order?
  -0.0027  What is your refund policy?
  -0.0451  Do you ship internationally?

"Change my login credentials" matches "reset my password" at 0.60 while sharing no words with it, and "update my billing address" comes second because changing account details is a
related idea. That is what you cannot get from keyword matching.

encode returns a kjarni::Embedding, which owns the array the C API returned and frees it in its destructor. It hands out a std::span<const float> through values(), so it drops
straight into ranges, and to_vector() copies when the data has to outlive the object. There is no raw pointer to forget.

Classification and reranking

The other models follow the same shape.

auto clf = kjarni::Classifier::create({.model = "roberta-sentiment"});
if (!clf) { std::println(stderr, "{}", clf.error().message()); return 1; }

for (std::string_view t : {"I love this product!",
                           "Terrible quality, broke after one day."}) {
    auto top = clf->top(t);
    if (!top) { std::println(stderr, "{}", top.error().message()); return 1; }
    if (*top) std::println("  {:<9} {:5.1f}%  \"{}\"", (*top)->name, (*top)->score * 100, t);
}

  positive   98.5%  "I love this product!"
  negative   94.1%  "Terrible quality, broke after one day."

top() returns Result<std::optional<Label>>, which puts two separate questions in the type: did the call work, and did it produce a label. A model with nothing above threshold is
not a failure.

Reranking uses a cross-encoder, which reads the query and each document together instead of comparing two independently produced vectors. It is slower and much more precise, so it runs
as a second pass over whatever the embeddings retrieved:

auto rr = kjarni::Reranker::create();
if (!rr) { std::println(stderr, "{}", rr.error().message()); return 1; }

const std::vector<std::string> docs = {
    "Machine learning is a subset of artificial intelligence.",
    "Deep learning uses neural networks with many layers.",
    "The weather today is sunny.",
};

auto ranked = rr->rerank("What is machine learning?", docs);
if (!ranked) { std::println(stderr, "{}", ranked.error().message()); return 1; }

for (const auto& r : *ranked)
    std::println("  {:>9.4f}  {}", r.score, docs[r.index]);

    10.5139  Machine learning is a subset of artificial intelligence.
    -5.5301  Deep learning uses neural networks with many layers.
   -11.1001  The weather today is sunny.

The scores are logits, not probabilities. What matters is the ordering and the size of the gap between one document and the next. Ranked gives back an index into your input rather than a copy of the text, so whatever IDs, URLs and permissions came with your documents stay attached to them.

One signature detail: rerank takes std::span<const std::string> rather than string_view, because the C call underneath needs an array of null terminated pointers and a string_view does not promise one.

The same numbers in every language

Those figures are not specific to C++. The reranker scores 10.5139, -5.5301 and -11.1001 are
the same values the C# document search post prints, and the
similarity scores are the ones in Semantic Search in C#.

That is the reason a C ABI is the right shape here. There is one engine and one set of
kernels, and the C++ header is a wrapper over the same entry points the C#, Go and Python
packages call. There is no second implementation to drift from the first.

Choosing a model

Model	Dimensions	Input limit	Notes
`minilm-l6-v2`	384	256 tokens	Default. Fast, good quality per byte
`mpnet-base-v2`	768	384 tokens	Higher quality, slower
`nomic-embed-text`	768	8192 tokens	Long documents, though trained at 2048
`bge-m3`	1024	8192 tokens	Large, multilingual

Mind the input limit column. minilm-l6-v2 reads 256 tokens, roughly 900 characters, and silently drops the rest: no error, no warning, just a vector computed from the part it saw.
The cross-encoder has its own limit, reading query and document as one sequence capped at 512 tokens. If your documents are longer than that, chunk them. There is a measurement of
what the truncation costs in Your MiniLM Embeddings Are Probably Truncating at 256 Tokens.

Practical notes

Threading. The handles are not individually thread safe. Give each thread its own, or serialise calls. The engine already parallelises across cores inside a single call, so one embedder will use the machine.

C++23 is only needed for std::expected. Everything else in kjarni.hpp is C++20, and GCC 13 or Clang 17 and newer will build it.

There is no package manager integration yet. No Conan recipe, no vcpkg port. The four commands above are the install story on Linux, and the equivalent archives for macOS and
Windows are on the releases page.

If you are on C++11 or C++17

Plenty of codebases are, and a header that demands C++23 is not much use to them. It is worth being clear about what the requirement actually covers: kjarni.hpp needs C++23 for
std::expected, and nothing else does. kjarni.h is plain C, it is the interface every other language binding is built on, and it works from C++11 upward.

The whole of the C++23 convenience is one RAII wrapper and a copy:

#include "kjarni.h"

#include <cstdio>
#include <memory>
#include <string>
#include <vector>

namespace {

struct EmbedderDeleter {
    void operator()(KjarniEmbedder* p) const { kjarni_embedder_free(p); }
};
using EmbedderPtr = std::unique_ptr<KjarniEmbedder, EmbedderDeleter>;

std::vector<float> encode(KjarniEmbedder* emb, const char* text) {
    KjarniFloatArray arr{};
    if (kjarni_embedder_encode(emb, text, &arr) != KJARNI_ERROR_CODE_OK) {
        std::fprintf(stderr, "encode failed: %s\n", kjarni_last_error_message());
        return {};
    }
    std::vector<float> out(arr.data, arr.data + arr.len);
    kjarni_float_array_free(arr);   // copied out, so release the engine's buffer
    return out;
}

} // namespace

int main() {
    KjarniEmbedderConfig cfg = kjarni_embedder_config_default();
    cfg.model_name = "minilm-l6-v2";
    cfg.quiet = 1;

    KjarniEmbedder* raw = nullptr;
    if (kjarni_embedder_new(&cfg, &raw) != KJARNI_ERROR_CODE_OK) {
        std::fprintf(stderr, "could not load model: %s\n", kjarni_last_error_message());
        return 1;
    }
    EmbedderPtr embedder(raw);

    const std::vector<float> question  = encode(embedder.get(), "How do I get my money back?");
    const std::vector<float> related   = encode(embedder.get(), "What is your refund policy?");
    const std::vector<float> unrelated = encode(embedder.get(), "The weather in Reykjavik is unpredictable.");
    if (question.empty() || related.empty() || unrelated.empty()) return 1;

    std::printf("related:   %.4f\n",
                kjarni_cosine_similarity(question.data(), related.data(), question.size()));
    std::printf("unrelated: %.4f\n",
                kjarni_cosine_similarity(question.data(), unrelated.data(), question.size()));
}

g++ -std=c++17 hello17.cpp -I. -L. -lkjarni_ffi -Wl,-rpath,'$ORIGIN' -o hello17

related:   0.5510
unrelated: -0.0630

The same numbers as the C++23 version, because it is the same engine underneath. That compiles unchanged under -std=c++11 as well.

Two rules cover the manual memory. Any KjarniFloatArray you receive is freed with kjarni_float_array_free once you have copied what you need out of it, and any handle is freed with its matching _free function. Wrapping the handle in a unique_ptr with a
custom deleter, as above, means the second rule takes care of itself on every return path.

Error text comes from kjarni_last_error_message(), and it reports the most recent failure process wide, so read it immediately after the call that failed rather than saving it up.

Compared to the alternatives

	libtorch	ONNX Runtime	Kjarni
Install	download SDK, match ABI	package plus model conversion	one archive
Model format	TorchScript	.onnx, converted	HuggingFace safetensors and GGUF directly
Extra entries in `ldd`	many	its own stack	none beyond libc
Tokenizer	bring your own	bring your own	included
GPU	CUDA toolkit	CUDA or DirectML	WebGPU, no toolkit

The trade is scope. libtorch runs anything expressible in TorchScript. Kjarni runs the model families it implements: BERT-style encoders, cross-encoders, Llama-family decoders, T5, BART and Whisper. For an arbitrary research model, convert it and use ONNX Runtime. For embeddings, classification, reranking or chat inside a C++ program that has to ship somewhere, one archive with no toolchain is a smaller problem than either.

Getting it

kjarni.ai - documentation and the rest of these posts
Releases - the archive used above, for Linux, macOS and Windows
GitHub - source, including kjarni.hpp and the C++ examples
NuGet - the same engine from C#
npm - the same engine in the browser, via WebAssembly
Go module - the same engine from Go
crates.io - the Rust engine itself

Other Resources

Semantic Search in C# - The same engine and the same vectors, from .NET
Build a Document Search Engine in C# - Keyword and semantic retrieval combined, with reranking
Why I Built a Native ML Inference Engine in Rust - What is underneath all of this
ML from the Command Line - The same models as a UNIX tool
Your MiniLM Embeddings Are Probably Truncating at 256 Tokens - Measured, with the cost

Tuesday Coding Tip 24 — Getting template type from an existing object

Tue, 29 Sep 2026 09:59:00 +0000

Nice APIs expose their template types as member aliases so that anybody can get them easily. For other types, you might be able to deduce the type by calling decltype on a return value of some of their functions.

Sometimes, none of that is possible. But there is still a way to get to it. You need to write a template structure that only matches on the type you care about and alias the template parameters so you can access them later, a technique known as ‘type trait’.

#include <vector>

// Base template, only for the compiler
template<class T>
struct UnderlyingVectorType {};

// Overload for vector, note that templates don't have to match
template<class T, class A>
struct UnderlyingVectorType<std::vector<T, A>> {
    using StorageType = T;
    using AllocatorType = A;
};

// Nice types already expose their template types
template<class T>
class NiceType {
public:
    using StorageType = T;
};

int main() {
    int a;
    
    // error: no type named 'type' in 'UnderlyingVectorType<int>'
    // because it resolves to the base template
    // UnderlyingVectorType<decltype(a)>::storageType b;

    std::vector<float> vec;
    using VecStorageType = UnderlyingVectorType<decltype(vec)>::StorageType;
    VecStorageType vec2;
    static_assert(std::is_same_v<VecStorageType, float>);

    NiceType<double> nice;
    decltype(nice)::StorageType myDouble = 0.0;
    static_assert(std::is_same_v<decltype(nice)::StorageType, double>);
}

Tuesday Coding Tip 23 — CMake configure_file

Tue, 22 Sep 2026 09:59:00 +0000

In unit tests, I often don’t want to bother with the working folder of the test binary. But if those tests need physical files from the disc, I need to know their absolute paths (which are different on each machine). Luckily, CMake has a function configure_file that can write CMake variables to a file template.

cmake_minimum_required ( VERSION 3.10 )

set ( USE_MSVC_FEATURES ("${CMAKE_GENERATOR}" MATCHES "Visual Studio 17 2022") )

project ( DEMO CXX )

# CMakeLists.txt
configure_file(
    "${CMAKE_SOURCE_DIR}/TemplateHeader.hpp.in" # input
    "${CMAKE_SOURCE_DIR}/FinalHeader.hpp" # output
)

For example, I can prepare a template for a header that will hold an absolute path to a folder with helper files, and during configuration, I can produce a valid C++ header with the path filled out. CMake will replace variables escaped as @VAR@, ${VAR}, $CACHE{VAR} or $ENV{VAR} and furthermore it can do things like generating #define directives.

// TemplateHeader.hpp.in
#pragma once

#include <filesystem>

#cmakedefine01 USE_MSVC_FEATURES

const std::filesystem::path TESTDATA_FOLDER = "@CMAKE_CURRENT_SOURCE_DIR@/TestFiles";

// Generated FinalHeader.hpp
#pragma once

#include <filesystem>

#define USE_MSVC_FEATURES 1

const std::filesystem::path TESTDATA_FOLDER = "C:/Work/Project/TestFiles";

Full documentation: https://cmake.org/cmake/help/latest/command/configure_file.html

Embedding a web UI into a native desktop application comes with a price

Sun, 20 Sep 2026 14:12:47 +0000

I thought embedding a web UI into a native desktop application would be the easy part.
After all... macOS has WebKit. Linux has GTK WebKit. Windows has WebView2.

One API per platform, smaller installers, native look & feel. Sounds perfect.
Then reality arrived.

macOS 🍎

Honestly, this was the easiest platform.
System WebKit is there.
It behaves consistently.
No additional runtime.
No installer surprises.
Exactly what you'd expect from a platform component.
10/10

Linux 🐧

Things became... more interesting.
GTK WebKit works, but suddenly packaging starts to matter.
An AppImage built on one distribution may refuse to start on another because some required WebKitGTK library isn't available.
Your application itself is perfectly fine.
The user's system just doesn't happen to provide exactly the version your build expects.
You quickly discover that "works on my machine" has many regional dialects.
7/10

Windows 🪟

This one surprised me the most.
Unlike macOS, the web view isn't really just "there."
Using WebView2 means depending on the Edge WebView runtime.
If the runtime isn't installed, congratulations—you now need another installer.
So your installer may install something whose purpose is to allow your application to display HTML.
Not exactly the dependency story I was hoping for.
2/10

Meeting in the middle

At some point I asked myself:
Why am I spending time debugging operating-system packaging instead of building my application?

So I tried CEF (Chromium Embedded Framework).
Yes...
The application becomes larger.
Quite a bit larger.

But in exchange:
• Same rendering engine everywhere.
• Same JavaScript engine everywhere.
• Same debugging experience.
• Same HTML/CSS behavior.
• No Linux WebKit dependency lottery.
• No separate WebView runtime installation on Windows.
• One code path across all desktop platforms.
Ironically, shipping your own browser turned out to be simpler than relying on the browser already "provided" by the operating system.
It's one of those engineering decisions that looks wasteful on paper but ends up reducing complexity everywhere else.
Sometimes carrying the extra megabytes is cheaper than carrying platform-specific surprises.

Curious what others have settled on.

Are you using native web views, CEF, or something else for cross-platform desktop applications?

Tuesday Coding Tip 22 — Compile-time computing

Tue, 15 Sep 2026 09:59:00 +0000

As you might know, templates in C++ are turing-complete and you can use them for compile-time computing. But they are unwieldy. So the constexpr/consteval keywords were created, so you can write a normal code and mark it as viable for compile-time execution. consteval means that the function has to be executed during compilation (and then optimized away) while constexpr gives the compiler the opportunity to do so.

#include <array>

template<unsigned limit>
consteval auto ComputeFibonacciLookup()
{
    std::array<int, limit> result = { 0 };

    unsigned n_1 = 0;
    unsigned n_2 = 1;
    for (unsigned i = 0; i < limit; i++)
    {
        result[i] = (n_1 + n_2);
        n_2 = n_1;
        n_1 = result.at(i);
    }

    return result;
}

constexpr const auto FIB_LOOKUP_TABLE = ComputeFibonacciLookup<10>();
static_assert(FIB_LOOKUP_TABLE.size() == 10u);
static_assert(FIB_LOOKUP_TABLE[0] == 1);
static_assert(FIB_LOOKUP_TABLE[1] == 1);
static_assert(FIB_LOOKUP_TABLE[2] == 2);
static_assert(FIB_LOOKUP_TABLE[3] == 3);
static_assert(FIB_LOOKUP_TABLE[4] == 5);

Why is this useful? For example, you can generate a lookup table to optimize runtime speed while maintaining the table itself via an algorithm, not hard-coded values. Or you can write compile-time unit tests for your code. These are handy the compilation will error out if you have any undefined behavior in your code (that does not happen for regular compilation).

constexpr bool divide(int a, int b)
{
    return (a / b) != 0;
}

// Static assert guaratees compile-time execution
static_assert(divide(10, 5)); // ok

// compilation error, division by zero is UB
// error: static assertion expression is not an integral constant expression
static_assert(divide(10, 0));

Extra thought: This tip was originally written three years ago. Since then, many more constexpr variants of standard containers and language constructs were added to the language. Meaning you can do more advanced stuff in the compile time. With C++26, you can even allocate memory and throw exceptions. The compiler will also check that you properly deallocate memory, which is very clever.

Edit 15.9.2026: Fixed the first code example as per Mike Dabydeen comment. Kudos for the correction!

ForgeZero: What Happens When Someone Finally Stops Forgiving Your Build System

Mon, 14 Sep 2026 21:33:21 +0000

In 1976, a Bell Labs researcher named Stuart Feldman was annoyed at a coworker. The story, as it's been retold for half a century now, goes something like this: a colleague kept shipping broken binaries because he'd edit a source file and forget to recompile the parts of the program that depended on it. Feldman's fix wasn't a lecture. It was make — a tool whose entire reason for existing was to answer one question correctly, automatically, every single time: what, exactly, needs to be rebuilt right now, and what doesn't?

That question turned out to be one of the hardest, most quietly load-bearing problems in all of software engineering. Fifty years later, we're still answering it badly, most of the time, and most engineers have simply stopped noticing.

Make aged the way anything does when it becomes foundational infrastructure nobody's allowed to break: badly, slowly, and in public. Its dependency model — timestamps, phony targets, recursive invocation — leaked complexity into every project that grew past a few dozen files, and autotools showed up to paper over that with an entire generation-of-generators architecture that, to this day, remains one of the most feared corners of the open-source toolchain. CMake arrived at the turn of the millennium out of Kitware's need to build ITK and VTK across radically different platforms without hand-maintaining a Makefile per OS — a meta-build system that generates other build systems, which is either a brilliant abstraction or a confession that the underlying problem was never actually solved, depending on which decade of CMake you personally suffered through.

And then there's Ninja. Evan Martin built it at Google specifically because Chromium's build had grown so large that Make's dependency-graph evaluation had become a measurable, painful part of every engineer's day — and his answer was almost insultingly minimal: a build file format so sparse that the project's own documentation tells you, directly, that you are not meant to write Ninja files by hand. Ninja doesn't try to be pleasant. It tries to be a fast, dumb, extremely well-behaved execution target for something smarter sitting above it, generating its files for it. That single design decision — radical minimalism as a feature, not a limitation — is one of the most underrated ideas in build tooling history, and it's the closest ancestor to what comes next in this story.

Because none of Make, Autotools, CMake, or Ninja were ever built for the workload I actually live in: assembly-heavy code, small C translation units by the hundreds, embedded and bare-metal targets, mixed-language repositories where the coordination between compiler invocations costs more than the invocations themselves. I started building ForgeZero to solve that gap about a year and a half ago, quietly, on my own time, the way most infrastructure worth trusting actually gets built. It went public in May 2026. This is the deep engineering account of what it actually is.

The Thesis, Stated Plainly

A build system should handle planning, invalidation, and routing. It should not try to reinvent the compiler.

That single sentence is the entire architectural spine of ForgeZero, and everything below is just the consequence of taking it seriously. ForgeZero is not GCC, Clang, Zig, NASM, FASM, GAS, or LD, and it has no interest in becoming any of them. It's the thin, transparent coordination layer that decides what those tools need to do, when, and whether they need to do it again at all — and then gets entirely out of the way.

The value proposition compresses into one relationship:

Build Throughput ≈ Useful Compiler Work
                    ─────────────────────────────────────────
                    Discovery + Dispatch + Repeated Work + Invalidation Cost

Every serious build-system optimization in ForgeZero attacks the denominator. None of it touches the numerator, because the numerator — actual code generation correctness — belongs to GCC, Clang, Zig, and the assemblers, permanently, and ForgeZero has no ambition to argue with that division of labor.

The Pipeline as a Chain of Owned Transformations

Filesystem state becomes a source set. The source set becomes a dependency closure. That closure becomes a preprocessing state, then a cache identity, then a set of compiler and assembler actions, then an object graph, then a linker invocation, then a verified artifact.

filesystem state
    -> source set
    -> dependency closure
    -> preprocessing state
    -> cache identity
    -> compiler/assembler actions
    -> object graph
    -> linker invocation
    -> verified artifact

What makes this more than a diagram is that each arrow is an owned boundary with its own failure class. A discovery failure is not a cache failure. A cache failure is not a linker failure. When something goes wrong, an engineer using ForgeZero is diagnosing one specific, narrow transformation — not reverse-engineering an opaque shell invocation that happened to fail somewhere in the middle of a black box.

Four properties fall directly out of respecting that boundary discipline:

Observability — the selected backend, target, flags, object paths, cache decisions, and exact linker command are all visible, not inferred.
Controllability — ABI, compiler, linker, optimization level, sysroot, and output format are never hidden behind a "just trust the abstraction" layer.
Amortization — unchanged units don't get recompiled, and metadata checks run before the expensive stages, not after.
Composability — assembly, C-family code, Zig, Gloria, custom preprocessing, and security tooling all live inside one coordinated pipeline instead of five disconnected ones duct-taped together in CI.

Who This Was Actually Built For

This isn't a general-purpose build tool wearing a performance costume. It has specific, named audiences, and it's honest about who they are:

Assembly engineers — boot code, runtime glue, kernel-adjacent components, flat binaries, hand-managed ELF/PE/Mach-O pipelines, where NASM/FASM/GAS selection and the resulting object format can't be papered over.
C/C++/Objective-C engineers who need direct, unfiltered access to GCC, Clang, or Zig — their own -I, -D, -O, sanitizer, and linker flags surviving intact into the actual command line.
Embedded and cross-compilation engineers targeting ARM, RISC-V, and bare-metal ABIs, where the target triple has to participate directly in backend selection, not get normalized away.
Release and supply-chain engineers who need reproducible builds, source-tree verification, SBOM generation, SAST-style auditing, and filesystem isolation — as genuinely separate concerns from the build cache, never conflated with it.
Build infrastructure authors looking to replace a Make/Ninja/shell-script Frankenstein with one coordinator that has a predictable cache model and room for hooks, watchers, and compile databases.

Cache Identity: The Part Everyone Gets Wrong

Here's the mistake that shows up in almost every homegrown build cache: treating "the source bytes didn't change" as sufficient justification for reusing a compiled object. It isn't, and pretending it is produces silent, maddening correctness bugs. The same source file produces a different correct object under a different compiler, a different compiler version, a different target triple, a different sysroot, different optimization flags, different sanitizer policy, or different linker configuration.

ForgeZero's action-level cache identity is built from the sorted inputs, their digests, the action name, and the full environment and toolchain parameters — not the source hash alone. Two layers do the heavy lifting:

Metadata-first invalidation checks file size and modification time before touching the file's bytes at all. If both match a cache entry, the expensive digest step is skipped entirely. Only a mismatch triggers a full keyed digest computation. This is explicitly a performance optimization, not a cryptographic guarantee — and ForgeZero doesn't pretend otherwise. Security-sensitive verification lives in its own, separately-specified verify/SBOM contract, deliberately kept apart from the invalidation fast path.

The disk hash cache format, FZHC3, stores path length, metadata, a context fingerprint, and a 32-byte digest, written via a temp-file-then-rename sequence specifically to avoid leaving a half-written cache entry behind on a crash. Small detail. The kind of detail that separates a cache you can trust from one you quietly stop trusting after the third mysterious corruption.

Two Hashes, One Honest Boundary

This is where ForgeZero's engineering has genuinely moved since it first went public, and it's worth explaining precisely, because the project draws a hard, deliberate line between two hashing systems that solve related but different problems.

BoomBoom Hash is the original incremental-invalidation engine, built as a specialized layer over keyed BLAKE3. Build context — compiler identity, version, target triple, ordered flags — gets domain-separated and hashed into a derived key first, so the same source bytes produce different digests under different build contexts without any cross-contamination between cache domains. Source files are broken into logical chunks — directive regions, brace-delimited blocks, top-level statements, residual spans — each independently digested and placed as a leaf in a flat, heap-layout Merkle tree. Change one chunk, and only the path from that leaf to the root gets recomputed: O(log n) instead of a full O(n) re-aggregation. Past four changed chunks, a persistent worker pool picks up jobs through atomic fetch-and-add over a flat array, each worker holding its own independent keyed BLAKE3 state, with zero shared mutable state at the hasher level.

BB64 is newer, and it exists precisely because BoomBoom Hash, built on a general-purpose cryptographic primitive, is doing more work than some invalidation paths actually need. BB64 is a purpose-built, non-cryptographic 64-bit hash with a hand-written AVX2 Plan 9 assembly hot path, a scalar fallback verified for bit-exact equivalence against the SIMD path, explicit tail handling for inputs of arbitrary length, and SIMD-accelerated byte comparison and delimiter scanning. On an AMD Ryzen 7 PRO 4750U, it measured roughly 16.87 GB/s at 0 B/op and 0 allocs/op — against roughly 0.42 GB/s for FNV-1a and roughly 1.71 GB/s for BLAKE3 on the same benchmark input. That's about 40x FNV-1a and nearly 10x BLAKE3, for a task — PCH cache-key generation, keyed off header content, compiler, target, flags, and positions — that never needed cryptographic guarantees in the first place.

And here's the part that should matter most to anyone evaluating this as infrastructure, not just admiring the throughput number: BB64 is explicitly, deliberately never used for security-sensitive file integrity, package verification, or any cryptographic surface. That boundary isn't an oversight waiting to be "optimized away" later. It's the whole point. A fast non-cryptographic hash and a keyed cryptographic hash are different tools solving different problems, and collapsing that distinction to save one dependency is exactly the kind of shortcut that turns into a CVE two years later. ForgeZero doesn't take it.

Below the Go Standard Library: The Discovery Layer

This is the part that will make a systems engineer sit up, because it's the difference between "a build tool written in Go" and "a build tool written by someone who's actually spent time fighting syscall on Linux.

Source discovery on Linux bypasses the convenient, portable filepath.WalkDir entirely in favor of raw getdents64 traversal via unix.Getdents, paired with openat using O_NOFOLLOW to keep directory traversal from silently following a symlink somewhere it shouldn't. Metadata collection goes through Linux statx for type, inode, size, and modification time in a single call, falling back to Fstatat on kernels where statx isn't reliably available. Directory reads retry on EINTR instead of surfacing a spurious failure, malformed dirents get validated rather than trusted, and path ordering is made deterministic so two runs on the same tree produce the same discovery order — a small property that matters enormously the first time you're trying to reproduce a flaky build. Non-Linux platforms fall back cleanly to filepath.WalkDir, because the portable API contract stays identical even when the backend implementation doesn't.

The payoff isn't hypothetical: manual dirent parsing measurably cut Linux discovery allocations on a 1,024-file benchmark from roughly 3,182 down to 2,088 allocations per operation — about a third fewer allocations, on a code path that runs at the very start of every single build.

io_uring, Used Honestly

ForgeZero's io_uring integration batches file reads into a single submission cycle instead of one syscall per file, drains completion queue entries fully with explicit user-data bounds checking, handles zero-length files without generating an invalid empty READ request, and supports IORING_OP_STATX for metadata collection through the same ring. It enables IORING_SETUP_COOP_TASKRUN where the kernel supports it, with a clean setup fallback for older kernels that don't.

And then there's the detail that actually tells you how this team thinks: IORING_OP_GETDENTS was never wired up, because the target kernel ABI doesn't expose a usable io_uring GETDENTS opcode — so rather than fabricate support for an operation that doesn't reliably exist, directory listing stays on the syscall path where it actually works. That's a small, unglamorous decision. It's also exactly the kind of decision that separates infrastructure you can trust from infrastructure that looks impressive in a README until someone runs it on the wrong kernel version.

Symbol cache decoding is strict — malformed records are rejected outright rather than partially trusted, triggering a fresh extraction through nm, objdump, or readelf instead of silently propagating a corrupted cache entry into a link step. Symbol results move through indexed, preallocated result slots instead of a per-object queue payload, cutting allocation churn on the hot link path. The scheduler supports idempotent shutdown and explicit stopped-state handling, so a second shutdown call doesn't do anything surprising.

And then there's this: worker and scheduler queue producer/consumer counters are deliberately separated across 64-byte cache lines, specifically to avoid false sharing — the scenario where two unrelated atomic counters happen to land on the same CPU cache line and start silently fighting each other for cache coherency traffic under concurrent load, tanking throughput for no reason visible anywhere in the code. This is genuinely advanced systems-engineering territory, the kind of optimization that only shows up in codebases that have actually been profiled under real concurrent load rather than just "made to compile and pass CI."

Gloria: The Language That Refuses to Hide Anything

Sitting inside ForgeZero is Gloria, an experimental language that isn't trying to compete with C, Rust, or a full assembler frontend. It occupies a specific, narrow niche: a minimal language for producing a small, fully-understood fragment of machine code in contexts where a libc, a runtime, and a general-purpose compiler pipeline would be overkill.

source -> lexer -> tokens -> codegen -> machine bytes -> relocation -> raw binary

There's no mandatory intermediate object file, no libc startup sequence, no standard linker script. The emitter writes bytes directly, and ForgeZero writes them out as a raw binary. Functions land in a contiguous output buffer; calls are written first with relocation placeholders, and once the function table is complete, relative displacements get patched directly into the buffer:

disp32 = offset(target) - (offset(call) + 5)

That's the entire mechanism that lets Gloria skip a full object-file linker for small raw images. Compile this:

fn main() {
    let a = 10;
    let b = 20;

    if b > a {
        print("hello world lol");
    }
}

and disassembling the resulting gloria.bin shows exactly what you'd hope for from a language that refuses to hide anything: an entry jump and stack-frame prologue, 64-bit immediate loads materializing the literals, a cmp/jle pair lowering the comparison, and — because the observed output loop writes directly to 0xb8000, the classic x86 VGA text-memory address — a byte-by-byte character-and-attribute write loop instead of a hidden printf call. Every single opcode in that disassembly traces back to a specific, readable decision the emitter made. That transparency, not competing with production languages, is the entire point of Gloria existing at all.

Security as a Neighbor, Not a Costume

ForgeZero keeps its security surfaces deliberately separate from its performance surfaces, because conflating "this build was fast" with "this build can be trusted" is exactly how supply-chain incidents happen. Path validation constrains CLI paths, symlink boundaries, and FZP include resolution to explicitly allowed roots. A dedicated seal/integrity subsystem tracks trust state for executables and toolchains — a fundamentally different question from "do I need to recompile this file," and the codebase treats it as one. SBOM generation produces a CycloneDX-style component inventory with hashes; a separate audit subsystem runs SAST-style checks for secrets, vendor-specific risk patterns, and configuration violations; manifest-based source-tree verification is kept algorithmically stable specifically so release verification stays interoperable across versions instead of silently drifting.

Cache hits are fast. Cache hits are not proof of integrity. ForgeZero's architecture never lets those two facts get confused with each other.

The Redis Case Study, Read Correctly

The number worth reporting is this one:

fz -p performance -dir redis/src -mode c -out redis-server -j 16

user       27.66 s
system     11.68 s
CPU        1155%
elapsed     3.404 s

Read it precisely, because precision is the entire point of this project. 1155% CPU utilization means the work was genuinely spread across multiple hardware threads, not disguised behind a fast single-thread path. 3.404 seconds elapsed against nearly 40 seconds of combined CPU time shows the bottleneck sitting in parallel compile-and-link work, not in sequential orchestration overhead — which is exactly where you want a build's time to be spent. The dependency closure for that run wasn't trivial: fpconv, hdr_histogram, hiredis, libxxhash, linenoise, lua, and tre were each independently compiled into static archives, then handed to the linker alongside Redis's own translation units — proving the pipeline handles real, dependency-aware, multi-ABI native builds, not just a flat folder of standalone .c files.

The honest framing matters more than the headline number: this is end-to-end orchestration latency on one specific host, toolchain, and cache state — not a claim about compiler speed, and not a number that means anything without the CPU model, governor, storage, toolchain versions, cache warmth, and parallelism level that produced it. ForgeZero's own documentation says exactly that, unprompted, which is a more convincing performance claim than any raw benchmark number could be on its own.

Cross-Platform Without Pretending Every Platform Is the Same

The Go core stays portable while low-level operations are split cleanly across build-tagged files: Linux gets native getdents64/statx/io_uring fast paths, other Unix-like targets get mmap/descriptor-based paths, Windows gets its own executable, security, and filesystem branches entirely. Cross-platform, here, doesn't mean identical capability everywhere — it means an identical semantic contract at the API boundary regardless of which backend is actually doing the work underneath it. Linux can have the fastest path available to it without Windows being forced into an emulation layer pretending to be a kernel it isn't.

The Installer Nobody Notices Until It Breaks

install.sh got rewritten as a strict POSIX sh script with explicit platform and architecture validation, --help and missing-option handling, retry-and-timeout logic on both curl and wget, and remote and local checksum verification before anything gets executed. The insecure mktemp -u pattern — which creates a predictable race window between naming a temp path and actually using it — was replaced with a properly private temporary directory. Writable installs land through a temp-file-then-atomic-rename sequence; privileged installs go through sudo install rather than a raw copy; a full dry-run mode exists that downloads and modifies nothing; cleanup traps make sure temp files don't survive a failed run. It's the least glamorous file in the entire repository, and it's exactly the file that determines whether someone's first five minutes with the project go smoothly or end with a half-installed binary and a GitHub issue.

What ForgeZero Deliberately Doesn't Do — And Why That's Worth Trusting

The most senior-engineer-coded section of this entire project's documentation isn't a feature list. It's a short list of things the team explicitly chose not to build, and it's worth reading as a statement of engineering values as much as a technical note:

BB64 stays out of every security-sensitive path — integrity checks, package verification, and cryptographic APIs all keep using the keyed BLAKE3-based BoomBoom Hash, on purpose.
IORING_OP_GETDENTS was never faked into existence to check a feature-completeness box, because the kernel ABI in question genuinely doesn't expose a usable opcode for it.
clone3/execveat weren't forced into the process launcher without a proper lifecycle design, because Go's context cancellation, descriptor ownership, and cross-platform launcher contracts all deserve a real design pass, not a shortcut.
A shared-memory persistent cache wasn't shipped without a versioned format, crash recovery, and an ownership protocol behind it — because a cache that can silently corrupt itself is worse than no cache at all.
No thousand-fold speedup claims got made without workload-specific measurements standing behind them.

Any team can list what they built. Far fewer are willing to publish, in plain language, what they refused to ship half-finished — and that restraint is a far stronger signal of engineering maturity than another benchmark chart would ever be.

Where This Actually Leaves You

ForgeZero isn't trying to convince you that gcc -O3 needs replacing. It's making a much narrower, much more defensible claim: that the coordination surrounding native compilation — discovery, invalidation, scheduling, dispatch, caching, linking — has its own real, measurable cost, and that cost has been quietly tolerated by an entire industry for decades because Make, Autotools, CMake, and Ninja were each solving the build problem of their own era, not this one. Assembly-heavy, embedded, mixed-language, cache-identity-sensitive native builds were never really the target audience for any of them.

A year and a half of quiet, unglamorous systems work — cache-line-aware schedulers, kernel-ABI-honest io_uring integration, a hash function that knows exactly which problems it's allowed to touch and which ones it isn't — is what it actually takes to make that narrower claim true instead of just plausible. That's the whole pitch. Not magic. Not a thousand-fold speedup. Just a build system that finally stops forgiving itself for not knowing precisely why it did what it just did.

From Arduino to ESP-IDF: The architecture behind my digital "Swiss Army Knife"

Sat, 12 Sep 2026 14:58:13 +0000

1. Why build another multi-tool?

How many of you have often found yourselves wanting to buy a Flipper Zero? I thought about it many times, but there were always problems holding me back: stock is often limited, the price tag is quite high, and above all, you miss out on the thrill of building such a powerful tool literally from scratch.

From these observations, my project was born: designing and developing a low-level "Swiss Army Knife".

It all started a few months ago. I was thinking about buying an M5Stick S3 after watching some videos online where people spoke very highly of it, especially for one major detail: unlike the Flipper, it has Wi-Fi and Bluetooth modules already built-in.

Digging deeper, I quickly realized the advantages of the ESP32-S3 over the classic Arduino. The key features that convinced me were:

Dual-core processor: It opens the door to serious features, like managing firmware tasks separately.
More RAM: It allows integrating very complex external libraries (like heavy graphical interfaces) without killing performance.
Native USB HID: It allows emulating peripherals like keyboards or mice natively and quickly.

So, the hardware was decided. But why build a multi-tool?

The main reason is to explore and understand the technical background of as many tools as possible. Lately, I feel there is a tendency to overlook the ingenuity of the mechanisms operating right in front of our eyes. We prefer having a ready-made tool, usable perhaps without even knowing the basics of computer science. I wanted to go in the opposite direction and understand exactly how these things work at the code level.

2. Fluid Graphics and Multitasking: How not to blow up an ESP32

A major problem when rendering a graphical interface on a microcontroller is that the CPU has to calculate and send every single pixel. Since this is a time-consuming operation, the entire device gets blocked until the whole interface is completely redrawn. In a multi-tool, if the ESP32 is stuck drawing buttons, it cannot sniff packets or execute attacks.

To solve this problem and make the device truly responsive, I decided to use DMA (Direct Memory Access). DMA is a dedicated hardware component that allows peripherals (in this case the SPI display) to read data directly from RAM without involving the CPU, generating a single interrupt only when the transfer is complete.

I initialized the SPI bus asking ESP-IDF to automatically assign a DMA channel:

spi_bus_initialize(SPI2_HOST, &buscfg, SPI_DMA_CH_AUTO);

The RAM problem and Chunk Rendering

However, implementing DMA without the right precautions wouldn't have been enough. The device's screen resolution is 135x240 at 16 bits, which requires a total of 64.8 KB to be rendered. This leads to two major problems:

Wasting so many resources just for the interface is not sustainable for a microcontroller.
It is virtually impossible to find 64.8 KB of contiguous memory inside the RAM once the system is running.

To bypass this issue, I decided to divide the screen into horizontal "slices" of 20 lines each (about 5.4 KB total). Using the advanced ESP-IDF APIs, I allocated this buffer in a memory area compatible with DMA:

lv_color_t *buf1 = heap_caps_malloc(LCD_H_RES * 20 * sizeof(lv_color_t), MALLOC_CAP_DMA);

This way, we optimize RAM usage while still maintaining super fluid rendering.

At this point, a question arises: how does LVGL (the library I use to manage the interface) know when the DMA has finished sending the bits for those 20 lines? Simply, with a Hardware Interrupt system that defines this flow:

LVGL fills the buffer and calls the driver.
The driver passes the buffer to the DMA controller.
When the transmission process ends, the interrupt is triggered.
The interrupt immediately calls a callback (notify_lvgl_flush_ready) which orders LVGL to calculate the next slice of the interface.

static bool notify_lvgl_flush_ready(esp_lcd_panel_io_handle_t panel_io, esp_lcd_panel_io_event_data_t *edata, void *user_ctx) {
    lv_disp_drv_t *disp_driver = (lv_disp_drv_t *)user_ctx;
    lv_disp_flush_ready(disp_driver);
    return false;
}

Semaphores for Safety (Thread-Safety)

Since FreeRTOS is a system based on multi-threading, it is important to implement proper task management. A fundamental detail to know is that LVGL is not thread-safe by design. This means that the library has no internal mechanisms to protect itself: if two different tasks try to access or modify the graphical interface at the exact same moment, the system will crash.

To prevent these race-conditions, which can lead to data inconsistency and deadlocks, I implemented a Semaphore (Mutex) system: every time an external task (other than the graphical one) wants to modify a GUI element, it must first "take" the semaphore.

lvgl_mux = xSemaphoreCreateMutex();

If the graphical task is already working, the network task (for example, the WiFi sniffer) waits in queue for a few milliseconds until the Mutex is released. This guarantees that LVGL's memory is read or written by only one thread at a time, making the firmware solid and crash-proof.

3. Data Security and Crash Prevention

Having a responsive interface and fast loading times is not enough: we also must try to make the firmware as robust as possible against hardware failures.

This justifies the choice of the file system: LittleFS. Unlike the classic FAT32 or SPIFFS (which would corrupt the disk leading to the loss of all data in case of sudden shutdown), LittleFS was specifically designed for battery-powered microcontrollers and can maintain its integrity even if the power is suddenly cut off.

esp_vfs_littlefs_conf_t conf = {
    .base_path="/memoria",
    .partition_label="storage",
    .format_if_mount_failed = true, 
    .dont_mount = false,
};
esp_err_t ret = esp_vfs_littlefs_register(&conf);

A great engineering practice is using the .format_if_mount_failed = true parameter, which allows handling the very first boot of the firmware on an empty memory by simply formatting it entirely on its own, without the user having to do anything.

How to read Giant Payloads without running out of RAM

The second major risk for stability is reading files. Many microcontrollers have very limited RAM that fills up in an instant if you try to open a file of several Megabytes all at once.

To prevent the BadUSB tool from going into Out of Memory when executing complex payloads, I decided to implement a "line-by-line" reading. Think of it a bit like an e-reader: it doesn't load the whole book into memory, but only shows the small part of text you are reading, allowing you to scroll through the pages interacting with the interface.

My parser dynamically loads only 256 bytes at a time:

bool esegui_duckyscript(const char *path) {
    FILE *f = fopen(path, "r");
    if (!f) return false;

    char line[256];

    // RAM consumption is capped at 256 bytes, regardless 
    // of the size of the file loaded by the user!
    while (fgets(line, sizeof(line), f)) {
        trim_trailing(line);
        if (strlen(line) == 0) continue;

        char *cmd = strtok(line, " ");
        // parsing and execution of the single command...
    }
    fclose(f);
    return true;
}

Conclusion

This is how I structured my project to guarantee its stability, responsiveness, and scalability, especially considering the large number of tools I am going to implement.

In the next episode, we will get to the heart of the action: I will show you how I used the USB stack to make the computer believe that the ESP32 is a keyboard, in order to execute DuckyScript scripts (BadUSB).

In the meantime, which pentesting tool would you like to see added to the project? Let me know in the comments!

C++ Customization Points: Why tag_invoke Was Brilliant—and Why P2300 Moved Away From It

Sat, 12 Sep 2026 09:41:39 +0000

Generic C++ code needs customization points whenever a library wants to operate on types it doesn't own. The problem is deceptively simple: how can a library let users customize an operation without requiring inheritance, runtime dispatch, or modification of the library's source?

C++ has accumulated several answers over the decades—class template specialization, argument-dependent lookup (ADL), and Customization Point Objects (CPOs)—but each leaves important gaps. In 2019, Lewis Baker, Eric Niebler, and Kirk Shoop proposed P1895R0: tag_invoke — A general pattern for supporting customisable functions. The core idea was simple: use one ADL customization name (tag_invoke) and encode the operation in the first argument's type.

This pattern made several architectural techniques considerably easier to express—most notably generic forwarding through wrapper types—and saw adoption in Boost.JSON and early sender/receiver execution frameworks. But it also ignited vigorous debate, captured in Barry Revzin's critique, "Why tag_invoke is not the solution I want".

The central lesson is that CPOs and tag_invoke solve different layers of the customization problem. A Customization Point Object (CPO) is the user-facing function object that encapsulates an operation's invocation and dispatch policy. tag_invoke is a customization protocol that can be used to implement a CPO, or used directly by a library's customization API.

Neither, however, gives C++ a language-level way to declare and verify customization interfaces. Tracing why tag_invoke appeared, where it succeeded, and why the Sender/Receiver model eventually moved away from it tells one of the most instructive architectural stories in modern C++.

Crucial Distinction: CPO ≠ tag_invoke

Before digging into mechanics, we should clarify the single most common source of confusion in this area: a Customization Point Object is not the same thing as tag_invoke.

A Customization Point Object (CPO) is the user-facing function object that encapsulates an operation's invocation and dispatch policy. tag_invoke is one specific customization protocol that a CPO can choose to use under the hood:

Customization Point Object (CPO) [User-facing interface & invocation policy]
        │
        ├── can dispatch via raw ADL (e.g. std::ranges::begin)
        ├── can dispatch via member functions (.begin())
        ├── can dispatch via class template specialization
        └── can dispatch via a tag protocol (e.g. tag_invoke)

tag_invoke does not replace CPOs; it is a customization protocol that can be used to implement a CPO, or used directly by a library's customization API (as Boost.JSON does).

The Historical Timeline

To follow how modern C++ arrived at its current customization landscape, it helps to keep the timeline in view:

2015   N4381 — Customization Point Objects formalized (Niebler)
   ↓
2019   P1895R0 — tag_invoke proposed (Baker, Niebler, Shoop)
   ↓
2020   Barry Revzin — "Why tag_invoke is not the solution I want"
   ↓
2020   Boost 1.75 — Boost.JSON adopts tag_invoke for conversions
   ↓
2021   P2279R0 — "We need a language mechanism for customization points" (Revzin)
   ↓
2021–23 P2300 — tag_invoke used extensively across early Sender/Receiver (libunifex)
   ↓
2024   P2300R9/R10 — std::execution replaces tag_invoke with member customization + domain dispatch
   ↓
2026   C++26 standard finalized — std::execution standardized as the core asynchronous framework

When Is `tag_invoke` a Good Fit?

If you are evaluating customization strategies for your own libraries or application architectures, here is a practical decision guide:

Prefer `tag_invoke` when:

Your ecosystem or library already uses it (e.g., writing custom serializers for Boost.JSON).
You need generic wrappers or adapters that forward unknown customization points to wrapped objects.
You need a uniform, non-intrusive customization protocol across a large set of operations.
You want operation identity encoded in a type rather than risking collisions across shared ADL function names.
You are implementing a type-erased facility around a known set of CPO tags.

Prefer another mechanism when:

A named member function (obj.operation()) is sufficient and you control or can constrain the participating types.
The interface should be highly visible and self-documenting in class definitions.
You want straightforward, localized compiler diagnostics without deep template instantiation cascades.
There are only one or two simple customization points.
Your ecosystem does not otherwise use tag_invoke.

The Customization Problem & Barry's Criteria

In his 2020 analysis, Barry Revzin laid out six criteria for what constitutes a proper customization mechanism:

Clear interface definition: You can look at code and immediately see what operations can or must be customized, along with expected signatures and semantics.
Overridable default implementations: A library can supply a sensible fallback that types can selectively override for efficiency.
Explicit opt-in: Types intentionally declare that they satisfy the interface rather than accidentally matching loose signatures.
Early failure on incorrect opt-in: If a type tries to implement an interface with the wrong signature, the compiler rejects it at the point of definition, not miles away at a call site.
Safe and intuitive invocation: Calling the customized function is simple, and callers cannot accidentally bypass user customizations.
Programmatic interface verification: Generic code can easily check whether a type satisfies the customization requirements (e.g., via a Concept).

(Note: While Barry's initial 2020 post framed the discussion around these six points, his subsequent paper P2279R0 expanded the analysis to additional architectural dimensions, including atomic grouping of operations, associated types, non-intrusive customization, and generic forwarding.)

In C++, virtual member functions satisfy all six criteria cleanly:

struct Printable {
    virtual void print() const = 0;              // 1. Clear interface
    virtual void describe() const { print(); }   // 2. Overridable default
};

struct Widget : Printable {
    void print() const override;                 // 3. Explicit opt-in
    // void print(int) override;                 // 4. Compile error at definition!
};

Calling ptr->describe() dispatches cleanly (Criterion 5), and checking std::derived_from<T, Printable> verifies it (Criterion 6).

However, virtual functions are unsuitable for generic programming:

Intrusive: You cannot add a virtual member function to int, std::string, or a type defined in a third-party library without wrapping it in an adapter.
Runtime overhead: Virtual dispatch introduces an indirect call through a vtable and may inhibit compiler inlining unless the dynamic type can be devirtualized. Polymorphic objects also carry a vptr. (Importantly, virtual dispatch does not inherently require heap allocation—polymorphic objects can live on the stack or in static storage—but the indirection remains).
Incompatible with generic value semantics: Virtual methods cannot be function templates, nor can they easily return varying, dependent types tailored to each concrete implementation.

Hence the quest for static customization.

Three Generations of Static Customization

Generation 1: Class Template Specialization (`std::hash<T>`)

The oldest static technique requires users to specialize a class template owned by the library:

namespace std {
    template <>
    struct hash<MyType> {
        size_t operator()(const MyType& x) const noexcept {
            return std::hash<int>{}(x.id);
        }
    };
}

This provides explicit opt-in and prevents accidental signature matches. However:

The customization has to be expressed through a library-owned class template specialization, which makes conditional and composable customization awkward.
Function-template specializations are not a substitute for overload-based customization because they do not participate in overload resolution in the same way.

Generation 2: Raw ADL & The "Two-Step Dance" (`swap`)

The classic C++98/11 idiom for customizable algorithms relied on Argument-Dependent Lookup (ADL):

template <typename T>
void process(T& a, T& b) {
    // The infamous two-step dance:
    using std::swap;
    swap(a, b); // Finds custom swap via ADL if present, otherwise std::swap
}

Types customize swap by providing a non-member function in their own namespace (typically as a hidden friend):

struct Buffer {
    friend void swap(Buffer& a, Buffer& b) noexcept {
        // optimized pointer swap...
    }
};

This is non-intrusive and supports fallbacks, but introduces two notable failure modes:

The "Forgot the using" Bug: Writing std::swap(a, b) instead of using std::swap; swap(a, b); silently bypasses the user's custom implementation, invoking the generic copy/move fallback.
The ADL Namespace Problem: ADL searches all namespaces associated with a function's arguments. When multiple independent libraries pick the same common function name—such as size(x)—a call on a type that brings both namespaces into scope can result in ambiguous overloads or silent dispatch to an unintended function.

Generation 3: ADL-based Customization Point Objects (N4381 / Ranges)

In N4381: Suggested Design for Customization Points, Eric Niebler formalized Customization Point Objects (CPOs), which were standardized in C++20 Ranges (std::ranges::begin, std::ranges::swap).

A CPO is an ordinary function-object value placed in a specific namespace. Callers invoke the object directly:

std::ranges::swap(a, b);
auto it = std::ranges::begin(container);

The caller no longer performs ADL directly. The CPO owns the dispatch policy, encapsulating internal ADL lookups, member-function checks, and default fallbacks:

namespace mylib {
    namespace _detail {
        void foo() = delete; // Poison pill to avoid finding enclosing foo()

        struct foo_fn {
            template <typename T>
                requires requires(T&& x) { foo(std::forward<T>(x)); }
            constexpr auto operator()(T&& x) const
                noexcept(noexcept(foo(std::forward<T>(x))))
                -> decltype(foo(std::forward<T>(x))) {
                return foo(std::forward<T>(x));
            }
        };
    }

    inline namespace _cpos {
        inline constexpr _detail::foo_fn foo{};
    }
}

Because the CPO is a first-class function-object value, it can be stored, passed to other algorithms, and composed without losing customization behavior.

What ADL-based CPOs Still Struggle With

While CPOs solved the call-site invocation problem, ADL-based CPO conventions still face two architectural friction points:

The ADL Namespace Problem: An ADL-based CPO convention typically requires a corresponding ADL customization name (e.g., std::ranges::begin dispatches to an unqualified ADL begin(x)). If every library creates CPOs for dozens of domain algorithms, independent libraries still risk claiming and colliding on the same ADL identifiers.
The Generic Wrapper Problem: A wrapper cannot generically forward arbitrary ADL customization points because C++ has no mechanism for saying "for any future function name found by ADL, forward the call to the wrapped object."

The `tag_invoke` Protocol (P1895R0)

In P1895R0, Lewis Baker, Eric Niebler, and Kirk Shoop proposed a uniform protocol:

Reserve exactly ONE global ADL customization name: tag_invoke. To specify which operation is being performed, pass the CPO itself as the first argument (the tag).

[Caller: mylib::foo(x)]
         │
         ▼
[CPO: foo_fn::operator()(x)]
         │
         ▼
[tag_invoke(*this, x)] ──(ADL Dispatch)────────┐
                                                ▼
                         ┌──────────────────────────────────────────┐
                         │ tag_invoke(tag_t<foo>, MyType) defined?  │
                         └──────────────────┬───────────────────────┘
                                            │
                           ┌────────────────┴────────────────┐
                           ▼ YES                             ▼ NO
               [Custom Hidden Friend]             [Default Fallback in CPO]

Encoding Operations in Tag Types

Instead of dispatching to an ADL foo(x) or bar(x), the CPO dispatches to tag_invoke(foo, x) or tag_invoke(bar, x).

Because the operation identity is encoded in the first argument's type, collision risks between independent libraries are greatly reduced:

namespace geom {
    struct area_fn { /* ... */ };
    inline constexpr area_fn area{};
}

namespace screen {
    struct area_fn { /* ... */ };
    inline constexpr area_fn area{};
}

class ScreenWindow {
    // Customization for geom::area (tag is geom::area_fn)
    friend double tag_invoke(geom::area_fn, const ScreenWindow& w) {
        return w.physical_width * w.physical_height;
    }

    // Customization for screen::area (tag is screen::area_fn)
    friend int tag_invoke(screen::area_fn, const ScreenWindow& w) {
        return w.pixel_width * w.pixel_height;
    }
};

Even though both operations conceptually represent "area", their tag types (geom::area_fn and screen::area_fn) are distinct C++ types. Both customizations live side-by-side as hidden friends without ambiguity.

tag_invoke is still an ADL customization mechanism—it does not eliminate all ADL-related complexity—but it channels lookups through a single identifier differentiated by the tag type.

A Pedagogical `tag_invoke` Dispatcher

Let's build a deliberately simplified tag_invoke dispatcher for exposition. Production implementations (such as in libunifex, stdexec, or Boost) add substantial machinery for return type deduction, noexcept propagation, constraint checking, and error diagnostics.

#include <concepts>
#include <type_traits>
#include <utility>

namespace core {

namespace _tag_invoke_detail {
    // Poison pill declaration to ensure ADL occurs cleanly
    void tag_invoke();

    struct _fn {
        template <typename Tag, typename... Args>
            requires requires(Tag&& tag, Args&&... args) {
                tag_invoke(std::forward<Tag>(tag), std::forward<Args>(args)...);
            }
        constexpr decltype(auto) operator()(Tag&& tag, Args&&... args) const
            noexcept(noexcept(tag_invoke(std::forward<Tag>(tag), std::forward<Args>(args)...))) {
            return tag_invoke(std::forward<Tag>(tag), std::forward<Args>(args)...);
        }
    };
}

// The caller-facing dispatcher object
inline namespace _cpos {
    inline constexpr _tag_invoke_detail::_fn tag_invoke{};
}

// Convenience helper to extract the tag type from a CPO variable reference
template <auto& Tag>
using tag_t = std::decay_t<decltype(Tag)>;

// Concepts checking whether a tag can be invoked with given arguments
template <typename Tag, typename... Args>
concept tag_invocable = std::invocable<decltype(tag_invoke), Tag, Args...>;

template <typename Tag, typename... Args>
concept nothrow_tag_invocable =
    tag_invocable<Tag, Args...> &&
    std::is_nothrow_invocable_v<decltype(tag_invoke), Tag, Args...>;

template <typename Tag, typename... Args>
using tag_invoke_result_t = std::invoke_result_t<decltype(tag_invoke), Tag, Args...>;

} // namespace core

Defining a CPO with `tag_invoke`

Writing a CPO in a tag_invoke-based ecosystem becomes straightforward:

namespace graphics {

inline constexpr struct draw_fn {
    template <typename T>
        requires core::tag_invocable<draw_fn, const T&>
    void operator()(const T& item) const
        noexcept(core::nothrow_tag_invocable<draw_fn, const T&>) {
        core::tag_invoke(*this, item);
    }
} draw{};

} // namespace graphics

And user types customize it via a hidden friend:

#include <iostream>

struct Circle {
    double radius;

    friend void tag_invoke(core::tag_t<graphics::draw>, const Circle& c) noexcept {
        std::cout << "Drawing a circle with radius " << c.radius << "\n";
    }
};

int main() {
    Circle c{4.5};
    graphics::draw(c); // Prints: Drawing a circle with radius 4.5
}

The Killer Feature: Generic Forwarding Through Wrappers

This is the central architectural reason tag_invoke gained widespread attention.

Consider an adapter or decorator type—a logging wrapper, a thread-safe synchronized adapter, or a mock wrapper. You want the wrapper to forward customizations to the underlying object:

template <typename T>
struct logged {
    T value;
};

In an ADL-based CPO world, the wrapper cannot forward unknown operations because C++ has no syntax for: "for any future function name found by ADL, forward to value". The wrapper author must manually write a forwarding friend for every single CPO by name.

Because all CPOs in a tag_invoke-based ecosystem share the single customization function name tag_invoke, the wrapper needs exactly one templated friend function:

template <typename T>
struct logged {
    T value;

    template <typename Tag, typename... Args>
        requires requires(Tag tag, const T& val, Args&&... args) {
            tag(val, std::forward<Args>(args)...);
        }
    friend decltype(auto) tag_invoke(Tag tag, const logged& w, Args&&... args) {
        std::cout << "[LOG] Intercepted CPO call!\n";
        return tag(w.value, std::forward<Args>(args)...);
    }
};

Testing this with our Circle and graphics::draw:

int main() {
    logged<Circle> monitored{Circle{10.0}};

    // graphics::draw does not know about logged<Circle>.
    // logged<Circle> does not hardcode graphics::draw.
    // Yet forwarding works naturally:
    graphics::draw(monitored);
}

Output:

[LOG] Intercepted CPO call!
Drawing a circle with radius 10

The Caveat: Generic Forwarding Can Be Dangerous

While generic forwarding is powerful, it grants the wrapper broad authority over the customization surface:

CV/Ref Qualification: The simplified example above takes const logged& and forwards to const T&. A truly transparent wrapper must preserve the value category and constness (logged&, const logged&, logged&&, const logged&&), forwarding mutable and move-only operations correctly.
Greedy Overloads: A catch-all tag_invoke overload is easily matched. If it is not constrained carefully, it can accidentally intercept operations intended specifically for the wrapper itself, introduce unintended recursion, alter exception guarantees (noexcept), or silently skew overload resolution.

As Barry Revzin discussed in P2547R1, generic forwarding is one of tag_invoke's greatest architectural strengths, but it requires rigorous constraints to avoid hijacking operations.

Real-World Adoption: Boost.JSON

Boost.JSON (introduced in Boost 1.75) is one of the most prominent production examples of the tag_invoke pattern.

Importantly, Boost.JSON uses tag_invoke as its customization protocol without requiring value_from and value_to themselves to be CPO objects. Boost.JSON documents value_from and value_to as function templates whose customization is performed through ADL-discovered tag_invoke overloads.

Boost.JSON defines two primary tags in boost/json/conversion.hpp:

boost::json::value_from_tag
boost::json::value_to_tag<T>

The value_to_tag<T> tag is especially clever: the target type T is encoded as a template parameter of the tag type itself. This ensures that the user's namespace is automatically included in the associated namespaces for ADL lookup, even when converting from a standard JSON container.

Practical Boost.JSON Walkthrough

#include <boost/json.hpp>
#include <iostream>
#include <string>

struct User {
    int id;
    std::string name;

    // 1. Serialize: User -> boost::json::value
    friend void tag_invoke(boost::json::value_from_tag, boost::json::value& jv, const User& u) {
        jv = {
            {"id", u.id},
            {"name", u.name}
        };
    }

    // 2. Deserialize: boost::json::value -> User
    friend User tag_invoke(boost::json::value_to_tag<User>, const boost::json::value& jv) {
        const auto& obj = jv.as_object();
        return User{
            boost::json::value_to<int>(obj.at("id")),
            boost::json::value_to<std::string>(obj.at("name"))
        };
    }
};

int main() {
    User alice{42, "Alice"};

    // Value -> JSON
    boost::json::value jv = boost::json::value_from(alice);
    std::cout << "Serialized: " << boost::json::serialize(jv) << "\n";

    // JSON -> Value
    User restored = boost::json::value_to<User>(jv);
    std::cout << "Restored: " << restored.id << ", " << restored.name << "\n";
}

Notice the engineering benefits:

The customization functions are hidden friends inside User, so they do not pollute the enclosing namespace.
The user never reopens namespace boost::json.
The user-facing API functions value_from and value_to provide a clean, type-safe entry point.

Sender/Receiver: Why `tag_invoke` Was Attractive—and Why P2300 Moved Away

Historically, the primary driver for tag_invoke was the Sender/Receiver model for asynchronous execution, developed in Meta's libunifex and early revisions of P2300.

An asynchronous runtime involves two layers of operations:

Basis operations: Primitives that execution contexts must implement (schedule, connect, start, set_value, set_error, set_stopped).
Customizable algorithms: Generic algorithms with default implementations that can be overridden for specific execution domains (such as sync_wait, then, or transfer).

The Original Appeal

Early Sender/Receiver designs used tag_invoke universally. It solved the namespace pollution problem and allowed platform authors to specialize algorithms:

// Illustrative concept in early Sender/Receiver:
friend auto tag_invoke(sync_wait_tag, const cuda_sender& s) {
    // Specialized synchronization tailored to a GPU stream rather than
    // blocking the host thread with a generic mutex/condition_variable
}

The tag type also made it possible for a type-erased wrapper to define a vtable for a selected set of CPO tags and implement each entry by invoking the corresponding customization. P2300-era papers explicitly explored this technique for type-erasing senders and receivers.

The Retreat: Why P2300 Replaced `tag_invoke`

Despite these benefits, practical experience with tag_invoke at scale exposed serious pain points:

Inscrutable Diagnostics: When a tag_invoke overload fails a concept constraint, compilers emit multi-page template instantiation cascades rather than pinpointing what signature was expected.
Overload-Set Bloat: Every customized operation sharing the single name tag_invoke meant that in massive codebases, ADL candidate sets became large, slowing down compilation.
Interface Obscurity: Reading a class definition gave no clear indication of what interface was being fulfilled.

As explicitly documented in P2300R10, the authors replaced tag_invoke with an explicit, multi-tiered customization model:

Receiver and Completion Customizations Moved to Named Members:
- schedule(sch) → dispatches to member sch.schedule()
- set_value(rcvr, ...) → dispatches to member rcvr.set_value(...)
- set_error(rcvr, ...) → dispatches to member rcvr.set_error(...)
- set_stopped(rcvr) → dispatches to member rcvr.set_stopped()
Execution-Domain Dispatch for Algorithms:
Sender algorithms like sync_wait and then now customize via an explicit execution-domain mechanism using get_domain, get_completion_domain, and apply_sender.
Query Customization via Environments:
Environment queries use get_env(obj) returning queryable environment objects.

This architectural shift is telling:

Raw ADL ──> CPOs ──> tag_invoke ──> Named Member Customization + Domain Dispatch

The evolution was not simply "standardizing tag_invoke." It was realizing that different customization points have different requirements, and completion operations benefit from explicit member syntax.

Barry Revzin's Critique: `tag_invoke` Is Not a Trait System

In December 2020, Barry Revzin published Why tag_invoke is not the solution I want, followed by P2279R0: We need a language mechanism for customization points.

Barry framed the central question:

tag_invoke answers: "How can libraries build a unified, non-intrusive customization mechanism using existing language rules?"

Barry asks: "Why should users have to construct this machinery in a library when the language could understand customization interfaces directly?"

1. Inscrutable Interface Definitions

With language-level traits (such as Rust's PartialEq), an interface with a mandatory function and an overridable default is concise:

trait PartialEq {
    fn eq(&self, rhs: &Self) -> bool;
    fn ne(&self, rhs: &Self) -> bool {
        !self.eq(rhs)
    }
}

With tag_invoke, expressing that same two-function interface requires dozens of lines of template metaprogramming, nested requires requires clauses, SFINAE fallbacks, and tag-dispatch helper structs. For an application programmer reading the library header, the actual contractual interface is buried under implementation machinery.

2. Lack of Explicit Interface Declarations & Deferred Errors

In a language with native traits (or with virtual ... override), a type explicitly states which interface it implements. If the signature is slightly off, the compiler halts immediately at the type definition:

struct D : B {
    void f(unsigned int) override; // Compile error at definition!
};

In tag_invoke:

struct Widget {
    int id;

    // Subtle slip: takes Widget& instead of const Widget&
    friend bool tag_invoke(eq_tag, Widget& a, Widget& b) {
        return a.id == b.id;
    }
};

This hidden friend does not declare that it is satisfying eq. It merely declares an overload that might be found by future ADL lookups. If someone later calls eq(const_widget1, const_widget2), the overload is quietly ignored:

If a default fallback exists, the compiler silently calls it (possibly producing incorrect runtime results).
If no fallback exists, the compiler emits a deep template-instantiation error stating that Widget does not satisfy tag_invocable.

What `tag_invoke` Deliberately Does Not Solve

It is also worth making clear what tag_invoke is not designed to address:

Member operator synthesis: It does not synthesize operator++, operator*, or operator[].
Associated types and typedefs: It does not define member types like iterator_category or value_type.
Structural interface declarations: It does not declare class layouts or interface contracts.

For synthesizing class interfaces and operators (such as writing an iterator from minimal primitives), developers still use mixin techniques, CRTP, or C++23 explicit object parameters (deducing this).

Compile-Time Cost of Customization: Why ADL Matters

Runtime performance is rarely the only consideration in large C++ projects; compile time is often just as critical.

ADL-based customization has direct compile-time consequences:

Associated Namespace Traversal: Every ADL lookup must examine every namespace associated with every argument type, including enclosing namespaces, base classes, and template arguments.
Overload-Set Size: When all customizations share the single identifier tag_invoke, every participating type that is reachable contributes candidate overloads to the ADL overload set. The compiler must evaluate SFINAE constraints or concept requires clauses on every candidate to determine the best match.
Template Instantiation Depth: Constraining CPOs with std::tag_invocable triggers nested concept evaluations that increase memory consumption and compiler throughput times in translation units with heavy generic code.

Part of the motivation in P2300's shift to named member functions (sch.schedule(), rcvr.set_value(...)) was to make lookup direct, localized, and fast to compile, bypassing ADL candidate set construction entirely for hot completion paths.

Why This Matters in Embedded C++

For embedded systems and bare-metal programming, customization mechanisms are scrutinized under specific constraints:

Zero Runtime Overhead: Like CPOs, tag_invoke resolves entirely at compile time. Overloads inline aggressively, with no vtable indirection and no heap allocation.
Exception Safety & noexcept: Embedded environments frequently compile with -fno-exceptions. A well-designed tag_invoke dispatcher enforces nothrow_tag_invocable, guaranteeing that customization overloads do not introduce throwing paths.
Adapting Vendor Drivers & HALs Without Modification:
In embedded projects, you frequently deal with vendor-provided Hardware Abstraction Layers (HALs) that you cannot modify. With tag_invoke, you can customize higher-level protocols for vendor structs non-intrusively:

// Vendor HAL type (unmodified)
namespace vendor_hal {
    struct stm32_spi_bus { /* hardware registers... */ };
}

// Our application customization
namespace embedded {
    inline constexpr struct transfer_fn {
        template <typename Device, typename Buffer>
            requires core::tag_invocable<transfer_fn, Device&, Buffer&>
        void operator()(Device& dev, Buffer& buf) const noexcept {
            core::tag_invoke(*this, dev, buf);
        }
    } transfer{};
}

// Customize vendor_hal::stm32_spi_bus for embedded::transfer
// without touching vendor headers!
namespace vendor_hal {
    inline void tag_invoke(core::tag_t<embedded::transfer>,
                           stm32_spi_bus& bus,
                           std::span<uint8_t>& data) noexcept {
        // low-level register writes...
    }
}

Now, generic decorators like dma_device<T>, logged_device<T>, or mock_device<T> can forward embedded::transfer generically across different MCU targets.

Comparison Matrix

Feature	Raw ADL (`swap`)	ADL-based CPO (Ranges)	`tag_invoke` Protocol
Call syntax	Unqualified + `using`	Qualified (`ranges::swap`)	Qualified (`lib::foo`)
Caller controls dispatch	Easily bypassed (forgotten `using`)	CPO controls it	CPO controls it
Passable as function object	No	Yes	Yes
Operation-specific dispatch	Via function name	Via function name / CPO	Via tag type
Name collision risk	Possible and potentially serious	Possible (ADL name shared)	Greatly reduced (encoded in tag)
Generic wrapper forwarding	Very difficult	Very difficult	Natural (single catch-all overload)
Definition-time interface checking	No	Usually no	No

Summary and Key Takeaways

CPO ≠ tag_invoke: A Customization Point Object is a caller-facing function object that encapsulates dispatch policy; tag_invoke is a tag-dispatch customization protocol.
CPOs Fix Invocation: By moving the dispatch decision from the call site into a library-owned object, CPOs eliminate the fragile two-step ADL dance.
tag_invoke's Core Strength Is Generic Forwarding: By routing customizations through a single ADL name differentiated by tag type, wrappers can forward arbitrary CPOs without hardcoding their names.
Boost.JSON Proves Its Value for Conversions: Boost.JSON demonstrates that tag_invoke is a proven, highly effective pattern for decoupled domain conversions where types should not depend on JSON headers.
The Lesson of P2300: tag_invoke was not a failed idea—it solved real problems that earlier CPOs handled poorly. Its retreat from P2300 was a pragmatic recognition that completion operations benefit from explicit member syntax, cleaner diagnostics, and faster compile times, while complex algorithms benefit from domain-based dispatch.

Until C++ gains native language support for customization points, tag_invoke remains one of the most clever, powerful, and architecturally instructive patterns in modern C++ generic library design.

References & Further Reading

P1895R0: tag_invoke — A general pattern for supporting customisable functions — Lewis Baker, Eric Niebler, Kirk Shoop (2019)
Why tag_invoke is not the solution I want — Barry Revzin (2020)
N4381: Suggested Design for Customization Points — Eric Niebler (2015)
P2279R0: We need a language mechanism for customization points — Barry Revzin (2021)
P2547R1: Language Support for Customisable Functions — Barry Revzin (2022)
P1292R0: Customization Point Functions — Matt Calabrese (2018)
P2300R10: std::execution — Michal Dominiak, Lewis Baker, Lee Howes, Eric Niebler, Kirk Shoop, et al. (2024)
Boost.JSON Value Conversion & Custom Conversions Documentation — Vinnie Falco, Kary Pardy
Boost.JSON GitHub Repository

No default constructor exists for class

Sat, 12 Sep 2026 06:47:15 +0000

In C++, a default constructor is a constructor that is automatically created by the compiler if no other constructors have been defined for a class. However, if a class has any constructors that have been explicitly defined, the compiler will not create a default constructor for that class. This article will discuss the "no default constructor exists for class" error in C++ and provide solutions on how to fix it. Whether you are a beginner or an experienced C++ developer, this article will help you understand the concept of default constructors and how to use them effectively. So, let's dive in and explore the world of C++ constructors!

What is a constructor and it's role in a class?

A constructor is a special member function of a class that is executed when an object of that class is created. It is used to initialize the state of an object, and its name is always the same as the class name. The purpose of a constructor is to ensure that the object of a class is created in a valid state.

Differences between default and parameterized constructors

In C++, constructors can be defined with or without parameters. A constructor without parameters is known as a default constructor, while a constructor with parameters is known as a parameterized constructor. The default constructor is called when an object is created without any arguments, and it is responsible for initializing the object to a default state. On the other hand, a parameterized constructor is called when an object is created with specific arguments, and it is responsible for initializing the object to a specific state based on the arguments passed.

For example, consider the following class definition:

 
class MyClass {
    int x;
public:
    MyClass() {
        x = 0;
    }
    MyClass(int value) {
        x = value;
    }
};

In this case, MyClass class has two constructors, one default and one parameterized. The default constructor initializes the x variable to 0, while the parameterized constructor initializes the x variable to the value passed as an argument.


MyClass obj; // calls default constructor and x = 0
MyClass obj1(10); // calls parameterized constructor and x = 10

Note It's worth noting that, If a class does not have any constructor defined, the compiler creates a default constructor automatically. However, if the class has any constructor defined explicitly, the compiler will not create a default constructor automatically.

This can lead to a problem if a program attempts to create an object of that class without explicitly calling one of the defined constructors.

For example, consider the following class definition:


class MyClass {
public:
    MyClass(int x) {
        // constructor code
    }
};

In this case, the class MyClass has a single constructor that takes an int argument. Because this constructor has been explicitly defined, the compiler will not create a default constructor for the class. As a result, the following code will not compile:


MyClass myObject;

This will result in a compile-time error since we are trying to initialize an object with a default constructor whereas we created a constructor in our class definition without defining a default constructor.

Working with default constructor in C++

To fix this issue, you can either define a default constructor for the class or create an object of the class by explicitly calling one of the defined constructors. For example, you can define a default constructor for the class as follows:


class MyClass {
public:
    MyClass(int x) {
        // constructor code
    }

    MyClass() {
        // default constructor code
    }
};

This allows you to create an object of the class without any arguments:


MyClass myObject;

Alternatively, you can create an object of the class by explicitly calling one of the defined constructors:



MyClass myObject(42);

Another way to fix this issue is to use the initialization list to initialize the object by passing the required parameters.


class MyClass {
    int x;
public:
    MyClass(int x) : x(x) {
        // constructor code
    }
};

In this case, the object is created and initialized in the same statement.

Best practices for using constructors in C++

When working with constructors in C++, it is important to follow certain best practices to ensure that your code is efficient, readable, and maintainable. Here are some best practices to keep in mind when using constructors in C++:

Always initialize member variables: When defining a constructor, make sure to initialize all member variables to their default or appropriate values. This ensures that the object is created in a valid state.
Avoid duplicating code: When defining multiple constructors for a class, try to avoid duplicating code across constructors. Instead, use a single constructor and pass default values to the member variables.
Use the initialization list: Instead of initializing the member variables in the constructor body, use the initialization list to initialize the member variables directly. This is more efficient and prevents the object from being in an invalid state if an exception is thrown.
Make the constructors explicit: When defining a constructor with a single argument, make the constructor explicit to avoid unexpected type conversions.
Avoid overloading constructors: Overloading constructors can make the code hard to read and maintain. Instead, use default values for member variables in constructors to allow for more flexibility when creating objects.

Comparison of default constructors in C++ and other programming languages

When comparing default constructors in C++ to other programming languages, it is important to note that the behavior and implementation of default constructors can vary.

In some programming languages such as Java, the default constructor is automatically created by the compiler even if other constructors are defined. This means that in Java, the "no default constructor exists for class" error will not occur.

In other programming languages such as C#, the default constructor is not created by the compiler unless the programmer explicitly defines it. This is similar to the behavior in C++, where the default constructor is not created by the compiler if any other constructors are defined.

In contrast, in languages like Python, constructors are not mandatory and there is no concept of default constructors. Instead, the initialization of an object can be done using the __init__() method, which is called when an object is created.

It is important to note that understanding the behavior and implementation of default constructors in different programming languages is crucial, especially when working on projects that involve multiple languages or when transitioning from one language to another. This is because the "no default constructor exists for class" error in C++ can be avoided by using a different programming language with different default constructor behavior.

Conclusion

When a class has any constructors that have been explicitly defined, the compiler will not create a default constructor for that class. This can lead to a problem if a program attempts to create an object of that class without explicitly calling one of the defined constructors. To fix this issue, you can either define a default constructor for the class or create an object of the class by explicitly calling one of the defined constructors, or use the Initialization list.

References

Stroustrup, B. (2013). The C++ Programming Language. Pearson Education.
Deitel, P. J., & Deitel, H. M. (2017). C++ how to program. Pearson.
Lippman, S. B., Lajoie, J., & Moo, B. E. (2014). C++ primer. Addison-Wesley.

Tuesday Coding Tip 21 — Dangers of Enums

Tue, 08 Sep 2026 09:59:00 +0000

C++ and C# have a caveat in their enum types. Each enum has an underlying storage type which limits a maximum number of values and how much space it takes in memory. However, it also works the other way — it says how many distinct values the enum handles.

If you define an enum with just three values, if it has an underlying type of uint8, it handles 256 distinct values. You can take any integer up to 255, cast it to that enum type, and get a “valid” value. When branching on an enum, you need to keep in mind that you might get an undefined value, especially if it was deserialized from the wire.

To add insult to injury, compilers won’t warn you by default. Only pattern matching does for C#. C++ can warn you if you don’t cover a defined enum value in a switch statement, but you must not use the default case — preventing you from correctly handling ill-formed values.

#include <iostream>

enum class Mode : char {
    Primary,
    Secondary
};

std::string to_string(Mode mode)
{   
    switch (mode)
    {
        case Mode::Primary: return "Primary";
        // With -Wswitch-enum
        // warning: enumeration value 'Secondary' not handled in switch
    }
}

std::string to_string2(Mode mode)
{
    switch (mode)
    {
        case Mode::Primary: return "Primary";
        // With -Wswitch-enum
        // no other warning
        default: return "Undefined";
    }
}

std::string to_string3(Mode mode)
{
    switch (mode)
    {
        case Mode::Primary: return "Primary";
        case Mode::Secondary: return "Secondary";
        // With -Wswitch-enum
        // no other warning
    }
}

int main()
{
    auto&& str = to_string3(static_cast<Mode>(42));
    std::cout << str << std::endl; // Output is an undefined behaviour
    return 0;
}

C++ Smart Pointers, unique_ptr vs shared_ptr vs weak_ptr — How to Choose

Sat, 05 Sep 2026 13:18:53 +0000

When I first learned about smart pointers, I was equally confused by all three of them! They are used to manage memory dynamically. unique_ptr is like a master who is responsible for its pet's life. shared_ptr is like you and your friends renting a house together. weak_ptr is like a bystander who can only watch. This post explains what each one really does, with short examples.

Quick answer: use unique_ptr by default. Use shared_ptr only when ownership is truly shared. Use weak_ptr when you need to observe without owning.

	unique_ptr	shared_ptr	weak_ptr
Ownership model	exclusive ownership	shared ownership	no ownership
Can it be copied	No	Yes	Yes
Can it have multiple owners	No	Yes	No (it owns nothing)
Reference counting overhead	none	atomic count increase/decrease on copy and destroy	touches a separate weak count, never the strong count
How to choose	the default choice	when ownership is truly shared	to break circular references

Unique_ptr

unique_ptr means: "I'm your master and responsible for your life and death."

Example:

#include <iostream>
#include <memory>
using namespace std;

struct Task {
    int mId;
    Task(int id) :mId(id) {
        cout << "Task::Constructor" << endl;
    }
    ~Task() {
        cout << "Task::Destructor" << endl;
    }
};

int main()
{
    unique_ptr<Task> taskPtr(new Task(23));
    int id = taskPtr->mId;

    cout << id << endl;

    return 0;
}

Output:

Task::Constructor
23
Task::Destructor

Why unique_ptr can't be copied

unique_ptr can't be copy-constructed or copy-assigned, because copying would let two unique_ptrs point to the same object — and when both are destroyed, the object would be deleted twice. Instead, you use std::move to transfer ownership.

More on ownership transfer: see my earlier post, reset() vs release() vs std::move.

When to choose unique_ptr

unique_ptr prevents memory leaks caused by programming errors — the object is freed automatically when the pointer goes out of scope, even if you forget to delete.
Ownership can be transferred cheaply with std::move, without copying the managed object.

Shared_ptr

shared_ptr means: the house is rented together by friends. When one friend moves out, the house still belongs to the rest — the object is destroyed only when the last owner releases it.

Example:

#include <iostream>
#include <memory>

class House {
public:
    House()  { std::cout << "That's a big house." << std::endl; }
    ~House() { std::cout << "Bye" << std::endl; }
};

int main() {
    std::shared_ptr<House> friend1 = std::make_shared<House>();  // one allocation: object + control block
    std::shared_ptr<House> friend2 = friend1;  // a roommate moves in

    std::cout << friend1.use_count() << std::endl;  // 2
    std::cout << friend2.use_count() << std::endl;  // 2

    friend1.reset();  // a friend moves out
    std::cout << friend2.use_count() << std::endl;  // 1
    return 0;
}

Each shared_ptr copy increments the reference count; each destruction or reset() decrements it. When the count reaches zero, the object is destroyed.

Thread safety of shared_ptr

The member functions of shared_ptr (including the copy constructor and copy assignment operator) can be called on different shared_ptr instances from multiple threads at the same time without any extra synchronization. However, if multiple threads access the same shared_ptr instance and at least one of them calls a non-const member function, a data race occurs. To share the same instance safely, use std::atomic<std::shared_ptr<T>> (since C++20). In C++11/14/17, use the free functions std::atomic_load() and std::atomic_store() instead.

The trap of shared_ptr: circular references

shared_ptr has one famous trap: circular references. If two objects own each other with shared_ptr, neither reference count can ever reach zero — the memory leaks even after you drop all external references. A doubly-linked structure shows the shape of the problem:

#include <memory>

struct Node {
    std::shared_ptr<Node> next;
    std::weak_ptr<Node> prev;  // must NOT be shared_ptr — otherwise two nodes
                               // keep each other alive forever and leak
};

Use weak_ptr for the "back" direction. It breaks the cycle: the object is freed when no one strongly owns it, and the back-pointer simply expires.

Weak_ptr

weak_ptr means: I'm a bystander. I can observe you, but I'm not responsible for you.

Example:

#include <iostream>
#include <memory>

class Object {
public:
    Object(int value) : data(value) {
        std::cout << "Object created with value: " << data << std::endl;
    }
    ~Object() {
        std::cout << "Object destroyed with value: " << data << std::endl;
    }
    int data;
};

int main() {
    std::shared_ptr<Object> sharedObjectA = std::make_shared<Object>(42);
    std::weak_ptr<Object> weakObjectA = sharedObjectA;

    if (auto sp = weakObjectA.lock()) {  // safe idiom: check and lock in one step
        std::cout << "Value: " << sp->data << std::endl;
    } else {
        std::cout << "Object is gone" << std::endl;
    }

    sharedObjectA.reset();
    std::cout << "End of the Program" << std::endl;
    return 0;
}

Key member functions

lock(): if the object is still alive, returns a temporary shared_ptr; if it has been destroyed, returns an empty shared_ptr. Always use if (auto sp = w.lock()) instead of calling expired() and then lock() separately — the object could be destroyed between the two calls.
expired(): checks whether the managed object has already been destroyed.
reset(): releases the weak reference.
swap(): swaps the managed object with another weak_ptr.

Application

Breaking circular references: when an object needs to reference another object without owning it — like Node::prev above — use weak_ptr. The cycle is broken, and both objects are safely released when no longer needed.
Caching systems: caches often hold weak_ptrs so they don't keep objects alive; when an object is no longer used anywhere else, the cache entry simply expires instead of leaking.

Q&A

Q: Can a unique_ptr be converted into a shared_ptr?
A: Yes, and it's the only "copy-like" conversion allowed — it actually moves the ownership: std::shared_ptr<T> sp(std::move(up));. The reference count starts at 1 and nobody has to worry about double deletion.

Q: Is shared_ptr thread-safe?
A: Partly. The reference counting is atomic, so copies and destructions on different instances are safe. But the pointed-to object itself is not protected — if two threads read and write the object's data through their shared_ptrs, you still need a mutex or an atomic.

Q: Can I copy a unique_ptr?
A: No, by design — copying would cause the object to be deleted twice. If you really need to transfer it, std::move it.

Reference

C++ STL: map vs unordered_map — Key Differences and How to Choose

Sun, 23 Aug 2026 10:23:17 +0000

For a long time I used std::map and std::unordered_map interchangeably, and honestly I couldn't tell you why I picked one over the other. When I finally sat down and learned how they work under the hood — a red-black tree vs a hash table — choosing became obvious. This is the note I wish I had when I started.

TL;DR: need keys in sorted order or range queries → std::map. Just fast lookups → std::unordered_map. The rest of this post explains why.

1. Overview

std::map and std::unordered_map are containers used to store {key, value} pairs, and provide efficient insert, search, and delete operations.

The key difference: std::map keeps its elements sorted by key, while std::unordered_map makes no guarantee about order.

Compare std::map and std::unordered_map

	`map`	`unordered_map`
Time complexity	O(log N)	Average O(1), worst O(N)
Ordering	sorted by key	no guaranteed order
Underlying implementation	Red-black tree	Hash table
Key requirements	must support `<` (or a custom comparator)	must support `==` and be hashable

How to choose

Use map when you need to traverse in key order, do range queries (lower_bound/upper_bound), or when the key type doesn't have a good hash function.
Use unordered_map if you just need point lookups, frequent inserts, a large number of elements, and the hash distribution is uniform.

2. Space complexity

std::unordered_map spends extra memory on its bucket array, and it keeps the table less than fully packed (that's the load factor at work), so it typically uses more memory than std::map. As you insert more elements, the table rehashes and the bucket array keeps growing.

3. Requirements on the key

std::map stores its elements in a red-black tree, which requires comparing keys with <. The standard library uses operator< by default, but you can provide a custom comparator instead.

For example — Person as a key of std::map, with a custom comparator:

#include <iostream>
#include <map>
#include <string>

struct Person {
    std::string name;
    int age;

    friend std::ostream& operator<<(std::ostream& os, const Person& p) {
        return os << "(" << p.name << ", " << p.age << ")";
    }
};

struct PersonCompare {
    bool operator()(const Person& lhs, const Person& rhs) const {
        if (lhs.age != rhs.age) { return lhs.age < rhs.age; }
        return lhs.name < rhs.name;
    }
};

int main() {
    std::map<Person, std::string, PersonCompare> myMap;
    myMap[{"Alice", 25}]   = "Engineer";
    myMap[{"Bob", 20}]     = "Student";
    myMap[{"Charlie", 25}] = "Designer";

    for (const auto& [key, value] : myMap) {
        std::cout << key << " -> " << value << std::endl;
    }
    return 0;
}

Run it and notice: the output is strictly sorted by (age, name) — that's the red-black tree at work.

std::unordered_map needs a hash function to decide which bucket each key goes into. Because different keys can end up with the same hash (a collision), it also needs == to tell keys apart.

And the same Person as a key of std::unordered_map — note the two extra template parameters (hash + equality) instead of one comparator:

#include <iostream>
#include <unordered_map>
#include <string>

struct Person {
    std::string name;
    int age;

    friend std::ostream& operator<<(std::ostream& os, const Person& p) {
        return os << "(" << p.name << ", " << p.age << ")";
    }
};

struct PersonHash {
    std::size_t operator()(const Person& p) const noexcept {
        return std::hash<std::string>{}(p.name) ^ (std::hash<int>{}(p.age) << 1);
    }
};

struct PersonEqual {
    bool operator()(const Person& lhs, const Person& rhs) const noexcept {
        return lhs.age == rhs.age && lhs.name == rhs.name;
    }
};

int main() {
    std::unordered_map<Person, std::string, PersonHash, PersonEqual> myMap;
    myMap[{"Alice", 25}]   = "Engineer";
    myMap[{"Bob", 20}]     = "Student";
    myMap[{"Charlie", 25}] = "Designer";

    for (const auto& [key, value] : myMap) {
        std::cout << key << " -> " << value << std::endl;
    }
    return 0;
}

Run this one too: the output order will be different — and not sorted. That single difference in output is the "Ordering" row of the table above, live.

Two details worth noticing:

std::hash<std::string>{}(p.name) ^ (std::hash<int>{}(p.age) << 1) combines the two field hashes with XOR; the << 1 shift keeps (name, age) pairs from hashing symmetrically.
PersonEqual exists because of collisions: two different Persons can land in the same bucket, and == is what tells them apart — exactly the chaining mechanism in the Q&A below.

4. Q&A

Q: How does unordered_map deal with hash collisions?
A: C++ STL uses chaining — elements in the same bucket are linked into a list. When inserting, you attach to the end of the chain; when searching, you first use the hash to find the bucket, then traverse the list comparing keys. The more collisions there are, the longer the chain, and the worse the performance.

Q: Why is the worst case O(n)?
A: In the extreme case where all keys hash to the same bucket, the whole table degenerates into a linked list, and searching turns into a linear scan.

Reference

C++ unique_ptr: reset() vs release() vs std::move

Sat, 22 Aug 2026 15:48:55 +0000

When you first learn std::unique_ptr, three things confuse almost everyone: release(), reset(), and std::move. They all look like they "give something up", but they do very different things. This post explains what each one really does, with short examples.

1. The key to understanding `release()`

release() means: "I don't want to manage this object anymore."

It does not delete the object. It just gives up ownership and hands the raw pointer back to you. After the call, the smart pointer is empty (get() returns nullptr), and you are now responsible for deleting the object.

Parameters
(None)

Return value
The raw pointer to the managed object, or nullptr if there was no managed object.

Example

#include <memory>
#include <iostream>

int main(){
std::unique_ptr<int> ptr = std::make_unique<int>(100);
int* raw = ptr.release(); // ptr gives up ownership, ptr is empty now
if(!ptr)
std::cout<< *raw << std::endl;
delete raw; // we must delete raw manually
}

Warning: release() is rarely what you want:

If you forget to capture the returned raw pointer, the object leaks immediately.
After taking the raw pointer, you must remember to delete it yourself — you are back to manual raw-pointer management.
The one legitimate use: handing the object to a legacy C API that requires a raw pointer and promises to take ownership.

2. The right way to use `reset()`

reset() replaces the managed object.

Called with no argument, ptr.reset() deletes the object it owns and becomes empty. If you pass in a new pointer, the old object is destroyed first, and the smart pointer then takes ownership of the new one.

Parameters
ptr - (optional) pointer to a new object to manage

Example

#include <memory>
#include <iostream>

int main(){
std::unique_ptr<int> ptr = std::make_unique<int>(100);

ptr.reset();  // delete the original object, ptr is empty.

ptr.reset(new int(10)); // delete the old object, manage the new pointer.
}

3. Comparing `release()` and `reset()`

release(): does not delete the old object — it hands the raw pointer back to you
reset(): deletes the old object (if any), then manages the new pointer you pass in
Both make the smart pointer lose control of the old resource; the difference is who deletes the object and when

	release()	reset()
Old object destroyed?	No — you must delete it yourself	Yes, immediately
Smart pointer after call	empty	manages the new pointer (or nothing)
Returns	the raw pointer	nothing

4. How `std::move` fits in

std::move does not move anything by itself. It only marks an object as "moved-from" — a permission slip saying "you may take this object's resources instead of copying them".

Parameters
ob - the object to be moved

Example

class MyClass{
std::string data;
public:
MyClass(std::string&& str) : data(std::move(str)) {}
};

std::vector<std::string> v;
std::string temp = "example";
v.push_back(std::move(temp));

#include <memory>
#include <iostream>

int main(){
std::unique_ptr<int> ptr1(new int(10));
std::unique_ptr<int> ptr2 = std::move(ptr1);
if(!ptr1)
std::cout<< "ptr1 is empty" << std::endl;
if(ptr2)
std::cout<< "ptr2 owns the resource and value is: "<<*ptr2 << std::endl;
}

Why is std::move so common with smart pointers?
std::unique_ptr has exclusive ownership: it cannot be copied, because two owners would delete the same object twice. So the only way to transfer ownership between unique_ptrs is std::move.

References

Case label in switch statement must be constants only

Sun, 02 Aug 2026 07:23:56 +0000

The switch statement is a powerful control flow construct in C++, allowing for efficient execution of code based on the value of a given expression. One of the key features of the switch statement is the use of case labels to determine which block of code should be executed. However, there are certain rules that must be followed when using case labels in C++, specifically, that the case label must be a constant expression. This article will delve into the details of this rule, explaining why it exists and how it can be worked around in certain situations. We will also discuss the implications of this rule on the usage of switch statement and the best practices to follow. With this understanding, you will be able to effectively utilize the switch statement in your C++ code and write efficient, maintainable code.

Switch statement and its uses.

A switch statement is a control flow construct that allows for efficient execution of code based on the value of a given expression. The switch statement is used to test the value of a variable against a list of possible cases, and then execute a block of code corresponding to the first matching case. This can be useful in a variety of situations, such as:

Menu-driven Programs: The switch statement can be used to create a simple menu-driven program, where the user is presented with a list of options and the program takes an action based on the user's choice.
Handling Multiple Conditions: The switch statement can be used to handle multiple conditions in a more concise way. Instead of using multiple if-else statements, a switch statement allows for the same functionality with less code.
Enumerated Types: The switch statement is often used in conjunction with enumerated types, which are a way to define a set of named values. The cases in a switch statement can match the enumerated values, making the code more readable and maintainable.
Error Handling: The switch statement can be used to handle errors in a program by testing the value of an error code and taking appropriate action.
State machines: The switch statement is often used to implement state machines, a design pattern used to handle the various states of a program or system.
Network protocol handling: Switch statement can be used to handle different types of packets, messages or protocols in network communication.

Note It's worth noting that although switch statement is quite efficient in dealing with multiple conditions and handling them, it's not always the best option when it comes to complex conditions and nested statements. In such situations, a combination of if-else statements and other constructs such as function calls, might be more appropriate.

Why case label must be a constant expression.

In C++, the case label in a switch statement must be a constant expression. This means that the value must be known at compile-time and cannot be the result of a function call or an expression that involves a variable. This restriction is in place because the switch statement uses a jump table to determine which case to execute, and the jump table must be generated at compile-time.

One example of a valid case label in a switch statement is a constant integer, such as:


switch (x) {
    case 0:
        // code to execute when x is 0
        break;
    case 1:
        // code to execute when x is 1
        break;
    // etc.
}

An example of an invalid case label would be a variable, such as:


int y = 5;
switch (x) {
    case y: // error, y is not a constant expression
        // code to execute when x is y
        break;
}

However, in C++11, a new feature called constexpr was introduced, which allows variables and functions to be used in constant expressions. This means that in C++11 and later, it is possible to use a variable as a case label in a switch statement, as long as it is declared as "constexpr".


constexpr int y = 5;
switch (x) {
    case y: // valid in C++11 and later
        // code to execute when x is y
        break;
}

It is worth mentioning that the variable used in the switch statement must be an integral type(char, int, etc.) or an enumeration type.

This restriction on the case label in a switch statement is specified in the C++ standard.

What is the difference between switch statement and if-else statement? The main difference between `switch` statement and `if-else` statement is the way they test conditions. A switch statement tests for equality between the value of an expression and a list of possible cases, while an if-else statement tests for a Boolean condition. Switch statement is more efficient when handling multiple conditions with the same variable, while if-else statement is better suited for more complex conditions and nested statements.

In addition to the constness of the case label, it's also important to note that the range of the case label should be considered when using switch statement. In C++ standard, it's not guaranteed that a case label outside the range of the switch statement's controlling expression will be diagnosed.

Conclusion

In conclusion, the case label in a switch statement must be a constant expression in C++. This restriction ensures that the jump table used by the switch statement can be generated at compile-time. However, this restriction is relaxed in C++11 with the introduction of constexpr feature, which allows variables and functions to be used as case labels in switch statement as long as they are declared as constexpr. It's also important to take into account the range of the case label when using switch statement.

Raw Pointers VS Smart Pointers, Which One Should Beginners Learn First

Tue, 28 Jul 2026 14:07:37 +0000

These days, I've been learning C++ and have posted some articles about it. Since I started to learn C++ with raw pointers, I naturally hit some common questions: new/delete, manual memory manage, and so on.C++ Traps That Caught Me Off Guard — A Beginner's Log - Coder Legion

A few days ago, I discussed this topic with some C++ developers. As far as I'm concerned, I believe that raw pointers are fundamental and it's necessary for beginners to build a mental model of RAII and memory management before moving to smart pointers.

On the other hand, some developers think that raw pointers are not a suitable topic for beginners - we have the safer and more modern smart pointers to manage, so why not start with them directly?

Actually, it's up for debate whether beginners should learn these constructs. From my own experience learning C++ through raw pointers, I believe beginners can benefit from a moderate understanding of them.

As for performance, there's no absolute winner. Smart pointers are safer and work well for most scenarios, especially when code maintainability matters. Raw pointers still have their place in performance-critical or low-level contexts. The key is knowing both and choosing wisely.

Which one would you learn first if you are a beginner? And why?

C++ Traps That Caught Me Off Guard — A Beginner's Log

Thu, 23 Jul 2026 09:28:37 +0000

Learning C++ has been a journey full of traps. Here are three I hit — hope they save you some debugging time.

🎣 Trap 1: `new[]` + `delete`(instead of `delete[]`)

Wrong Code

 int* a = new int[3];
 
 // delete a; ❌ --> undefined

class MyClass{
public:
~MyClass(){
std::cout<<"delete successfully"<<std::endl;
}
}
int main(){
MyClass* mc = new MyClass[2];
//delete mc;  ❌ -> only outputs one "delete successfully"

What Happens

C++ standard clearly states that this is undefined behavior. Relying on it is extremely dangerous — different compilers, optimization levels, and platforms may behave completely differently.

new[] + delete only calls the destructor once, while delete[] calls it for every element in the array. Using delete instead of delete[] causes resource leaks for the remaining elements.

How to Fix

 int* a = new int[3];
 
 delete[] a;  -> ✔

class MyClass{
public:
~MyClass(){
std::cout<<"delete sucessfully"<<std::endl;
}
};
int main(){
MyClass* mc = new MyClass[2];
delete[] mc; -> ✔ outputs "delete successfully" twice
}

🎣 Trap 2: `cin` + `getline` eating your input

Wrong Code

int age;
std::string name;

std::cout<<"Enter age: ";
std::cin>>age;

std::cout<<"Enter name: ";
std::getline(cin, name); // ❌ name ends up empty!

std::cout<<name<<std::endl;

What Happens

cin leaves a newline character (\n) in the input buffer, and getline reads it immediately — so it stops before you even type anything.

Why

cin >> reads the value you type but leaves \n in the buffer. getline stops reading when it encounters \n, so it grabs that leftover newline and returns an empty string.

How to Fix

std::cin >> age;
cin.ignore();    // 👈 Eat the leftover newline
std::getline(cin, name);

🎣 Trap 3: `Copy constructor` vs `copy assignment`

class FixArray{
    std::string name_;
    int* data_;
    size_t size_;
public:
~FixArray(){
        delete[] data_;
    }

    FixArray(const FixArray& other) : FixArray(other.size_, other.name_){
        std::copy(other.data_, other.data_ + size_, data_);
    }

    FixArray& operator=(const FixArray& other){
        if(this != &other){
            int* new_data = new int[other.size_];
            std::copy(other.data_, other.data_ + other.size_, new_data);
            delete[] data_;
            data_ = new_data;
            size_ = other.size_;
            name_ = other.name_;
        }
        return *this;
    } 
};

Many beginners can't tell the difference between a copy constructor and a copy assignment. Actually, it's quite simple:

// Copy constructor: creating a new object from an existing one
FixArray fa(10, "example");
FixArray fb = fa;    // 👈 copy constructor called

// Copy assignment: assigning to an already-existing object
FixArray fc(5, "other");
fc = fa;            // 👈 copy assignment called

Copy constructor — creates a brand new object as a copy of an existing one.

Copy assignment — replaces the contents of an already-existing object with another object's data.

The key difference: copy constructor builds something from nothing; copy assignment replaces something that already exists.

>These are three traps I hit while learning C++. If you're a beginner too, I hope this saves you some debugging time. Have you encountered other tricky C++ traps? Share them below!

Tuesday Coding Tip 20 — Be `explicit`!

Tue, 21 Jul 2026 09:59:00 +0000

If you choose to add a conversion operator for your class in C++, be sure to mark it as explicit or you can get nasty side-effects that will be hard to debug. For example, having an implicit conversion operator to bool will make the operator less-than “work” for your class, meaning that class can be used as a key for std::map and suddenly, all hell breaks loose.

#include <iostream>
#include <vector>

class A {
public:
    operator bool() {
        return true;
    }
};

class B {
public:
    explicit operator bool() {
        return true;
    }
};

int main() {
    // This is ok
    std::cout << (A() < A()) << std::endl;
    A a;
    if (a); // implicit conversion allowed

    // Error: error: invalid operands to binary expression
    std::cout << (B() < B()) << std::endl;
    B b;
    if (bool(b)); // explicit conversion required

    return 0;
}

Similarly, it is good practice to mark single parameter constructors explicit to prevent implicit conversions from trivial data types or to possibly track places where your object is copied.

class A {
public:
    A(int) {}
    A(const A&) {}
};

class B {
public:
    explicit B(int) {}
    explicit B(const B&) {}
};

int main() {
    A a1 = 10; // ok
    A a2 = { 10 }; // ok
    A a3 = a1; // ok

    B b1 = 10; // error: no viable conversion, explicit constructor is not a candidate
    B b2 = { 10 }; // error
    B b3 = B{10}; // ok
    B b4 = b1; // error
    B b5 = B{b1}; // ok

    return 0;
}

Tuesday Coding Tip 19 — [[nodiscard]] annotation

Tue, 14 Jul 2026 09:59:00 +0000

Since C++17, one can use [[nodiscard]] annotation to mark API functions whose return values should not be discarded without consideration. This usually applies to methods that make no sense to call without evaluating their return value (like predicate functions such as empty or a factory function). The compiler will issue a warning if the return value is not handled.

class [[nodiscard]] A {};

// OR

class B {
public:
    [[nodiscard]] B() = default;
};

// Enums can be nodiscard too
enum class [[nodiscard]] State {
    Default,
    Foo,
    Bar
};

int main()
{
    // warning: ignoring temporary created by a constructor declared with 'nodiscard' attribute
    A();
    B();
}

But beware! Sometimes it might be tempting to return some scope guard that will maintain postconditions automatically at the end of the scope using RAII (such as committing transactions). However, a user of your API can pipe the result of your nodiscard function into a std::ignore helper which causes the temporary to destruct immediately, defeating the idea of end-of-scope cleanup.

#include <tuple> // std::ignore

class [[nodiscard]] A {};
class B {
public:
    [[nodiscard]] bool isOk() const { return true; }
};

// no need for nodiscard, A is nodiscard
A foo() {
    return A();
}

// B is not nodiscard, mark it explicitly
[[nodiscard]] B bar() {
    return B();
}

int main()
{    
    foo(); // warning: ignoring temporary created by a constructor declared with 'nodiscard' attribute
    bar(); // warning

    std::ignore = foo(); // ok
    auto b = bar(); // ok
    b.isOk(); // warning
    if (b.isOk()) {} // ok
}

Building a Custom Terminal from Scratch: Devlog #1

Sat, 11 Jul 2026 01:08:15 +0000

Purpose

I recently got interested in low-level programming and microcontrollers. For the purpose of exploring the area and gaining some experience, I started building my own bash-like terminal. The language of my choosing—unsurprisingly—was C++, as it is commonly used in low-level systems.

I made specific design choices and trade-offs to overcome challenges, which I am going to share in the next few devlogs.

Why did I ditch strings for raw char pointers?

My first task was seemingly simple: separate the input into an array.

Normally, I would have just used a built-in function to split the input. However, since I wanted this to be a challenge that would push me to think at a low level, I decided to opt out of built-in methods. In fact, throughout the entire process, I actively dodged the C++ libraries designed to make a dev’s life easier.

Going back to the question, I first need to explain the difference between strings and char pointers in C++. If you have any experience with programming languages, you already know the string, or text, type. A string is actually just a list of characters, and that is how it is stored under the hood.

The std::string type is just a wrapper around this char list. In fact, C doesn’t even have a native "string" type. Instead, to handle text, you need to define a char array. This is how software works fundamentally, and I went a step further with this approach by using char pointers.

Char pointers just store the memory address of this char list, which is manually allocated by the developer. But that brings up a problem: whenever the char pointer goes out of scope or is destroyed, it only frees the memory space allocated to store the address of the array. The array itself still exists in memory, which causes a memory leak. Because of this, I have to manually call free() (or delete[]) to empty that allocated memory.

I just thought managing this myself would be a great way to better understand how computers work, even though the standard string type normally handles this automatically.

What about scalability?

Soon, I noticed a major issue. Creating these char pointers in various locations throughout the code felt way too disorganized. I also needed to keep track of the maximum size I allocated for each char pointer to hold, since they don't have a size() function. If that allocated space is exceeded, it can create troublesome, hard-to-debug errors. You are basically writing into an unknown space in memory, which is like playing with fire.

My solution was to create a carr (char array) struct, and equip it with functions to expand, delete, and initialize itself.

I also overloaded some operators, such as =, to directly assign these char pointers. Overloading is simply changing the behavior of an operator for the interactions of that specific struct or class.

A small touch

It is true that I wanted to create a kind of bash clone, but I still didn't want a one-to-one copy. So, I decided to create my own command names.

That is why when I coded the features to get the current directory and move between directories, I chose "here" and "go" rather than "pwd" and "cd." It was just a little flavor I wanted to add.

Of course, when I was coding those commands, I still avoided using standard modern libraries like <filesystem> and went for <dirent.h> and <unistd.h>. They were a bit harder to use, but they gave me the exact low-level systems exposure I was looking for.

The switch

So far, I have written about how I tried to avoid C++ features and chose C-style alternatives instead. Well, that begs the question: why not just switch to C entirely?

My initial reasoning for using C++ was simply because I didn’t know C. However, this project actually created a huge opportunity for me to finally learn C, and I took it.

I thought to myself, "How hard could it be since I already coded it in a C-like style?" Well, it turned out to be quite a challenge.

First of all, remember how I added functions to my carr struct and overloaded its operators? Well, that is not possible in C. Because C doesn't support member functions or operator overloading, I had to recode every single place where I manipulated strings—which was a lot.

In the end, though, I gained complete control over my variables and how I manage them. And honestly, that was the whole point.

If you would like to connect with me, you can check out my socials:

LinkedIn: linkedin.com/in/suleymansade
Medium: @suleymansade09

How Jarvis Learned to Remember, Communicate, and Access Memory

Fri, 10 Jul 2026 09:50:20 +0000

In my previous articles, I learned about functions, arrays, strings, and loops by imagining how they could help build an intelligent assistant like Jarvis.

This week, I continued that journey by learning about 2D arrays, string functions, and pointers.

At first, these topics looked like ordinary programming concepts. But when I started thinking about how Jarvis would use them, their importance became much easier to understand.

Giving Jarvis a Tactical Display with 2D Arrays
Imagine Tony Stark is flying through a city and Jarvis is tracking multiple enemy drones.

For every drone, Jarvis needs to store information such as:

X Position

Y Position

Threat Level

This information can be organized in rows and columns, just like a table.

This is where 2D arrays become useful.

A 2D array allows us to store data in a grid format.

For example:

int enemies[5][3];

Here, each row could represent a drone, and each column could represent information about that drone.

Thinking about 2D arrays this way helped me understand how they can be used to organize large amounts of related data.

Helping Jarvis Understand Commands with Strings
One thing that makes Jarvis special is its ability to communicate with Tony Stark.

When Tony says:

"Jarvis, scan the building."

the system must understand the command before it can perform the action.

In C programming, text is stored using strings.

For example:

char command[] = "scan the building";

This week, I also learned several string functions that make working with text easier.

Some useful string functions are:

strlen() – Finds the length of a string

strcpy() – Copies one string into another

strcmp() – Compares two strings

strcat() – Combines two strings

These functions allow programs to process and manage text efficiently.

If Jarvis receives hundreds of commands every day, string functions would play an important role in understanding and handling them.

Teaching Jarvis Where Information Lives with Pointers
Pointers were one of the most interesting topics I learned this week.

Until now, Jarvis knew what information existed.

With pointers, Jarvis learns where that information is stored.

A pointer stores the memory address of another variable.

For example:

int battery = 90;
int *ptr = &battery;

Here:

battery stores the value 90

ptr stores the address of battery

Instead of only knowing the battery level, Jarvis now knows where that battery information is located in memory.

This direct access to memory is one of the reasons C is widely used in embedded systems.

As I learn more about microcontrollers in the coming weeks, I expect pointers to become even more important.

My Key Takeaway
This week helped me understand that programming is not only about writing code.

It is also about organizing information, processing data, and managing memory efficiently.

Through 2D arrays, Jarvis learned how to organize information in a structured way.

Through strings and string functions, Jarvis learned how to understand and work with text-based commands.

Through pointers, Jarvis learned how to directly access information stored in memory.

Each new topic feels like adding another capability to an intelligent system.

The more I learn, the more I realize that advanced technologies such as AI assistants, robots, and autonomous systems are built using these simple building blocks.

This weekend, Jarvis learned how to organize information, communicate using text, and access memory.

I wonder what new abilities he will gain next weekend.

Jarvis Capability Log
✓ Store data using variables

✓ Perform calculations

✓ Make decisions

✓ Repeat tasks using loops

✓ Organize abilities using functions

✓ Store collections of information using arrays

✓ Process text using strings

✓ Analyze data using nested loops

✓ Organize data using 2D arrays

✓ Understand text using string functions

✓ Access memory using pointers

🚀 Next Upgrade: Coming Soon

Tuesday Coding Tip 18 — Generating random numbers in C++

Tue, 07 Jul 2026 09:59:00 +0000

Classic C way of generating random numbers is to set the current time as a seed and then modulo results of the rand function to get somewhat random numbers (modulo can introduce bias based on the implementation of rand).

#include <iostream>
#include <random>

// Get random integer in range <min, max)
int getRandomNumber(int min, int max)
{
    return rand() % (max - min) + min;
}

int main()
{
    // seeding with current time to get different output each time
    srand(time(NULL));

    for (int i = 0; i < 10; i++)
        std::cout << getRandomNumber(10, 20) << std::endl;
}

C++11 introduces the concept of engines, adaptors, and distributions. Engines are seedable and give you random numbers similar to rand() calls. However, each engine is implemented differently, impacting its speed and memory footprint. Adapters tamper with RNG output, such as shuffling the order of output values or discarding them.

Distributions transform the output from the generators to get values in certain ranges and probabilistic properties, such as the middle value being the most probable (normal distribution). Distributions are more nuanced than just using the modulo operator so their outputs are more suitable for cryptography use-cases.

#include <iostream>
#include <random>

// Get random integer in range <min, max)
int getRandomNumber(int min, int max)
{
    return rand() % (max - min) + min;
}

int main()
{
    std::random_device rd; // non-seedable source of non-deterministic numbers from hardware
    std::mt19937 generator(rd()); // deterministic generator with uniform distribution
                                  // seeded with totally random number

    std::uniform_int_distribution<> distribution(10, 19);

    for (int i = 0; i < 10; i++)
        std::cout << distribution(generator) << std::endl;
}

Tuesday Coding Tip 17 — Wrapping C APIs

Tue, 30 Jun 2026 09:59:00 +0000

Resource Acquisition is Initialization (RAII) is an awfully named principle saying that your class should be fully usable after construction and should clean itself up in the destructor (in other words, no (de)init methods). This principle is common in modern programming languages and is also adopted in modern C++ codebases.

But what if you work with C-like API like fopen? It returns a pointer you need to manually free before it goes out of scope. Otherwise, you leak memory and open file handles. This is where smart pointers come to the rescue as you can wrap raw pointers with them and give them custom callbacks to execute when they leave the scope.

#include <cstdlib>
#include <iostream>
#include <memory>

// MSVC disallows calling fopen
#pragma warning(disable : 4996)

void CloseFile(FILE* f)
{
    std::cout << "Closing file" << std::endl;
    fclose(f);
}

auto SafeFopen(const char* path, const char* mode)
{
    return std::unique_ptr<FILE, decltype(&CloseFile)>(
        fopen(path, mode), CloseFile);
}

int main()
{
    auto&& fp = SafeFopen("myfile.txt", "w");
    return 0;
    // Outputs: Closing file
}

Tuesday Coding Tip 16 — Creating objects in existing memory

Tue, 16 Jun 2026 09:59:00 +0000

C++ allows you to scrap your OS’ memory allocators, get yourself a huge chunk of memory and write your own allocators (they can be used with the standard library). It’s a hardcore optimization, but here’s a related tip that might be handy in normal projects as well.

When using the operator new, one can provide it with an already allocated memory, so it runs a constructor for a particular type in there. After that, reinterpret that memory as a pointer to your desired object and use it normally. However, deletion is a bit more complicated, as you have to call the destructor on that object manually (because delete must be called on the original memory, not the object).

// using some template type T
auto&& buffer = static_cast<std::byte*>(::operator new(sizeof(T)));
if (!buffer) throw std::bad_alloc();

new (buffer) T();
auto&& object = reinterpret_cast<T*>(buffer);

// ...

object->~T(); // call destructor
delete[] buffer; // properly release memory

I used this trick when implementing a resource manager that needs to hold any user data type (that is still default-constructible in my case): link

Why I Still Choose Go After All These Years

Wed, 10 Jun 2026 13:38:44 +0000

Hello everyone.

I'd like to discuss a topic that has sparked endless debates among developers for years:

What programming language should you choose for a serious project?

Throughout my career, I've worked with C, Assembly, Go, and spent a considerable amount of time exploring modern languages such as Rust and C++. The more experience I gain, the more convinced I become that there is no perfect programming language. Every language has its own strengths and weaknesses.

Despite that, I deliberately chose Go as the foundation of my primary project: ForgeZero.

ForgeZero is a cross-platform build orchestration tool written in Go, with carefully optimized performance-critical components implemented in Plan 9 Assembly to minimize runtime overhead and eliminate unnecessary allocations.

At first glance, it might seem logical that after working with C and Assembly, the next step should be Rust or modern C++, since they are widely considered the future of systems programming.

Rust

Rust solves an impressive number of memory safety problems.

Its ownership model and borrow checker force developers to think about lifetimes and resource management before the code even compiles.

However, safety comes at a cost.

There are moments when it feels like the language dictates your architecture rather than the other way around. In large projects, satisfying the borrow checker can sometimes consume more time than solving the original problem itself.

Even with Rust's strict guarantees, bugs still exist. No language can eliminate every possible programming mistake.

Personally, I also find large Rust codebases relatively difficult to read. The amount of syntax and abstractions often makes understanding unfamiliar code slower than it should be.

C++

C++ is an incredibly powerful language.

Unfortunately, that power comes with enormous complexity.

Templates, metaprogramming, concepts, multiple paradigms, countless coding styles, and dozens of ways to solve the same problem can make maintaining large codebases challenging.

Sometimes reading someone else's C++ project feels less like software engineering and more like an archaeological expedition.

C

C remains one of the greatest programming languages ever created.

It provides maximum control over the system, minimal abstractions, and extremely predictable performance, making it an outstanding choice for low-level development.

The downside, however, is responsibility.

Every pointer, every allocation, and every memory access becomes your responsibility. Bugs such as use-after-free, buffer overflows, or segmentation faults can be devastating.

And perhaps even more importantly, building large software systems in C requires an enormous investment of engineering time.

Had ForgeZero been written entirely in C, both development and long-term maintenance would have been significantly more expensive.

Why Go?

Go occupies a very unique position.

It is simple enough that new contributors can understand a codebase within days, while still being powerful enough to build serious production-grade software.

Goroutines, channels, built-in concurrency, and a minimalistic syntax allow developers to focus on solving problems instead of fighting the language.

Of course, Go has its own limitations.

The runtime, garbage collector, and automatic memory management make it a poor choice for operating system kernels, drivers, or extremely low-level software.

Yet the common belief that Go cannot deliver high performance is simply incorrect.

With careful architecture, proper escape analysis, object pooling, and manual optimization of performance-critical paths, it is entirely possible to achieve nearly zero allocations where they actually matter.

That is exactly the direction ForgeZero takes.

For me, Go represents an excellent balance between development speed, maintainability, readability, and performance.

It is not perfect.

But it allows me to build complex tooling faster than most alternatives without sacrificing quality.

That is why, after all these years, I still choose Go.

Am I Betraying C?

Absolutely not.

C shaped me as a software engineer, and I still consider it one of the greatest programming languages ever designed.

In fact, one of ForgeZero's goals is to make C development easier, improving build workflows and project management for both newcomers and experienced engineers.

Go may be my primary language today, but that does not mean abandoning C.

A huge portion of modern software infrastructure still depends on it.

Operating system kernels, drivers, networking libraries, embedded software, and countless system components have been built and refined in C for decades.

Many developers now discuss Rust's introduction into the Linux kernel and the future of systems programming.

But realistically, no major company or open-source project is going to rewrite millions of lines of stable legacy C code overnight simply because a newer language exists.

Large migrations take years—sometimes decades—and happen gradually.

For that reason alone, C will remain relevant for a very long time.

And personally, I still use it whenever it is the right tool for the job.

Recently, while training a small neural network on my home machine, I encountered an interesting problem.

The hardware is far from modern: an eight-core CPU from 2014 paired with a GTX 1060 6GB (Pascal architecture). Although training was performed on the GPU through PyTorch, the CPU was still under significant thermal stress.

Instead of building a monitoring solution in Python or deploying heavyweight background services, I wrote a small daemon in C that continuously monitored CPU temperature and automatically terminated non-essential processes once critical thresholds were reached.

Could I have written the same utility in Go?

Absolutely.

But for this particular low-level task, C was simply the better tool.

No runtime, minimal dependencies, tiny resource usage, and complete control over the operating system.

That is exactly why I never claim that Go should replace C.

Quite the opposite.

I believe that Go + C + Assembly is an incredibly powerful combination.

Go excels at infrastructure, CLI applications, automation, backend services, and distributed systems.
C remains unmatched for systems programming and direct interaction with operating system internals.
Assembly is invaluable when every CPU cycle matters and maximum optimization is required.

A good engineer should choose the right tool for the problem—not the trendiest language on social media.

My Advice for Beginners

If I had to start my programming journey again, I would begin with C.

Not because it is the "best" language, but because it forces you to understand how computers actually work.

How memory is organized.

How the stack and the heap operate.

How pointers behave.

How a compiler transforms source code into assembly instructions and eventually into machine code executed by the processor.

Once those fundamentals become clear, learning Go, Rust, C++, Java, or almost any other language becomes dramatically easier.

You stop memorizing syntax and start understanding software engineering.

So my advice is simple:

Don't be afraid of low-level programming.

Even if your future career revolves around web services or cloud infrastructure, understanding what happens beneath the abstractions will make you a far stronger engineer.

Programming languages come and go.

Fundamental computer science knowledge stays with you forever.

Tuesday Coding Tip 15 — Mathematical constants in C++

Tue, 09 Jun 2026 09:59:00 +0000

Since C++20, you can include header <numbers> and use many commonly used, precomputed mathematical constants like Pi, Phi, square root of 2 and 3, natural logarithms of 2 and 10, and many more! Even better, you can choose their precision by specifying the underlying type via a template.

And since C++17, the <cmath> header contains some special math functions I’ve never heard of like cylindrical Bessel functions, associated Legendre polynomials, or Riemann zeta function.

#include <iostream>
#include <numbers>
#include <iomanip> // std::setprecision
#include <limits> // std::numeric_limits

template<typename T>
void printConstant(T value)
{
    const auto default_precision{std::cout.precision()};

    std::cout << std::setprecision(std::numeric_limits<T>::digits10 + 1);
    std::cout << value << std::endl;

    std::cout << std::setprecision(default_precision);
}

int main()
{
    using namespace std::numbers;
    printConstant(pi_v<float>);
    printConstant(pi_v<double>);
    printConstant(pi_v<long double>);

    /* Outputs:
    3.141593
    3.141592653589793
    3.141592653589793239
    */
}

Constants are documented here: https://en.cppreference.com/w/cpp/numeric/constants
Special functions are documented here: https://en.cppreference.com/w/cpp/numeric/special_functions

How I saved my Python-to-C++ Transpiler from failing by pivoting to Gemini AI (Built 100% on Mobile)

Tue, 09 Jun 2026 09:24:42 +0000

Hey devs!
A while ago, I started building Astmize, a web tool to transpile Python code into optimized C++. In the first version, I tried building a strict AST parser. Long story short: handling type inference across languages entirely from a mobile IDE was an absolute nightmare, and I almost gave up on the project.
Instead of quitting, I decided to pivot. I completely rewrote the backend to leverage Gemini AI as the core translation engine. Now, instead of breaking on complex structures, the AI understands the logic and generates clean, optimized C++ code dynamically.
And yes, the entire stack (Frontend on GitHub Pages, Backend API on Render) was built, debugged, and deployed 100% using my phone.
Version 2.0 is officially LIVE! I'd love for you guys to break it, test it with some complex Python logic, and give me your brutal feedback.
Live Demo: [https://thespacetimedebugger.github.io/Astmize/]
GitHub Repo: [https://github.com/TheSpacetimeDebugger/Astmize.git]
Let's hear your thoughts!

I built an open-source Python to C++ AST Transpiler entirely from my phone

Tue, 09 Jun 2026 09:23:03 +0000

Hey everyone!

I wanted to share a project I've been pouring my heart into: Astmize. It's an open-source Python-to-C++ transpiler built entirely from my mobile phone (using mobile editors since I don't own a PC at the moment).

Instead of using basic regex or string replacement, Astmize parses Python code into an Abstract Syntax Tree (AST) and maps the logical nodes directly into structurally equivalent, clean C++ code.

The C++ Design Bottleneck I Had to Solve

While developing the transpiler from my screen, I hit a massive roadblock regarding type emission. As we know, C++ is statically typed and strictly forbids using auto for non-static class data members without a direct initialization expression, because the compiler must determine the exact object memory layout at compile time.

In Python, fields are dynamically assigned inside __init__ via arguments (e.g., self.speed = speed). Initially, my compiler emitted auto speed; inside the generated C++ class struct, leading to immediate compilation failures.

The Solution: Smart Type Inference Engine

To fix this from my phone, I implemented a custom Type Inference Engine in the Python backend that utilizes three core heuristics:

RHS Node Evaluation: Evaluates the Right-Hand Side assignment node to detect concrete primitive constants or explicit type initializers.
Variable Tokenization: Automatically splits attribute names by underscores and parses individual tokens against an explicit C++ type keyword library (e.g., detecting is_ or has_ prefixes infers a bool; tokenizing player_speed maps speed to int).
Safe Fallback Mechanism: If the type remains completely ambiguous, it safely defaults to int instead of emitting an illegal auto, ensuring structural layout validity and preventing compilation blocks.

The live dashboard integrates with standard GCC/Clang via the Wandbox API to compile and run the generated C++ code instantly on the fly.

Check it out here:

Live Web App: https://thespacetimedebugger.github.io/Astmize/
GitHub Repository: https://github.com/TheSpacetimeDebugger/Astmize.git

I'd absolutely love to get your feedback on the generated C++ structure, how you handle strict type emission in metaprogramming/transpilers, and if there are any C++ edge cases I should guard against!

Drop a ⭐ on GitHub if you find the concept interesting! Happy coding!

How to Fix Xcode C++ Compiler Errors in React Native (Yoga / glog / constexpr)

Sat, 06 Jun 2026 09:39:12 +0000

You just upgraded your local development environment, updated Xcode, or bumped a minor patch version in your React Native project. You open your terminal, run your standard iOS build command, and instead of a clean bundling process, the terminal throws a massive wall of raw C++ compiler text at you.

The error logs likely point to internal framework files like Yoga.cpp, glog, or the fmt library, screaming about constexpr or consteval issues, or complaining that a specific language standard identifier is missing.

This is one of the single most frustrating traps in mobile development. Your JavaScript is perfect. Your React components are clean. But your entire build is dead because an underlying C++ compilation standard is fighting your new Xcode tooling.

Why This Happens to JavaScript Developers

React Native relies heavily on a core C++ layout engine called Yoga under the hood. When Apple updates Xcode, they also update the underlying compiler tools (Clang) and shift the default C++ language dialect standard forward (for example, enforcing strict C++20 or C++23 rules).

If an older version of a library in your node_modules uses a syntax decoration that the new compiler now considers illegal or deprecated, the native compilation step fails instantly. Because most mobile developers do not actively write pure C++, looking at a raw Clang compiler failure feels like looking at alien code.

Nuking DerivedData or running pod install twenty times will not change the fact that the compiler rules have changed.

The Solution: Force the C++ Language Standard Backwards

Instead of attempting to manually modify source code deep inside your native node_modules dependencies (which will just get overwritten the next time you install packages), you can use a CocoaPods post-install hook to force the compiler to accept the specific language dialect your dependencies need to pass the check.

Open the Podfile located inside your project's native ios directory. Scroll down to the bottom where your post_install loop lives, and inject this compiler flag override block:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      # Force the compiler to use the stable C++17 standard for all sub-dependencies
      config.build_settings['CLANG_CXX_LANGUAGE_STANDARD'] = 'c++17'
    end
  end
end

By adding this configuration script, CocoaPods will automatically modify the native build files for every single sub-dependency when you run your installation pipeline, forcing Xcode to evaluate the underlying C++ libraries under a compatible standard framework.

Clear the Native Caches and Rebuild

Once the project configurations are updated, you must completely destroy the old build artifacts that were compiled under the conflicting settings, or Xcode will continue to throw the same syntax exception.

Run this quick command chain in your project terminal to wipe the native cache layers and execute a clean compilation:

# Clear Xcode's local compilation cache
rm -rf ~/Library/Developer/Xcode/DerivedData

# Re-evaluate the Podfile with the new compiler hook
cd ios
pod install --repo-update

# Return to root and boot the iOS simulator
cd ..
npx react-native run-ios

As soon as the native build pipelines evaluate your sub-dependencies through the consistent compiler standard, the cryptic layout exceptions will vanish and your bundle will build cleanly.

The 7-Zip RCE Flaw (CVE-2026-48095): Inside the Shift Loophole

Thu, 04 Jun 2026 08:46:58 +0000

The security world was recently reminded that some of our most trusted, everyday open-source tools can harbor critical flaws. A major remote code execution (RCE) vulnerability, tracked as CVE-2026-48095, was disclosed in the ubiquitous 7-Zip archive utility.

Impactful up to version 26.00, this flaw allows attackers to compromise a system simply by convincing a user to open or extract a maliciously crafted archive file.

Let’s take a look under the hood at what went wrong in the source code, why it bypassed security controls, and how to protect your codebases and infrastructure.

The Anatomy of the Bug: `NtfsHandler.cpp`

The vulnerability lies within 7-Zip's internal NTFS archive handler (NtfsHandler.cpp). 7-Zip doesn't just read basic metadata; it parses raw disk images and file system structures to extract files.

The flaw boils down to a Heap Buffer Overflow triggered by a faulty integer arithmetic operation:

The 32-bit Shift Loophole: When calculating memory allocations for compressed internal structures, the code utilizes a 32-bit shift calculation to estimate size limits.
The Under-allocation: An attacker can carefully craft an archive with anomalous data structures that cause this calculation to wrap around or truncate.
The Hijack: As a result, 7-Zip allocates a heap buffer that is significantly smaller than the incoming payload. When the data is written into memory, it triggers an out-of-bounds write. This corrupts neighboring memory objects, leading to a "vtable hijack" that redirects application control flow to malicious code execution.

Why This Evades Standard Email Filters

What makes this particularly dangerous for end-users is that it is extension-agnostic.

7-Zip identifies formats by reading the magic bytes (internal file signatures) rather than trusting the file extension. An attacker can rename a highly malicious, exploited NTFS disk image to vacation_photos.zip or invoice.7z. When a user attempts to open it, 7-Zip automatically routes it to the vulnerable NTFS parsing engine.

️ The DevOps & DevSecOps Reality Check

For developers and operations teams, bugs like this highlight a massive blind spot: Legacy third-party dependencies.

Many enterprise servers, automated CI/CD pipelines, and background microservices rely on command-line utilities like 7-Zip to extract uploaded files, process logs, or ingest data packages. If a service account running an unpatched version of 7-Zip extracts an untrusted user upload, your entire backend container or server could be compromised.

Prevention vs. Detection

When it comes to building your own file-handling logic, catching these structural mathematical errors early is critical. Running a repository scanner—like Debuggix, Semgrep, or SonarQube—as a casual part of your CI/CD pipeline helps catch integer overflows and path traversals in your own code before it gets compiled.

However, for third-party, pre-compiled desktop software like 7-Zip, repository scanners cannot intercept a compiled binary run by a user. For that, you need active patch management and software inventory monitoring.

️ How to Protect Your Systems

If you or your team use 7-Zip, you need to remediate this immediately:

Update to 7-Zip v26.01+: The patch directly modifies the 32-bit memory allocation math in NtfsHandler.cpp to prevent truncation and buffer overflows.
Audit Production Environments: Check your deployment scripts, Dockerfiles, and build servers. Ensure any automated extraction scripts are executing the updated binary.
Sanitize User Uploads: If your application allows users to upload .zip or .7z files, ensure they are unpacked in isolated, sandboxed environments with low-privilege service accounts to limit the blast radius of potential execution.

Have you audited your servers for 7-Zip versions yet? Let’s discuss in the comments how your team manages unmanaged desktop utility dependencies in production!

Tuesday Coding Tip 13 — Deleting problematic overloads

Tue, 26 May 2026 09:59:00 +0000

Suppose you have a C++ function for opening a file stream that accepts a path to a file and a string (view) with open-mode specifications (like fopen). The issue is, even though your API is strongly typed, users can still swap the arguments by accident and don’t get a compile time error, due to implicit conversions from string-like constants.

Luckily, there is an easy hack with which you can disable implicit conversions for one particular function by explicitly deleting all overloads (via auto template) and allowing just one particular version. The coolest thing is that even the return value doesn’t have to match!

#include <filesystem>

using path = std::filesystem::path;

void fopen2(const auto&, const auto&) = delete;

FILE* fopen2(const path& fp, const std::string& mode)
{
    /* dummy implementation */
    return nullptr;
}

int main()
{
    // error: call to deleted function 'fopen2'
    // note: candidate function [with auto:1 = char[11], auto:2 = char[2]] has been explicitly deleted
    fopen2("myfile.txt", "r");

    // This is ok
    fopen2(path { "myfile.txt" }, std::string { "r" });
    return 0;
}

8 Arduino coding habits that separate hobby sketches from real products

Tue, 26 May 2026 05:54:48 +0000

Most Arduino tutorials teach you to blink an LED and stop there. The jump from "it works on my desk" to "it ran for 6 months without crashing" is where most hobby projects die. Here are eight habits that get you across that gap - most of them I learned the hard way.

1. Stop using `delay()`

delay(1000) halts your entire program for a full second. Nothing else runs - not your buttons, not your sensor reads, not your serial output. Use millis() instead:

unsigned long lastBlink = 0;
const unsigned long BLINK_INTERVAL = 1000;

void loop() {
  if (millis() - lastBlink >= BLINK_INTERVAL) {
    lastBlink = millis();
    digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
  }
  // your other code keeps running here
}

Once you internalize this pattern, every project gets better.

2. Avoid the `String` class on AVR boards

String fragments the tiny heap on Uno/Nano/Mega. Your sketch runs fine for an hour, then crashes mysteriously at 3 AM. Use fixed-size char buffers:

char buf[32];
snprintf(buf, sizeof(buf), "Temp: %d C", temperature);
Serial.println(buf);

On ESP32 with megabytes of RAM, String is fine. On a 2KB AVR, it's a timebomb.

3. Wrap string literals in `F()`

Every Serial.println("Hello world") copies that string into precious RAM at boot. The F() macro keeps it in flash:

Serial.println(F("System ready"));  // costs 0 bytes of RAM

On a 2KB Uno, this single change can free hundreds of bytes.

4. Be explicit about integer sizes

int is 16 bits on AVR and 32 bits on ESP32/SAMD. Code that works on an Uno silently breaks on an ESP32 (or vice versa) because of overflow. Use <stdint.h> types:

uint8_t  pin = 7;
uint16_t adcValue;
uint32_t timestamp;
int16_t  signedTemp;

Your future self porting between boards will thank you.

5. Use `INPUT_PULLUP` instead of external resistors

You almost never need a physical pull-up resistor for a button. The AVR/ESP32 has them built in:

pinMode(BUTTON_PIN, INPUT_PULLUP);
// button pressed = LOW, released = HIGH

Less wiring, fewer parts, fewer things to debug.

6. Keep ISRs tiny and mark shared variables `volatile`

Interrupt service routines should set a flag and exit. Do the real work in loop():

volatile bool buttonPressed = false;

void IRAM_ATTR onButton() {   // IRAM_ATTR for ESP32; omit on AVR
  buttonPressed = true;
}

void loop() {
  if (buttonPressed) {
    buttonPressed = false;
    handleButton();
  }
}

Calling Serial.print() inside an ISR is a common rookie mistake - it can deadlock the whole board.

7. Model state machines explicitly

If your project has modes - idle, recording, transmitting, error - don't nest five if statements. Use an enum:

enum class State { Idle, Recording, Transmitting, Error };
State state = State::Idle;

void loop() {
  switch (state) {
    case State::Idle:         handleIdle(); break;
    case State::Recording:    handleRecording(); break;
    case State::Transmitting: handleTransmitting(); break;
    case State::Error:        handleError(); break;
  }
}

This one habit makes debugging an order of magnitude easier.

8. Enable the watchdog for anything deployed

A device sitting in your garage with no debugger needs to recover from its own bugs. On AVR:

#include <avr/wdt.h>
void setup() { wdt_enable(WDTO_8S); }
void loop()  { wdt_reset(); /* your code */ }

If loop() hangs for more than 8 seconds, the chip reboots itself. Beats driving across town to power-cycle.

A bonus: `setup()` and `loop()` are just `main()`

The Arduino IDE hides it, but underneath it's plain C++. You can - and should - define classes, split code across .h/.cpp files, and use namespaces. The .ino file is just convention.

If you want to go deeper on the jump from hobby projects to real embedded products, that's what we write about over at Make-it.ai. Tools for hardware design, project breakdowns, and lessons from makers actually shipping things in the wild.

What's the Arduino habit you wish you'd picked up earlier? Drop it in the comments - I'm curious which of these resonate and which ones people disagree with.

The Compiler Maze

Sat, 23 May 2026 21:22:29 +0000

Why Compiler is a very breathtaking project for devs and single dev

I just got into the parser stage 2 days ago and the design was flowing like a breeze. Since my compiler is focused as a system programming compiler for my custom language, I was at the type checking (local type checking) phase.

This is where I created a util.hpp file in which I wrote a namespace containing polymorphic code as it is a global type system my compiler will use to verify type at compile time.

My compiler makes sure it does everything at compile time as it really benefits — creating a custom language means you're definitely tired of the scope of the current language compiler, so that's why we're here!

Type System

The compiler tries to be ambitious like Zig and more than it, as it supports variable width types from 1 to 65535 for both unsigned and signed. I won't lie, I learned the formula for signed and unsigned, but like I said, the compiler scope got in my way: how do I store 2^65535 - 1 for unsigned value range? As we famous graphics devs and codecs know, u8 is from 0 to 255. Wait, it's unrelated.

My Ambitions

I'm a rising video codec engineer but no traditional DCT, motion vector in my vision. I did try to invent a proprietary upscaler called GVEST (Geometry Vector Expansion Spatial Transform). It's better than bilinear by a few tens of dB in edge construction without blurring, and same dB on a noisy image. If you want to see the images, I will try to upload the graph and simulation results which AI did run Python code to generate, in another Non-Compiler Series of ours. So to cut the story short, I knew entropy coding and video codecs need not just runtime precision but memory precision. And don't get me wrong — Gemini AI helped me fix the formula, as fitting the above range results from the above formula is not my path and I didn't see it coming, and I don't want another hour of burnout. I want to add theoretical bit-size memory allocation to the value of that variable bits to memory, meaning if a u8 (which is 1 byte) and the value was 5 which doesn't take the whole 8 bits or byte, why waste memory? But it's non-trivial as unpacking them will be a big fight, but I'm still going that route.

What's still breathtaking

Won't lie — I'm very ambitious. I've got so much type system, DSA to optimize at compile time. I asked AI why no language optimizes tree-based DSA as I knew little about them. All my life from JS to C++ wasn't more than structs and arrays (with vector in C++'s case). I did learn DSA in my days as a JS dev, but C++ is different in everything: containers abstraction, STL, iterators, the .data() + index, end or the .begin(), .end() — it's everywhere in C++, and beginners and experienced devs definitely still go to the docs once in a while. And honestly, the docs aren't great too.

I went through serious burnout today as I want my language, even if C++-like, to have ownership and lifetime and memory validation, if you've seen my ambition above. It will also be friendly and clear with error messages, and I'm already proud of my lexer stage error messages on my string and char warnings and recovery on unterminated literals. It's really a breathtaking journey.

Closing it all up

If you liked the architecture and insights you've seen or haven't, I welcome you in the comments section, and if you want to subscribe to my Newsletter — though it's in early stage — become my subscriber on Substack: Substack

I'm happy building the project as I'm not looking at where I am but where it's going to be. I'm breaking the LLVM oath solo, and you can too. If you follow up, everything counts for me.

Why These and That in Every System

Thu, 21 May 2026 21:25:10 +0000

We all know about DSA—Data Structures and Algorithms. But that's not all there is to programming, no matter the field. I emphasize this especially in software engineering: DSA is almost never the fix on its own.

Today marks over a week and a half on my lexer since the beginning of May 2026, when I decided to build a compiler. I've gone through different choices, code patterns, rewrites. But you know what? I didn't read a single compiler book. No Compiler Dragon Book—the bible of the field. No PDF, no 2,000 pages just to experience someone else's experience into yours.

This article isn't saying you shouldn't read books. But if you're a systems engineer like me—and my experience is pretty low, roughly 2.5 years in C++ and years in programming—we know tools aren't always the answer. In fact, DSA isn't either. This isn't about toy projects. We're talking about real production-grade projects where every performance detail and line of code must be understood perfectly, not just written pretty.

While writing the lexer in C++, coming from Rust after ditching C++ for a while, I hated my comeback. Rust's ownership model and the compiler fighting me on every borrow? I ran from it. Went back to C++ where debugging a struct—which was my token object—meant just printing fields and moving on. No lifetime elision wars, no fighting the borrow checker because my token held a reference to source text that might outlive the lexer stream. In C++, I own my memory, I leak it, I fix it. The cost is visible immediately. In Rust, the cost was hidden behind compiler errors that were technically correct but solved someone else's problem, not mine. I didn't need zero-cost abstractions. I needed to see my token struct in a debugger without wrestling with the language first.

Those questions turned out to be simple. Deceptively so.

I noticed that while having only the basics of compilers—its stages, just the prior experience (in my case: Lexer → AST → IR → Codegen)—if I had actually asked the same questions as the first person who attempted it, about its architecture, what it solves, and the coding reality... because as we all know, design doesn't map well to code. In the worst case, if we try to find the ratio, we can use only the most abstract and subtle design—not overly architected, but rearchitected through code. This is a classic system design phase, but I realized it through grit.

So the problem, which you've probably guessed, is we want to solve two problems. First: no manual assembly. Second: high-level code and its own problem—which is, how do they get back to their root?

The best approach—not the only approach, but the best—was to use what we all call a lexer today: a stream-broken, tokenized, labeled source code.

But why? Why not parse straight from the character stream? Why add a whole stage just to label things?

Because the problem isn't "how do I read code." The problem is how do I transform high-level intent into machine execution without writing machine code by hand. And that problem has two parts: the human writes symbols, the machine needs instructions. The gap between them is where every cost hides.

So you ask the two questions. First: what do I actually need to know about this source? Not "what data structure should I use"—that's the DSA trap. You don't reach for a hash map because hash maps are fast. You reach for it when your problem is "I need to check if I've seen this identifier before in O(1)." The problem first. The structure second.

Second: where does the cost arrive? Design won't show you. Design is clean boxes and arrows. Code reveals it. When I wrote my lexer, I didn't hit the cost in the diagram. I hit it when I realized a recursive descent parser trying to backtrack over raw character streams was burning CPU on re-lexing the same identifier five times. The cost wasn't visible in the "Lexer → Parser" box. It was visible in the profiler, in the branching, in the cache misses from string comparisons.

That's when the engineering choice crystallized. The lexer isn't there because compilers "should have one." It's there because tokenization is the point where you pay the string cost once, then never again. You transform the variable-length, unpredictable, cache-unfriendly character soup into fixed-size, predictable, cache-friendly labels. That's not a fancy design pattern. That's solving the first sub-problem: how do I make the rest of the pipeline fast enough to be usable?

Now, why can't the parser live in the lexer? Why not just build the AST while tokenizing?

Because the lexer solves a linear problem. It walks left-to-right, one pass, no memory of nesting depth. The parser solves a non-linear problem. Take a complex recursive function—nested lambdas, match arms, closures capturing environments. The lexer sees this:

FN  IDENT  LPAREN  IDENT  COLON  IDENT  RPAREN  LBRACE  MATCH  IDENT  LBRACE...

Flat. Stateless. A conveyor belt of labels. It has no stack to track "this brace closes the lambda, not the match arm." It cannot, by design, handle recursion because recursion requires a tree, and trees require a builder that remembers where it is in the structure.

The parser sees the same tokens, but at depth 3, inside a match arm, inside a closure, knowing exactly which brace closes which scope. The lexer sees RBRACE and thinks "end of something." The parser knows "end of match arm, inside lambda, inside function." That's the difference between a label and a structure.

Could you force the lexer to track a stack? Could you make it "smart"? Sure. Now you've merged two problems into one stage. And when that recursive function nests ten levels deep, your lexer isn't tokenizing anymore—it's predicting, it's branching, it's holding state that grows with input complexity. The cost arrives in CPU exhaustion, in stack overflows, in the maze of entry and exit points where you can't tell if you consumed the full path or just the happy path. Burnout in code, not in design.

And here's what they don't tell you: the burnout hits the engineer before it hits the machine. The junior who reads three compiler books before writing a line of code. The team that designs for 1M users at 100 users. The developer who builds a distributed system because "microservices are best practice" when a monolith would have shipped in a week. The cost arrives in the human first—in the paralysis of premature abstraction, in the exhaustion of solving problems you don't have yet. That's why these stages exist. Not because a book prescribed them. Because that problem needed that solution.

The AST exists because some problems are inherently non-linear, and pretending they're linear doesn't make them linear—it makes them expensive. The parser is where you accept that cost upfront, where you build the explicit tree, where you make recursion manageable by giving it a structure that matches its nature. The AST isn't standard because every language has different non-linear truths. SIRL's match arms with explicit types need different nodes than C's switch statements. The AST shape is dictated by what your language actually does, not by what some book says it should look like.

Same for the IR. Same for the lexer. We know the stages—Lexer → Parser → AST → IR → Codegen—but the implementations diverge because the problems diverge. A JIT compiler skips the AST for hot paths because its problem is latency, not optimization. An embedded compiler uses a different IR because its problem is register pressure, not vectorization.

This is the grit. The design phase gives you the illusion that you've solved it. The code phase reveals you haven't. Design doesn't map to code. It maps to intention. Code maps to reality. And reality is where the cost lives—in the branching, in the memory layout, in the cache lines, in the non-linear paths that design documents politely ignore.

Books give you answers to questions you don't have yet. The problem is yours; the answer should be too. Not from blind DSA application. Not from following a chapter. From asking what you actually need to know, and having the guts to let the code show you where the cost lives.

So the lexer stays dumb. The parser stays recursive. The AST stays language-specific. Not because it's elegant. Because each stage solves exactly one problem, pays exactly one cost, and exposes exactly one interface to the next stage. That's systems engineering. Not DSA for DSA's sake. Problem first. Cost second. Structure last.

And when you finally lower to IR and codegen to assembly, you've answered both original problems. No manual ASM. High-level code returned to its roots. But the path there wasn't found in a book. It was found by asking what the problem actually is, where the cost actually arrives, and having the grit to let code—not design, not someone else's experience—tell you the truth.

Two questions. Everything else is just typing.

I'm Building a Multi-Target Compiler Backend from Scratch — No LLVM, No Crutches

Thu, 21 May 2026 20:34:21 +0000

Hi there, i'm Gideon. Roughly 1.5 years of writing C++ from the ground up — ray tracers, video codecs, and now a compiler. No frameworks. No LLVM. Just me, the hardware manuals, and a lot of wrong turns.

This post starts a series where I document the build in real time. I'm currently in the parser stage. By the end, I want a compiler that emits x86-64 and SPIR-V from a C++-like language, with SIMD vectorization and security-hardened codegen baked in.

What I'm Actually Building

Not a programming language. A compiler backend toolkit — the part that turns intermediate representation into fast machine code across multiple targets.

The pipeline:

Source → Parser → AST → SSMOL (HIR) → MREL (LIR) → x86-64 / SPIR-V / ARM64 / RISC-V / WASM

MREL is my target-agnostic low-level IR. It knows about virtual registers, stack slots, and machine operations — but not physical register names. The backend handles that per-target.

Why Not Just Use LLVM?

LLVM is 4 million lines of code. It solves everyone's problem and no one's perfectly. I need:

Fine-grained control over SIMD width selection per target
Constant-time crypto primitive emission with secret register annotations
Security obfuscation passes (control flow flattening, opaque predicates)
A codebase I fully understand and can license

Building from scratch is slower. But I own every decision.

Where I Am Right Now

Parser stage. Hand-written recursive descent. C++-like syntax with:

Functions, structs, basic types
Ownership semantics (borrowed from my Rust phase, simplified)
Explicit SIMD types (v128, v256, v512)

The parser emits an AST that gets lowered to SSMOL — my high-level IR that knows about types, ownership, and semantics.

What's Next

SSMOL → MREL lowering (types to sizes, structs to offsets, control flow to basic blocks)
MREL → x86-64 backend (register allocation, instruction selection, ELF emission)
One working program: compile, link, run main() that returns 42

Then SPIR-V compute kernels. Then the rest.

What I'll Write About

Each stage, when I hit it. The problems that took me three days to solve. The specs I wrote to keep myself honest. The wrong assumptions that cost me a week.

Not polished tutorials. Build logs from someone actually building.

Follow This Series If

You work in systems, compilers, or graphics
You're curious what "building from scratch" actually looks like
You want to see if I crash or ship

My Specs (For the Curious)

I write technical specifications to keep the design coherent across months of work. The MREL backend spec covers x86-64, ARM64, RISC-V, SPIR-V, and WebAssembly with calling conventions, opcode tables, and security passes. Link in bio.

Substack: (https://ayndlr.substack.com)

Closing

This is post 1 of however many it takes. Next post: parsing expressions with operator precedence and why I gave up on Pratt parsing.

Follow for the crash or the ship. Either way, it's real.

Tuesday Coding Tip 12 — Stack trace

Tue, 19 May 2026 09:59:00 +0000

C++23 brings a new feature that I always wanted since I’ve seen it in C# — stack trace.

When combined with exceptions, it can immensely help with the analysis of user error reports, when you cannot simply attach a debugger. The code snippet shows how to create an exception class that can automatically capture stack trace at the point where it was constructed.

#include <iostream>
#include <stacktrace>
#include <stdexcept>

class stacktrace_error : public std::runtime_error
{
public:
    stacktrace_error(std::stacktrace trace = std::stacktrace::current())
        : std::runtime_error(std::to_string(trace))
    {}
};

void bar() { throw stacktrace_error(); }
void foo() { bar(); }

int main()
{
    try
    {
        foo();
    }
    catch (std::exception& e)
    {
        std::cerr << e.what() << std::endl;
        /* OUTPUTS:
        0> C:\...\Main.cpp(19): Sandbox!bar+0x44
        1> C:\...\Main.cpp(25): Sandbox!foo+0x20
        2> C:\...\Main.cpp(31): Sandbox!main+0x32
        3> D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(79): Sandbox!invoke_main+0x39
        4> D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288): Sandbox!__scrt_common_main_seh+0x12E
        5> D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(331): Sandbox!__scrt_common_main+0xE
        6> D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17): Sandbox!mainCRTStartup+0xE
        7> KERNEL32!BaseThreadInitThunk+0x14
        8> ntdll!RtlUserThreadStart+0x21
        */
    }
}

The API even allows you to iterate over each stack entry, but honestly — who needs that?

Note: Linux versions of GCC and Clang have this stupid idea of requiring you to manually link stacktrace (akin to math library), because -std=c++23 is apparently not enough of a feature flag. So don't forget to use -lstdc++_libbacktrace argument for compilation.

Building RedxChess: A Neural-Network Chess Engine with Bitboard Move Generation

Fri, 15 May 2026 11:19:04 +0000

Chess engines sit at a fun intersection — they're a classic AI problem with decades of refinement, but they're also a playground for modern techniques. I wanted to build something that respected the old guard (Stockfish-style search) while leaning on neural-network evaluation for positional judgment. The result is RedxChess, a UCI-compatible engine you can play against in the browser: https://topstar-ai.github.io/play
The stack

Python + C++: Python for the orchestration, training, and UCI protocol layer. C++ for the hot path — move generation and search.
Bitboards: Each piece type gets a 64-bit integer where set bits represent occupied squares. Move generation becomes bitwise math instead of array iteration, which is dramatically faster.
Neural-network evaluation: Replaces hand-tuned material + positional heuristics. The network scores positions; the search tree uses those scores.
UCI protocol: Standard interface, so the engine plugs into any UCI-compatible GUI (Arena, Cute Chess, lichess-bot, etc.).

Search techniques
The engine implements the modern toolkit:

Alpha-beta pruning with quiescence search to avoid the horizon effect on tactical positions
Null-move pruning — assume the opponent passes; if we're still winning, the branch is likely refutable
Late-move reductions (LMR) — search later moves at shallower depth, since they're statistically less likely to be best

What I learned

Bitboards aren't just a performance trick — they make certain rules (attacks, pins, castling rights) cleaner to express than mailbox representations.
Wiring a neural net into the search is mostly a latency problem. Evaluation calls dominate runtime, so batching and quantization matter as much as the architecture.
UCI is delightfully boring. Once it works, every chess tool in the world becomes a debugger.

Try it
Play here: https://topstar-ai.github.io/play
Happy to dig into any of the search or evaluation details in the comments. If you've built an engine, I'd love to hear what you'd do differently.

chess-engine, ai, python, cpp, neural-networks, bitboards, game-development

Tuesday Coding Tip 10— CTest

Tue, 05 May 2026 09:59:00 +0000

CMake can do many things and instrumenting your test suite is one of them. Use add_test to tell cmake it should run a particular command with given parameters. If it returns zero, it succeeded. You can use it to simply run a testrunner binary or to make a matrix of input parameters that are expected to not crash the program.

cmake_minimum_required ( VERSION 3.26 )

project ( testrunner )
add_executable ( ${PROJECT_NAME} Main.cpp )

enable_testing()
add_test(
   NAME "Example with no params"
   COMMAND ${PROJECT_NAME}
)

add_test(
   NAME "Example with help param"
   COMMAND ${PROJECT_NAME} -h
)

In order to add_test do anything, one has to also call enable_testing(). Running the tests is just a matter of running ctest from command line. Just note that ctest requires you to specify a build configuration if you have more than one.

Tuesday Coding Tip 09 — Source location

Tue, 28 Apr 2026 09:59:00 +0000

If you want to log a filename and line number prior to C++20, you need to use the likes of __FILE__ and __LINE__ macros. To use those easily, you have to create a wrapper macro for logging, which usually leads to an ugly macro bonanza.

#include <iostream>
#include <format>

void log(
    const std::string& message,
    const std::string& fileName = __FILE__,
    unsigned lineNo = __LINE__)
{
    std::cout << std::format(
        "{}({}): {}\n",
        fileName,
        lineNo,
        message);
}

#define LOG(msg) log(msg, __FILE__, __LINE__)

int main()
{
    log("hello world");
    // logs: example.cpp(7): hello world
    // Note that __FILE__ and __LINE__ are expanded at their
    // position, not at the callsite
    LOG("hello world2");
    // logs: example.cpp(22): hello world2
    // Wrapping the call in another macro with explicit placement
    // of __FILE__ and __LINE__ makes them expand at the correct place
}

C++20 introduces std::source_location, a regular object that can be constructed as a default value of a logging function parameter and passed along as the user needs.

#include <iostream>
#include <source_location>
#include <format>

void log(
    const std::string& message,
    std::source_location location = std::source_location::current())
{
    std::cout << std::format(
        "{}({}) {}: {}\n",
        location.file_name(),
        location.line(),
        location.function_name(),
        message);
}

int main()
{
    log("hello world");
    // logs: example.cpp(19) int main(): hello world
}

UltrafastSecp256k1 v3.67.0

Wed, 22 Apr 2026 09:10:44 +0000

v3.67.0 — CAAS hardening, multi-CI reproducible builds, OpenSSF Scorecard cleanup, Zenodo + funding outreach
This release closes the remaining CAAS gap-closure roadmap, lands the multi-CI reproducible-build attestation surface, brings the OpenSSF Scorecard code-scanning queue to zero open alerts, and pre-stages Zenodo metadata + a funding-outreach playbook. No public-API or ABI breakage; no behavioral changes to the crypto engine.

Highlights
Continuous Audit (CAAS) — roadmap complete
All eleven CAAS hardening items (H-1 … H-11) closed in a single sweep.
Gap-closure roadmap G-1 … G-10 closed: threat model, RNG entropy attestation, hardware side-channel methodology, compliance stance, INTEROP matrix, multi-CI reproducible builds, CT-tool independence, SPEC traceability matrix, protocol spec, traceability-join gate, RFC 9116.
scripts/audit_gate.py now wires G-1 / G-1b / G-8 / G-10 as first-class sub-gates; caas_runner.py is fail-fast across all five stages.
scripts/check_exploit_wiring.py enforces the Exploit / Audit Test Conversion Standard at CAAS Stage 0 — every audit/testexploit*.cpp file must be wired into unified_audit_runner.cpp or the gate refuses the push.
Audit dashboard refreshed: hardening progress 12/12 (100%).
Multi-CI reproducible-build attestation
.gitlab-ci.yml and .woodpecker.yml (Codeberg) added alongside the existing GitHub Actions surface — the same release artifact is now built on three independent CI providers and verified byte-identical via SHA-256.
docs/MULTI_CI_REPRODUCIBLE_BUILD.md documents the protocol; docs/SUPPLY_CHAIN_LOCAL_PARITY.md describes the local-parity check.
INTEROP differential testing
First INTEROP §2 reference wired: OpenSSL 3.x random-vector differential PoC (audit/test_exploit_differential_openssl.cpp), advisory module, host-only.
INTEROP §3 closure tracked for k256 (Rust), btcd (Go), BoringSSL, WolfSSL, NSS, MuSig2 wire, FROST wire.
OpenSSF Scorecard — code-scanning queue cleared
All open code-scanning alerts on main resolved.
PinnedDependenciesID (6): every GitHub Action pinned by 40-character SHA in mutation-weekly.yml, rocm-smoke.yml, and formal-verification.yml; pip installs in those workflows switched to pip install --require-hashes -r ... against new hash-pinned requirement files.
TokenPermissionsID (1 fixed in code): caas-evidence-refresh.yml top-level contents: write dropped to read; write retained only at the job level where the workflow actually pushes refreshed evidence back to dev.
Six remaining TokenPermissionsID alerts dismissed as legitimate job-scoped writes (release sync-docs, audit-report publish to gh-pages, bench-regression baseline push, three ClusterFuzzLite SARIF uploads).
BranchProtectionID resolved at config level: main-protection ruleset hardened — bypass_actors=, required_approving_review_count=2, require_code_owner_review=true, require_last_push_approval=true, dismiss_stale_reviews_on_push=true.
Crypto bug-pattern scanner
13 CVE-grounded pattern checkers added to scripts/dev_bug_scanner.py (timing-dependent branches on secret data, missing zeroization, RFC 6979 misuse patterns, ECDSA nonce reuse signatures, scalar-mod-n omission, …).
False-positive reduction pass across eight checkers; investigation report at docs/SCANNER_INVESTIGATION_REPORT.md.
GPU backend parity
schnorr_snark_witness_batch parity gap closed via deterministic host-side CPU fallback in gpu/src/gpu_backend_fallback.cpp — CUDA, OpenCL, and Metal now all return correct byte-identical results. Native GPU kernels remain a future optimisation; public-data-only operation.
Cross-compile / CI fixes
arm64 + riscv64 cross-compile no longer picks up host OpenSSL headers via bare has_include. The OpenSSL gate is now driven by a CMake UFSECP_HAVE_OPENSSL=1 define that is only set when find_package(OpenSSL) actually links — the source guard requires both the define and has_include.
-Werror build no longer trips on OpenSSL EC_KEY deprecation warnings (pragma block scoped to the differential PoC).
CAAS verdict accepts both PASS and PASS with advisory.
Visibility surface
.zenodo.json added — academic metadata staged for the next release; the next release-tag push will trigger Zenodo archival and DOI minting (Zenodo↔GitHub OAuth toggle is enabled).
README.md "Cite this work" section + DOI badge placeholder.
CITATION.cff linked from "Where to Start"; docs/ADOPTION.md and docs/FUNDING_TARGETS.md linked next to it.
docs/FUNDING_TARGETS.md — funding playbook covering Bitcoin grant programmes (HRF, OpenSats, Brink, Spiral, Strike Catalyst, MIT DCI), Ethereum programmes (EF ESP, Protocol Guild, EF Academic, Optimism RetroPGF, Arbitrum, Coinbase / Base), EU / cross-cutting (NLnet NGI Zero, Sovereign Tech Fund, OSTIF, GitHub Accelerator, a16z crypto Open Source Grants), with 30-second + 5-minute pitches and an evidence-pointer column.
README.md hero block now carries explicit CTAs: a one-line invitation for production users to PR themselves into docs/ADOPTION.md, and a one-line pointer for prospective sponsors to docs/FUNDING_TARGETS.md.
Documentation reconciliation
Exploit-PoC counts reconciled across all audit docs to the real number (189).
Non-exploit module + CI workflow counts reconciled to reality.
docs/SPEC_TRACEABILITY_MATRIX.md paths reconciled; traceability-join gate flipped to strict by default.
Compatibility
C ABI: unchanged.
Public C++ API: unchanged.
GPU backend GpuBackend virtual interface: one method (schnorr_snark_witness_batch) gained a deterministic CPU fallback; previously returned Unsupported on every backend.
Reproducible build: byte-identical to v3.66.0 for the engine + library outputs; only CI / docs / audit-tooling surface changed.
Adoption
Sparrow Wallet Frigate ships UltrafastSecp256k1 by default since 1.4.0. See docs/ADOPTION.md for the integration details and Craig Raw's independent benchmarks.

Cite this work
This release will be archived on Zenodo with a DOI assigned automatically once the tag push completes. See .zenodo.json and CITATION.cff.

https://github.com/shrec/UltrafastSecp256k1/releases/tag/v3.67.0
https://github.com/shrec/UltrafastSecp256k1

Tuesday Coding Tip 08 — Explicit template specialization

Tue, 21 Apr 2026 09:59:00 +0000

While template instantiation can be used to move your template implementation from header files to object files for a given subset of types, specialization allows you to override the default template implementation for a particular type.

Specialization requires that you first define the template implementation and then you can implement any number of specializations for given types. This way, you can override free functions (while maintaining their overall signature) or you can override whole classes (and you don’t have to respect their interfaces). This way, you can create drop-in replacements for library containers specialized for particular types and try to optimize them for your use case.

#include <filesystem>
#include <iostream>
#include <string>

template<class T>
T concat(T a, const T& b)
{
    return a + b;
}

namespace fs = std::filesystem;

fs::path concat(fs::path a, const fs::path& b)
{
    return a / b;
}

int main()
{
    using namespace std::string_literals;
    std::cout << concat("aaa"s, "bbb"s) << std::endl;        // outputs: aaabbb
    std::cout << concat("aaa", "bbb").string() << std::endl; // outputs: aaa\bbb
    return 0;
}

The specialization can also be partial and it can be inline/const whatever even if the original template is not.

#include <iostream>
#include <string>

template<class T>
struct CustomType
{
    T foo() { return T {}; }
};

template<>
struct CustomType<std::string>
{
    std::string bar() { return "hello world"; }
};

int main()
{
    CustomType<int> ct1;
    std::cout << ct1.foo() << std::endl; // outputs: 0
    CustomType<std::string> ct2;
    std::cout << ct2.bar() << std::endl; // outputs: "hello world"
}

Last but not least, if you’re implementing a template and need to change only a few lines of implementation for one particular type, you don’t need specialization. Instead, use constexpr conditions — they are evaluated in compile time and optimized away when the compiler emits its own specialized code.

#include <concepts>
#include <filesystem>
#include <iostream>
#include <string>

template<class T>
T concat(T a, const T& b)
{
    if constexpr (std::is_same_v<T, std::filesystem::path>)
        return a / b;
    else
        return a + b;
}

int main()
{
    using namespace std::string_literals;
    using path = std::filesystem::path;
    std::cout << concat("aaa"s, "bbb"s) << std::endl; // outputs: aaabbb
    std::cout << concat(path{ "aaa" }, path{ "bbb" }).string()
              << std::endl; // outputs: aaa\bbb
    return 0;
}

Coder Legion - Recent posts tagged cpp

Tuesday Coding Tip 27 — Aliasing and ‘using’ in C++

The missing break behind Digimon World’s evolution rules

tags: reverseengineering, c, gamedev, cpp

The missing break

The scoring system: four checks, three needed

Care mistakes, and the flag that inverts them

Weight is a window, not a floor

Stats, where the stage changes the rule

The bonus point: any one of five

The rule that quietly steers your collection

Who actually did this

Running their code somewhere it has never run

Measuring the GTE instead of guessing at it

Where I got things wrong

What this does not prove

What we finally understand

I Built a C++ CLI That Hunts Down Secrets Hiding in Your Git History

What it does

Key features

Example output

Getting started

Why C++20

Try it out

Update - Sep 3:

I Tried to Build Persistent Compute on an Xbox SSD. The Failed Tests Changed the Architecture.

The problem wasn't just memory capacity

First, I investigated the Xbox process model

The first failures weren't even storage failures

The second process became a coordinator

Next, I needed storage that could survive failure

Then I tried breaking it

Running computation through persistent storage

The first uninterrupted runs passed. Restart failed.

Eight gigabytes, and another failed experiment

The 64 GiB attempt was refused

The result: worker 0.1.160.0

What this proves, and what it doesn't

Why the failed tests mattered more than the number

The code is now open source

Beyond the SSD experiment

How a single 1-bit shift bug stayed hidden in NASA's communication protocol for years.

Write C++ like it's SQL

Tuesday Coding Tip 25 — User-defined literals

Semantic Search in C++ without Python, libtorch or ONNX Runtime

canonical_url: https://kjarni.ai/blog/cppinference/

How semantic search works

What you actually link against

Errors are values

Searching a corpus

Classification and reranking

The same numbers in every language

Choosing a model

Practical notes

If you are on C++11 or C++17

Compared to the alternatives

Getting it

Other Resources

Tuesday Coding Tip 24 — Getting template type from an existing object

Tuesday Coding Tip 23 — CMake configure_file

Embedding a web UI into a native desktop application comes with a price

macOS 🍎

Linux 🐧

Windows 🪟

Meeting in the middle

Tuesday Coding Tip 22 — Compile-time computing

ForgeZero: What Happens When Someone Finally Stops Forgiving Your Build System

The Thesis, Stated Plainly

The Pipeline as a Chain of Owned Transformations

Who This Was Actually Built For

Cache Identity: The Part Everyone Gets Wrong

Two Hashes, One Honest Boundary

Below the Go Standard Library: The Discovery Layer

io_uring, Used Honestly

Linking, Scheduling, and the False-Sharing Detail Most Projects Never Bother With

Gloria: The Language That Refuses to Hide Anything

Security as a Neighbor, Not a Costume

The Redis Case Study, Read Correctly

Cross-Platform Without Pretending Every Platform Is the Same

The Installer Nobody Notices Until It Breaks

When Is `tag_invoke` a Good Fit?

Prefer `tag_invoke` when:

Generation 1: Class Template Specialization (`std::hash<T>`)

Generation 2: Raw ADL & The "Two-Step Dance" (`swap`)

The `tag_invoke` Protocol (P1895R0)

A Pedagogical `tag_invoke` Dispatcher

Defining a CPO with `tag_invoke`

Sender/Receiver: Why `tag_invoke` Was Attractive—and Why P2300 Moved Away

The Retreat: Why P2300 Replaced `tag_invoke`

Barry Revzin's Critique: `tag_invoke` Is Not a Trait System

What `tag_invoke` Deliberately Does Not Solve