Essentially, a Scala object is a singleton class, and it comes with two methods you can define that - weirdly enough - can be used used for custom pattern matching:

object CustomerID:

  def apply(name: String) = s"$name--23098234908"

  def unapply(customerID: String): Option[String] =
    val stringArray: Array[String] = customerID.split("--")
    if stringArray.tail.nonEmpty then Some(stringArray.head) else None

val customer1ID = CustomerID("Sukyoung")  // Sukyoung--23098234908
customer1ID match
  case CustomerID(name) => println(name)  // prints Sukyoung
  case _ => println("Could not extract a CustomerID")

This caught me by major surprise as I was not aware any language yet had a way to support first-class pattern matching to any extent.

I was even more surprised to then learn that something similar is also supported in Haskell:

{-# LANGUAGE PatternSynonyms #-}
{-# LANGUAGE ViewPatterns #-}

-- A space is used instead of `--` because Haskell's
-- standard library has no `splitOn` function :(
applyCustomerId :: String -> String
applyCustomerId name = name ++ " 23098234908"

unapplyCustomerId :: String -> Maybe String
unapplyCustomerId str = case words str of
  (name:_) -> Just name
  _ -> Nothing

pattern CustomerId :: String -> String
pattern CustomerId name <- (unapplyCustomerId -> Just name)

main = case applyCustomerId "Sukyoung" of
  CustomerId name -> putStrLn name
  _ -> putStrLn "Could not extract a CustomerID"

I do like the Haskell approach much more than Scala’s since it makes the “pattern” more obvious via the pattern keyword and specific <- (f -> x) syntax.

But it still isn’t quite satisfactory.

The is operator

Suppose Haskell had an operator that could pattern match on a value as a boolean expression:

isCustomerId :: String -> Bool
isCustomerId str = safeHead (words str) `is` (Just _)

Right now, the CustomerId pattern is checked like unapplyCustomerId -> Just name, but if the function before the -> were to always return a boolean anyway, then we could simplify this syntax:

pattern CustomerId :: String -> String
pattern CustomerId name <- isCustomerId

And the compiler would know what to bind name to as it could check where pattern matching occurs within isCustomerId, which in this case is via the is operator.

Well, I’ve been designing a language that happens to already have such an is operator, and so I was able to come across this solution naturally. Here’s how you’d define it:

def CustomerId #= subtype[String]

impl From[String, U64] for CustomerId:
	static def from #= fn(name # String, id # U64) -> Self:
		"${name}--${id}"

impl Match[String, U64] for CustomerId:
	def is #= fn(&self, name # String, id # U64) -> Bool:
		self.splitAt("--") |> @.length is 2
			and @.at(0) is name
			and U64::from(@.at(1)) is id

First off, this language is in its very early stages of design, and so a lot of the syntax is subject to change. Those who have used Rust before, though, should be familiar with the impl definition where we implement the From and Match traits for our CustomerId subtype.

A subtype differs from a type in that it does not wrap the underlying data. Instead, the data can be accessed directly and all of its properties and functions are still available to access - i.e., "Foo-1801" is CustomerId("Foo-1801"). It is also possible to impose restrictions on the input values, but that’s a topic for a different article.

The From trait works very much like it does in Rust where it allows you to call CustomerId::from() on data that isn’t implicitly convertible to a String. The Match trait, however, is something new. It allows you to overload the is operator for a particular type and set of parameters.

In pratice, it is used like this:

if CustomerId::from("Jeff", 19970823) is
	| CustomerId("Kojo", 20060717):
		echo("You must be Kojo Bailey!")
	| CustomerId("Jeff", _):
		echo("Woah! Jeffs are banned from this company!")
	| CustomerId(_, def id):
		echo("Welcome patient ${id}!")
	| _:
		echo("Your ID appears to be invalid...")

Not particularly complicated, really. There are some rules to keep in mind though:

-- Compile Error: Left side must be a value.
CustomerId(name = "Kojo", id = 20060717) is "Kojo--20060717"

-- Compares value to value.
CustomerId::from(name = "Kojo", id = 20060717) is "Kojo--20060717"

-- Compares value to pattern.
"Kojo--20060717" is CustomerId(name = "Kojo", id = 20060717)

-- Compares value to value.
"Kojo--20060717" is CustomerId::from(name = "Kojo", id = 20060717)

And that’s it! The is operator helps to keep things very simple.

You might be wondering though, how exactly does the compiler know what values to bind to from the is overload? To help answer that question, first have a look at this comparison with if the language did not have an is operator and instead had to rely on a classic match expression:

def is #= fn(&self, name # String, id # U64) -> Bool:
    self.splitAt("--") |> @.length is 2
        and @.at(0) is name
        and U64::from(@.at(1)) is id

def match #= fn(&self, name # String, id # U64) -> Bool:
    def strArray #= self.splitAt("--")
    if str.length != 2: return False
    match (strArray.at(0), U64::from(strArray.at(1))):
        (name, id) -> True
        _ -> False

The compiler should be able to deduce what both name and id bind to based on what they pattern matched against. To write it in a way that is even clearer:

def is #= fn(&self, name # String, id # U64) -> Bool:
    self.splitAt("--") |> @.length is 2
        and (@.at(0), U64::from(@.at(1)))
            is (name, id)

However, the compiler also needs to enforce that each argument that could bind is used exactly once an only in an is expression. Any other case would either cause other issues or just not be very useful anyway. I do admit that having these implicit compiler restrictions isn’t ideal and I will continue to look for possible alternatives that may feel more intuitive, but at the very least, it wouldn’t be hard for the programmer to learn given the compiler should give useful error messages.

What Haskell does with its (f -> x) syntax is very robust since it restricts you from misusing the binding arguments; the syntax is just quite confusing in my opinion. This is largely how Haskell quite frankly “cheats” via its type signature grammar:

pattern CustomerId :: String -> String
pattern CustomerId name <- (unapplyCustomerId -> Just name)

This pattern’s type is written as String -> String, but that is not accurate considering it does not take a string and then return a string. Haskell having its type signatures separate from its definitions means it can get away with this, whereas you would struggle to make the type annotations inline:

pattern CustomerId (name :: String) (input :: String) =
  (unapplyCustomerId input -> Just name)

This is already dodgy, and what exactly would its return type even be? A boolean? Because that would just get us to where I am currently.

Conclusion

Regardless, I think this is very interesting (to put it lightly) and I hope I or someone else can think of an elegant solution in the not-so-distant future.

This has been by first blog post on this new language I’m designing, and I look forward to sharing more of it. My dissatisfaction with existing programming languages has pushed me to a point where I want to focus solely on developing this language until I have it implemented so that I can use it! Whether or not it will finally satisfy my needs remains to be seen… but I am optimistic.

I remember it immediately stuck out to me for having seemingly Python-like syntax while promising high performance as a systems language. I am constantly thinking about ways that programming languages can be made more ergonomic, so naturally, I get very excited when I come across a language that actually strays from typical C-like syntax. Right now, I’m very excited to see how Mojo develops!

I was also intruiged by how the language can be garbage collected yet also supports custom allocation and memory management strategies. Although I’m not experienced with things like custom allocators, I do primarily come from a C++ background, and so I’m not too keen on using garbage collected languages - it’s why I’m yet to really give Go a go.

Having recently finished an implementation of Pong in Odin , I was left rather disappointed and was craving something more interesting. And so I pulled up my list of languages to try out and saw Nim towards the top of the list. As such, I decided to program another classic game, Snake , with the help of Raylib . In particular, I used Naylib , a wrapping for Nim that conforms to its style.

In this article, I’ll to go over my thoughts about the language after having used it for a whopping 4 hours, and explain why I probably won’t be using it again anytime soon!

First Impressions

Before I got started with my Snake project, I first installed the Nim compiler and toolchain - including its package manager, Nimble - and compiled a hello world program as I typically do when I install a new language:

echo "Hello from Arch Linux Hyprland!"

How succinct! Although I must say, I don’t get the appeal of using echo over print. Maybe it’s to help emphasise the Bash-like command syntax. I am a fan of said syntax though, especially coming from Haskell . It’s just as clean as it gets really.

Entry Point

I don’t feel particularly strong on the absence of an explicit main function. Conventionally, main is handy for finding the entry point of a program, of course, but it’s not that much more difficult to navigate without it. Plus, if you do feel strongly about it, you can always define a custom entry point, even if just for some organisation.

proc main() =
    echo "echo"

main()

The lack of main also means you need to read command-line arguments via the std/os module, and you likewise can’t just return an exit code like you would in C. Thing is, these conventions are seemingly being abandoned anyway, with both Rust and Zig treating main as void and processing command-line arguments via library functions. Plus, the entry point being the top of the file itself is something Python programmers will already be familiar with, so really it’s leaving one convention for another.

Procedures vs Functions

What many will be less familiar with, however, is the proc keyword - “procedure” rather than “function”. Well, except Nim does have functions, but they are reserved for the more mathematical concept of a pure function that has no side effects . I first saw proc used in Odin, and I’m glad that Nim also makes the distinction between a process and a function.

That being said, I am weary of how pure functions can get in the way of debugging. The thing that made debugging logic errors in Haskell so hellish was the inability to print without changing the function’s signature from pure to IO (). Thankfully, Nim actually does have a solution in the form of debugEcho - an echo treated by the compiler as if it has no side effects.

func foo() =
    echo "caw" # Compile error
    23
    
func bar() =
    debugEcho "caw" # A-OK
    67

It comes across as a bit hacky, but I appreciate it all the same. Perhaps all the hype around pure functions will one day lead to good debugging for them becoming mainstream, preferably built into compilers.

Implicit Result

You will also notice that Nim supports implicit returns when you end a procedure with an expression, like Rust. Well, this is partially true, as Nim also has a feature that I actually also thought of myself a while ago, and I was surprised to actually see implemented in a popular language:

import std/math

func quadratic(a, b, c: float64): float64 =
    result = sqrt(pow(b, 2) - 4 * a * c)
    result += b
    result /= 2 * a

echo quadratic(1, 5, 6)

Here, result is an implicit variable for the result of a non-void procedure. And it does genuinely have its uses - for example, here’s how I used it in a “constructor”:

proc newSnake(startPos: Vector2): Snake =
    result.head = addr result.body[0]
    result.length = 1
    result.head.position = startPos
    result.head.direction = right

Keywords vs Symbols

Notice how I get the address of result.body[0] via the addr keyword rather than a symbol like &. The same is true for pointer types being denoted via ptr rather than a * or ^. And yet, in order to reference a pointer, you use [] rather than a keyword…

var a: int = 23
var b: ptr int = addr a
b[] += 3

echo a
echo b[]

…something which I find rather strange. It is consistent with indexed dereference syntax for arrays though, if you think of arrays as pointers. Issue is, arrays aren’t just pointers, and [i] semantically means “get the element at this index of this list container”, which is why it is used for more than just pointers in most languages.

And weirdly (and I can’t wrap my head aroud this), Nim then uses the * to… denote members as public within modules.

type
  Person* = object # Person is visible to other modules
    name*: string  # name is visible to other modules accessing Person

I’m not sure how this is better than public, let alone the more concise pub. I didn’t end up splitting my project into modules though, so maybe there’s some nuance I’ve missed.

Nim also replaces && with and, || with or, and ! with not, although still uses != (!+=) for “not equals”. I am a fan of this, and have even considered using this convention in my C++ code since C++ does in fact support operator alternatives , including not_eq for !=. Whether or not to use != is quite a dilemma since, on one hand, cool fonts (like on this blog) can change it to a long equals with a slash through the middle, but it will normally be displayed as a !+= which may leave a programmer wondering why ! is used to mean “not”, and creates friction if the ! operator is to be repurposed for something else.

One such solution is to simply not support it and instead require expressions like not (5 == 3), but that can be quite cumbersome. You could also instead use /= as seen in Haskell, but this conflicts with divide-equals, and would therefore also impact +=, -=, and *=. Two other symbols that could actually work are \= and =/= (=+!+=), the latter of which is used in Erlang for strict equality.

Generally though, I do like the idea of using keywords over symbols like &&, ||, and !, especially since the words and, or, and not are only 2-3 letters long anyway. Then, I’d finish off by replacing != with =/= or something. I also don’t mind the use of ptr, addr, and ref keywords for similar reasons, but really that comes down to how often you use raw pointers and access addresses in the language. A language like Rust that uses & to denote borrowing should absolutely use a special symbol over a keyword due to the sheer frequency of it use, and that’s a general rule that can be applied to symbols in all languages - if it is extremely common, make it quick-n-easy to type.

Variables, Constants, and… Lets?

Nim supports 3 ways to bind values to names:

var a: int = 3
const b: string = "foo"
let c: float = 4.2

var defines a mutable variable as you would expect, but both const and let define immutable bindings. The difference is that const is analogous to C++’s constexpr in that a const value must be known at compile-time. My main issue with this is its inconsistency when read. a is a var. b is a const. But c is a… let? Rust suffers from the same issue since, although it uses let and let mut, it also supports const for compile-time constants.

Really, I don’t see why there particularly needs to be a distinction, as the compiler should be able to deduce from context whether an immutable binding can be known at compile-time or not - I mean, hell, it literally has to check in order to report an error when you try marking something runtime as const. To my knowledge, Zig is an example that doesn’t make a distinction, yet allows you to force compile-time evaluation via comptime:

comptime const x = foo();

But there is an argument for more explicit contracts being better for communicating programmer intent. In that case, I will shoutout Odin’s syntax for defining compile-time constants, especially as it’s consistent with the language’s syntax for defining procedures, structs, and others:

package main

import "core:fmt"

msg :: "hello"

main :: proc() {
    fmt.println(msg)
}

In general though, I think I’ve come to appreciate and prefer let and let mut over var and const. It means there’s an expectation for everything to be constant unless you define it as mut - the inverse of C++’s situation with its const keyword - and means that if you forget to mark something as mut, you either get told by the compiler or accidentally get the better result anyway. It also just semantically signifies that you can make something mutable later if needed, whereas changing a const to var can feel more… impactful, in a way that’s hard to put into words. You could argue that it’s better for it to feel more impactful and that Rust in general struggles with making bad decisions feel too easy (another example is the ? operator and .unwrap()), but that’s a whole post in of itself, I think.

I will mention though - I find there’s currently a disconnect between how we define bindings in source code and how they actually get mapped in memory, if mapped at all. For example, consider the following snippet:

const X = 5;
println!("{}", X + 3);

Under normal circumstances, there is no way that X here is stored as a binding in memory. Instead, it is certainly made inline at compile-time, and then further used to evaluate X + 3 = 5 + 3 = 8 as well, so 8 (or even "8") just becomes hard-coded into the machine instructions. For reasons I can’t quite define, it feels ill-fitting to refer to X as a “constant”, and maybe inline would be more fitting, although then what if you have a const array that is actually stored in memory at runtime? This is something I want to think more on, but for now, I can say that Odin’s x :: 5 speaks to me for this reason, and may be worth exploring in more depth.

Implicit Namespacing

I just had to mention this briefly, because I love it when languages support the following:

type Direction = enum
    up, down, left, right

proc advance(direction: Direction) =
    case direction
    of    up: snake.position.y -= 1
    of  down: snake.position.y += 1
    of right: snake.position.x += 1
    of  left: snake.position.x -= 1

advance(up) # Direction.up
advance(left) # Direction.left

iirc OCaml supports this (to an extent), and I really wish Rust and other languages did too… I’d imagine the effects on compilation time are minor, meanwhile the ergonomics are insane. The same goes for namespacing in general, as Nim doesn’t require you to prefix imports with the library name. It’s why I was able to use Raylib like so:

while not windowShouldClose():
    beginDrawing()
    clearBackground(Black)

    if isGameOver:
        if isKeyDown(Enter):
            reset()

Rather than something like:

while not rl.windowShouldClose():
    rl.beginDrawing()
    rl.clearBackground(rl.Color.Black)

    if isGameOver:
        if rl.isKeyDown(rl.KeyboardKey.Enter):
            reset()

It seems unimportant at first, but the improvement on readability is honestly more significant than is often acknowledged.

Yes, namespace conflicts are an issue, but the habit of prefixing literally everything with a namespace - even stuff from the standard library - is very much due to C++’s issues with #include. In a language where you can control what you import from a module and even specify your own namespace for it independent of what the module specifies, I don’t believe the habit is necessary. Rust code uses Vec over std::Vec, Zig allows custom namespaces via const whatever = @import("std"), and Go just uses the package name as the qualifier even with its standard library, like with fmt.Println.

Significant Whitespace

On the topic of readability, I have found that I am a big fan of significant whitespace. Consider this code snippet in Nim:

if not isGameOver:
    snake.updateDirection()
    if getTime() - lastTick >= tickRate:
        snake.advance()
        snake.checkCollision()
        if snake.head.position == apple.position:
            apple.goToRandPos()
            snake.grow()
        lastTick = getTime()

    apple.draw()
    snake.draw()

    let scoreStr = $score
    const scoreFontWidth = 60
    drawText(scoreStr, centerTextHorizontal(scoreStr, scoreFontWidth), 40, scoreFontWidth, White)

endDrawing()

And how it would look without significant whitespace:

if not isGameOver {
    snake.updateDirection();
    if getTime() - lastTick >= tickRate {
        snake.advance();
        snake.checkCollision();
        if snake.head.position == apple.position {
            apple.goToRandPos();
            snake.grow();
        }
        lastTick = getTime();
    }

    apple.draw();
    snake.draw();

    let scoreStr = $score;
    const scoreFontWidth = 60;
    drawText(scoreStr, centerTextHorizontal(scoreStr, scoreFontWidth), 40, scoreFontWidth, White);
}

endDrawing();

You may be inclined to disagree, but I personally do not find that the braces {} and semicolons ; help with readability. If anything, they add visual noise and make it harder to read, and make writing code more prone to errors that waste compilation cycles.

You will also notice that despite using braces, we still conventionally use the same indentation; and despite using using semicolons, we still conventionally put statements on the same lines. And that is only by convention, which can of course be ignored.

A key benefit of significant whitespace is that it forces code to be much more uniform, which is something to be appreciated. It’s the reason that many modern languages enforce formatting rules despite them not benefitting the compiler. And while I understand that significant whitespace is more difficult to parse, modern computer hardware should be at the stage where the impact on compilation times is minimal, or so I assume given languages like Python, Haskell, and Nim exist.

However, Nim also opts to force spaces over tabs which I am less happy about. I don’t see same-width indentation being particularly important - I didn’t like it in Haskell either, and my opinion wouldn’t change unless I see examples of where it actually matters for readability. Instead, I’d advocate for enforcing tabs. Really, it’s just an accessibility feature that allows people to personally customise their tab widths when reading anyone’s code.

camelCase

Speaking of spacing, camelCase has grown on me due to its compactness. Initially, especially due to coming from C++, I hated camelCase and much preferred to use snake_case, going out of my way to use it in Unity with C# for a while before realising I was fighting the compiler and causing myself unnecessary aids.

Since then, I’ve come to actually like camelCase simply because it is much more compact than snake_case. This has become particularly true as a result of me trying to use better variable names. For example, go_to_rand_pos() becomes goToRandPos(), and is_game_over becomes isGameOver.

Perhaps you do not see the appeal, but is it not strange that even in languages like C++, programmers opt to use PascalCase for things like user-defined types? You almost never see Whatever_This_Case_Is_Called because it looks quite weird. It also means that the underscore _ can be reserved for something else in identifiers, although I can’t imagine what right now.

The only real annoyance with camelCase is in the less-rare-than-you’d-expect instances where you want to add/remove a word at the start of an identifier, like position to newPosition. It’s minor, but worth mentioning.

Object-Oriented Programming

So far, I’ve had a lot of good things to say about Nim. But unfortunately, this negative is a real deal-breaker for me, and honestly makes me quite sad :(

type Snake = object
    head: ptr SnakePiece
    body: array[0..512, SnakePiece]
    length: uint32
    oldDirection: Direction

proc newSnake(startPos: Vector2): Snake =
    result.head = addr result.body[0]
    result.length = 1
    result.head.position = startPos
    result.head.direction = right

proc grow(self: var Snake) =
    self.length += 1
    self.body[self.length-1].position = Vector2(x: -1000.0, y: -1000.0)
    score += 1

proc draw(self: Snake) =
    for i in 0 .. self.length - 1:
        self.body[i].draw()

Nim supports OOP . In fact, it supports the bad version of OOP as it outright supports inheritance via ref object of:

type
  Person = ref object of RootObj
    name*: string
    age: int
  
  Student = ref object of Person # Student inherits from Person
    id: int

For reference, the “good” version of OOP is akin to what Rust does with type traits and impl.

And yet despite this, Nim has… outright terrible encapsulation!

It goes down the C path of not allowing methods nested within or attached to structs. Instead, it makes use of global dot syntax such that foo.bar() is analogous to bar(foo). Already this is an issue as it means there are two or more ways to do the exact same thing - not good.

proc add(a: int, b: int): int = a + b

echo add(3, 4)
echo 3.add(4)
echo 4.add(3)

And then the language tries to rely solely on this feature! So the only way to actually associate procedures with a struct is by making the type of the first parameter said struct. This means the functions can be defined literally anywhere, making them hard to track - especially because the order of declaration matters in Nim!! This ended up being a big annoyance for me and is the main reason I couldn’t be bothered with splitting my project across multiple source files. Apparently it’s something to do with metaprogramming, but given that other languages cope fine with order-independence, I don’t quite understand why Nim has it be this way.

And then to top it all off, because the only way to get makeshift struct methods is via this dot syntax, you cannot have static struct procedures. That means no Foo::new() or Foo::from(bar), patterns I love in Rust. Instead, static constructors that return a struct object are declared as newFoo() (and only by convention).

I would have much rather have liked to have seen something more akin to Rust’s way of doing it, and I hope I come across a language with Nim/Python-like syntax that does someday. I don’t like the term “OOP” because it has bad connotations, but the core idea of encapsulating not just data but abstraction in objects is so fundamental to how we operate as humans. A language which messes up this feature is doomed to only appeal to C programmers, I fear (ahem Odin).

Final Thoughts

So, as much as I appreciated a lot about Nim, I unfortunately can’t see myself continuing to use it when other options exist. The extent of its fun is limited due to its issues with OOP, and honestly I would probably have a better experience using Python at that point.

What’s more, I tried compiling my Snake game to WASM (since I’m on Arch Linux), but the process turned out to be more struggle than I could be bothered to put up with at the time. It didn’t help that, a) the documentation on Nim is limited compared to other communities, and b) the compiler honestly isn’t great at reporting errors in a way that’s easy to understand.

I will say though, for the short time I did use it, it was fun and quite refreshing trying out Nim, and it helps that I had a clear, simple project in mind that I could use Raylib for. It’s important that new languages are made that deviate from conventional syntax and practices because it allows us to try and test new things. Haskell sure as hell isn’t a lovely language to use (despite what FP purists may try and tell you), but it is jam-packed with so many cool, novel, and useful features that helped lead to languages like Rust and Zig today.

So although I don’t see Nim or Odin competing with the likes of Rust, Zig, and modern C++, I do appreciate them merely for existing. And hey, this was a good excuse for me to make a Snake game. The next time I do something like this, I’ll try harder to compile it to WASM so I can embed it into the article…

I personally haven’t taken the time to dabble in Zig yet - I’m already busy with Rust and OCaml - but curious as I am, I particularly wanted to know if files could be accessed at compile-time in the language I still know best: C++.

Turns out, the answer is… yes! Although, surprising to me, it’s not through some constexpr version of std::ifstream.

Some Context

Instead, we can turn to a new feature in C23 and C++26 : the #embed preprocessor directive. It allows file data to be embedded into a program at compile-time like so:

constexpr unsigned char foo =
{
#embed "foo.dat"
};

and even allows data to be read directly into structs!

struct T
{
    double a, b, c;
    struct { double e, f, g; } x;
    double h, i, j;
};
T x =
{
// well-formed if the directive produces nine or fewer values
#embed "s.dat"
};

There are also optional embed parameters for even more power; and all-in-all, this is a welcome alternative to encoding file data into scripts manually. Plus, it better allows compilers to make optimisations!

However, although #embed is a nice solution to embedding files for the timebeing, it is still a preprocessor, which we in C++ would rather avoid.

The “proper” C++ alternative is proposed via std::embed by the same author of #embed, JeanHeyd Meneide , and was actually first proposed back in 2018 - although perhaps this shouldn’t come as a surprise considering C++ is far from the easiest language to design and implement new features for.

Although there’s a lot more to be said about these features, I want to focus this article on something… a bit less useful (obsolete even) - another, rather fun way to embed data. A method without #embed, std::embed, special conversion tools, or manually copying bytes by hand!

The Power of the Preprocessor

The #include preprocessor is a relic of C’s past that C++ is only recently beginning to escape from, with popular compilers slowly but surely implementing C++20’s new modules system. After all C’s old include system is widely considered to be glorified copy-paste, leaving C++ programmers to struggle with header guards, namespaces, and build times manually.

However, because #include effectively just copies a file’s contents directly into a C++ file - regardless of the file’s type - we can exploit this to load more than just header files, and at compile-time!

But there is an obvious drawback: the content that is pasted into our C++ script has to be valid C++ code. Therefore, a reliable way to have this work for any arbitrary data is to include it as a C++ string literal. This is because C strings are nothing more than char arrays, where each char represents a single byte, thus acting as a suitable container for binary-encoded data.

For instance, the following program encodes some binary data:

#include <iostream>
#include <cstdint>

constexpr const char data[] = "\x64\0\0\0\0\0\x20\x40\x31\x6A\x6E\x74\x30\x31\0\0";

struct Character {
    std::uint32_t hp;
    float speed;
    char id[8];
};

int main()
{
    // Assume little endian.
    Character character = *reinterpret_cast<const Character*>(data);
    std::cout
        << "Character ID: "    << character.id    << "\n"
        << "Character HP: "    << character.hp    << "\n"
        << "Character Speed: " << character.speed << "\n";
}

Expected output:

Character ID: 1jnt01
Character HP: 100
Character Speed: 2.5

So, seeing as that works, let’s #include a file in place of the string:

constexpr const char data[] =
    #include "1jnt01.bin"
;

Fairly straightforward, although because there is no way (that I could find, anyway) to wrap the include in a string from the C++ file itself, we need to add it to the binary file directly. As a result, it’s important we format the data as a raw string literal, since then we don’t need to worry about random " characters in the middle of the data breaking our string.

More specifically, we should use a prefix that is highly unlikely to show up randomly elsewhere in the data, like R"CEmbd(. Notice that this is also 8 characters/bytes long, which is because we should maintain 64-bit alignment. This in turn gives a suffix of 7 bytes, )CEmbd", for a total of 15 bytes of boilerplate - not particularly expensive.

To better illustrate what I’m on about, let’s construct a simple example with a file hello.bin that contains the following content:

R"CEmbd(Hello, "world"!)CEmbd"

which we include in a program like so:

constexpr const char data[] =
    #include "hello.bin"
;

which, after the preprocessor includes the file, will result in:

constexpr const char data[] =
    R"CEmbd(Hello, "world"!)CEmbd"
;

which is equivalent to:

constexpr const char data[] = "Hello, \"world\"!";

And that’s it! We have successfully embedded data from a non-C++ file into our C++ code. This method should work for any binary data that includes the proper raw string wrapping, whether edited to include it or designed as some kind of special data format (wouldn’t that be interesting!).

If you want to see a more practical example (with better visual aid), then feel free to check out this video:

Why?

#embed is already making its way into C++26, and std::embed may eventually be added as well, rendering this method as obsolete for anyone on the latest standard. Not to mention, the major drawback of using #include to embed is that you’d need to edit existing files to add the raw string wrapper.

That being said, for anyone on a version before C++26 who doesn’t want to have to convert their file to C++ source code every time they swap or edit it, this is one such solution. And don’t get me wrong - this isn’t some revolutionary discovery. I wouldn’t be surprised if some developer somewhere at some point in history has ended up genuinely making use of this hack because of their needs. Nevertheless, for developers that do have access to #embed, it is clearly the better option. Ergonomics aside, the additional performance benefits make it a true no-brainer.

Nevertheless, this was as interesting idea to test out, and I’m honestly surprised it worked so smoothly in the first place. C++ is full of strange features (I imagine largely unintentionally so) and it’s fun to see how they can be used in creative, sometimes mildly useful ways. With more compile-time features coming soon^TM to C++, including reflection, I very much look forward to seeing what else becomes possible!

As someone interested in programming language design, I’ve taken an interest in some of these features, eager to see just how hilariously difficult to read C++ code can be.

In this article, I intend to showcase some of these features in action, and so I present you with the following:

%:import "bits/stdc++.h"
auto main(register int(C), const char*(_)<::>) noexcept -> int {
    return operator<<(std::wclog, *(C ^= 074144, NULL<:_:> + 9))
        << (typeof(*_))new volatile const signed long long<%C++%>, not true;
}

I wrote this code while playing around with compiler.gg which uses Godbolt’s Compiler Explorer . It is intended to be compiled in that environment, so if you want to test it yourself, do so via this link with the “x86-64 gcc 15.2” compiler option.

Now, what this code does is simple: It outputs “sex” to the console.

How it goes about it… is less simple, and is what I will attempt to explain in the rest of this article! As I do so though, I invite you to also try and figure things out yourself to test your understanding of C and C++!

Digraphs

https://en.cppreference.com/w/cpp/language/operator_alternative.html

Right away, we are met with this strange %: pair of symbols, and similar symbols like <: :> and <% %> can be seen later in the code as well.

Such symbols are called digraphs - as in “double symbol” - and act as alternative ways to write common symbols for keyboards/systems that do not support ASCII . In particular, this is to comply with the ISO 646 7-bit character set, which lacks common symbols that you may be familiar with as a programmer.

C’s digraphs include:

• %: = #
• <: = [
• :> = ]
• <% = {
• %> = }

Furthermore, rather than use a digraph for the not operator, !, C includes the not keyword, which can be see towards the end of this code in not true.

Replacing all these alternative representations with their “normal” ASCII counterparts already helps to make the code a lot more readable:

#import "bits/stdc++.h"
auto main(register int(C), const char*(_)[]) noexcept -> int {
    return operator<<(std::wclog, *(C ^= 074144, NULL[_] + 9))
        << (typeof(*_))new volatile const signed long long{C++}, !true;
}

Bonus: Trigraphs

C++ also used to support trigraphs up until C++17 . These functioned similar to digraphs, except were parsed before both comments and string literals, leading to some funky situations such as "Enter date ??/??/??" becoming "Enter date \\??", hence their eventual removal.

Some of these trigraphs were:

• ??< = {
• ??> = }
• ??( = [
• ??) = ]
• ??= = #
• ??/ = \

That being said, GCC does still include trigraphs as an opt-in feature via the -trigraphs flag - and I must admit, I’m quite tempted to use them for stylised includes.

??=include<stdio.h>

#import

https://gcc.gnu.org/onlinedocs/cpp/Alternatives-to-Wrapper-_0023ifndef.html

Those who have been keeping up with modern C++ should recognise the import keyword, used to import modules as an alternative to classic header includes.

However, #import is not to be confused with this, and goes way back to the 80s/90s when GCC implemented support for Objective-C . While also an alternative to #include, its function is to ensure that a header is only included in a project once. Although, this feature was later deprecated as it became agreed that it’s better that the header file is responsible for whether or not it is included multiple times. Hence, developers nowadays are instead expected to either use #ifndef guards (generally recommended) or #pragma once (not standard) - or soon, perhaps, modules!

In the case of our code, there aren’t multiple source files anyway, so #import is synonymous with #include:

#include "bits/stdc++.h"

auto main(register int(C), const char*(_)[]) noexcept -> int {
    return operator<<(std::wclog, *(C ^= 074144, NULL[_] + 9))
        << (typeof(*_))new volatile const signed long long{C++}, !true;
}

bits/stdc++.h

https://stackoverflow.com/questions/25311011/how-does-include-bits-stdc-h-work-in-c

bits/stdc++.h is essentially a header that includes all the C and C++ headers, useful for quick testing, and especially useful for precompiled headers. Otherwise, though, it unsurprisingly slows down compilation, and it’s better to just include the independent headers that are actually used. In our case, all we’re doing is using std::wclog which comes from iostream, so we can just include that instead.

#include "iostream"

auto main(register int(C), const char*(_)[]) noexcept -> int {
    return operator<<(std::wclog, *(C ^= 074144, NULL[_] + 9))
        << (typeof(*_))new volatile const signed long long{C++}, !true;
}

Moreover, we can replace the "" around iostream with the more typical <> as the only real difference in this case is expressing intention. This change signifies that iostream is an external header that is independent of our project:

#include <iostream>

auto main(register int(C), const char*(_)[]) noexcept -> int {
    return operator<<(std::wclog, *(C ^= 074144, NULL[_] + 9))
        << (typeof(*_))new volatile const signed long long{C++}, !true;
}

Trailing return type

https://en.wikipedia.org/wiki/Trailing_return_type

Trailing return types have been supported since C++11, which can make functions more readable in some cases via the syntax auto foo() -> T {}, reminiscent of Rust ’s:

fn foo(x: u32) -> u32 { /* ... */ }

Generally-speaking, trailing return types have 3 main uses:

1. Return type with decltype (in C++11), before decltype(auto) was around (added in C++14):

template<typename A, typename B>
auto add(A a, B b) -> decltype(a + b);

2. Lambda expressions (also introduced in C++11).

auto f = [](int x) -> double { return x; };

3. Readability of more complex types.

template<std::integral T>
std::expected<BinaryView::Error, T> BinaryView::read(std::endian endian);

template<std::integral T>
auto BinaryView::read(std::endian endian)
    -> std::expected<T, BinaryView::Error>;

In the case of main, the return type is just int, and so using a trailing return type is nothing but stylistic choice. Although I personally don’t enforce trailing return types in my code unless I’m using something verbose like std::expected , I do see why some programmers choose to use them in every function for consistency’s sake.

#include <iostream>

int main(register int(C), const char*(_)[]) noexcept {
    return operator<<(std::wclog, *(C ^= 074144, NULL[_] + 9))
        << (typeof(*_))new volatile const signed long long{C++}, !true;
}

noexcept

https://en.cppreference.com/w/cpp/language/noexcept_spec.html

In short, noexcept as a specifier tells the compiler that a function will not attempt to propagate exceptions outwards - i.e., any exceptions that are propagated into the function are caught. This enables the compiler to make some optimisations as a result, but if the noexcept promise is broken, std::terminate is called instead, exiting the program.

So is there any point in tagging main with noexcept? Well, no, because main will exit if it has a propagating exception anyway. Therefore, it serves no real purpose here:

#include <iostream>

int main(register int(C), const char*(_)[]) {
    return operator<<(std::wclog, *(C ^= 074144, NULL[_] + 9))
        << (typeof(*_))new volatile const signed long long{C++}, !true;
}

register

https://en.cppreference.com/w/cpp/language/storage_duration.html

The register keyword is an artefact of a time when compilers weren’t as intelligent as they are now; the first time I ever saw it used was in the DOOM codebase of all places.

What register does is signal to the compiler that a declared variable is going to be heavily used and should therefore be stored directly in a CPU register if possible, as registers are significantly faster than memory stores.

However, the keyword was deprecated as of C++11 and outright removed in C++17, as compilers are allowed to ignore this hint if needed, and they can generally decide when a variable should be in a register more reliably than a human can. Therefore, we have no need for it here:

#include <iostream>

int main(int(C), const char*(_)[]) {
    return operator<<(std::wclog, *(C ^= 074144, NULL[_] + 9))
        << (typeof(*_))new volatile const signed long long{C++}, !true;
}

Additionally, 64-bit systems primarily use the fast-call convention which puts the first 4 arguments of a function into CPU registers anyway, so using register on the 1st argument of a function like this really is pointless.

Parenthesised declarators

https://en.cppreference.com/w/cpp/language/declarations.html

C++ supports parenthesised declarators to help with disambiguation in certain contexts, although can also be used in other contexts too. For instance, the following code is valid C++:

int((((((((a))))))))=5;

More useful cases include:

1. Function pointers

int *f();   // A function that returns int*
int (*f)(); // A pointer to a function that returns int

2. Array pointers

int *a[23];   // An array of 23 int*'s
int (*a)[23]; // A pointer to an array of 23 int's

There’s also this funky case where the use of a constructor can be confused for a function declaration:

Foo bar(Baz());   // Could be a function that has a parameter for a function that returns Baz
Foo bar((Baz())); // Unambiguous - simply takes the result of the function call Baz() in Foo's constructor

But C++11 added curly-brace initialisation for this exact reason, which I for one use religiously:

Foo bar{Baz()};

In the context of our code, however, we don’t need this disambiguation. The first parameter of main is simply an int, and the second is a char* array (char**), so the parenthesis just hurt readability and should be removed:

#include <iostream>

int main(int C, const char* _[]) {
    return operator<<(std::wclog, *(C ^= 074144, NULL[_] + 9))
        << (typeof(*_))new volatile const signed long long{C++}, !true;
}

Underscore identifier

https://en.cppreference.com/w/cpp/language/identifiers.html

Ignoring funky unicode stuff, C++ identfiers (such as variable names) can me made up of uppercase and lowercase Latin letters (A-Z and a-Z), underscores, and the digits 0-9 except for as the first character. There are also reserved identifiers, like with keywords and patterns like _Foo and __bar. However, a single underscore, _, rather than be reserved for wildcard syntax as seen in Haskell and Rust , manages to somehow slip through as a valid identifer. This means that _ can be used as a variable name.

Furthermore, C++ function type signatures are independent of the names given to the function’s parameters, hence we are able to change the typical argc to just C (in order to have C++ later in the code!) and argv to _. Changing these names back to normal, we get:

#include <iostream>

int main(int argc, const char* argv[]) {
    return operator<<(std::wclog, *(argc ^= 074144, NULL[argv] + 9))
        << (typeof(*argv))new volatile const signed long long{argc++}, !true;
}

It is also worth noting that const can be used here without any issues as well. In fact, it is the first obfuscation so far that can actually be argued as idomatic C++, even if it is unusual! As such, I will choose leave it in.

Operator overloading

https://en.cppreference.com/w/cpp/language/operators.html

Anyone who knows C++ should remember the first time they learned how to print to the terminal, using the << operator as if constructing a conveyor belt for which to stream content into std::cout. Hopefully, with std::println slowly making its way into compilers, newcomers to C++ will never have to face this atrocity ever again. It is a textbook example of operator overloading gone wrong. At least, most would likely agree that overloading an operator to do something completely different from what it was originally intended to do is not a great idea, and we’d be better of defining new operators instead (>>= anyone?).

<< is originally the bitwise left shift operator, used for… well, shifting bits . It was unfortunate enough to have the ostream header overload it with its own custom behaviour.

That being said, a cool quirk of operator overloading, is that it necessitates some way to… overload operators, and C++ provides this by making it possible to define operators as functions, their symbols prefixed with operator (e.g., operator+ or operator<<).

This also means that when such an overload is defined, it can be called in this way too, hence the following code snippets are equivalent:

std::cout << "Hello, world!" << std::endl;

operator<<(std::cout, "Hello, world!").operator<<(std::endl);

With this mind, we can once again make our code significantly easier to read:

#include <iostream>

int main(int argc, const char* argv[]) {
    return std::wclog << *(argc ^= 074144, NULL[argv] + 9)
        << (typeof(*argv))new volatile const signed long long{argc++}, !true;
}

std::wclog

https://en.cppreference.com/w/cpp/io/clog.html

But hold on, what is std::wclog? Shouldn’t it be std::cout that writes to standard output?

std::clog is similar to std::cerr in that they both write to standard error (stderr). However, unlike std::cerr, std::clog is not automatically flushed , which is important where performance-critical conditions.

std::wclog is just the wide char version of this. Typically, a wide char is more than just 1 byte, but std::wcout and its variants all implicitly convert char* to wchar_t*. Therefore, both these code snippets have the same visual result when a wide char is 4 bytes:

static_assert( sizeof(wchar_t) == 4 );

// Snippet 1
std::wcout << (wchar_t*)"b\0\0\0a\0\0\0z\0\0\0\0\0\0\0";

// Snippet 2
std::wcout << "baz";

Now, although it’s not immediately obvious that our code uses normal char* as input to std::wclog, we can see that (typeof(*argv)) is used as a cast (more on that later), which should evaluate to a (char*) cast. Therefore, it’s fairly safe to assume that we can just use std::cout instead, and we’ll also simplify the cast while we’re at it:

#include <iostream>

int main(int argc, const char* argv[]) {
    return std::cout << *(argc ^= 074144, NULL[argv] + 9)
        << (char*)new volatile const signed long long{argc++}, !true;
}

Comma operator

https://en.cppreference.com/w/cpp/language/operator_other.html

One of my absolute favourite features of C is the comma operator, which I imagine many programmers aren’t aware even exists. What I find so fascinating about it is that it is technically useful - potentially really useful in some contexts - but is nevertheless generally bad to use.

Not to be confused with the use of commas in other C/C++ contexts (e.g. lists), the comma operator forms an expression in which the left-hand argument(s) are evaluated with their results discarded, while the evaluation of the right-most argument is what the expression returns, eerily similar to the >> operator in Haskell, minus the monads .

-- putStr returns an IO (), which main requires.
main :: IO ()
main = putStr "Hello, " >> putStr "world!"

// main requires that an int be returned.
int main(void) {
    return puts("Hello, world!"), 0;
}

Some seemingly useful applications of this include:

1. Multiple varable mutation in index-based for loops:

// Comma operator used             ↓ here only!  
for (int i = 0, j = 10; i <= j; ++i, --j)
    std::cout << "i = " << i << " j = " << j << '\n';

int a = (a = 5, a *= 3, a += 4, a %= 8, a ^= 23);

return LOG_ERROR("Division by zero."), std::nullopt;

In our code, we are incidentally making use of that last example, logging before returning !true. If we instead opt to write this out as two separate lines, we get something more conventional and readable:

#include <iostream>

int main(int argc, const char* argv[]) {
    std::cout << *(argc ^= 074144, NULL[argv] + 9)
        << (char*)new volatile const signed long long{argc++};
    return !true;
}

But we’re not done yet! There’s another use of the operator within the dereference we have going on. Extracting this out to yet another line, things should be starting to make more sense:

#include <iostream>

int main(int argc, const char* argv[]) {
    argc ^= 074144;
    std::cout << *(NULL[argv] + 9)
        << (char*)new volatile const signed long long{argc++};
    return !true;
}

Implicit casting

https://en.cppreference.com/w/cpp/language/implicit_cast.html

Love it or hate it, C++ is notorious for implicit type conversion, so it’s pretty much expected that it’d turn up somewhere in this code - and sure enough, it’s easy to spot.

The function main has a return type of int, but we are attempting to return !true, so it must be that this bool expression is being implicitly converted to type int. In particular, !true == false, and false as an integer is simply 0. Therefore, we can write:

#include <iostream>

int main(int argc, const char* argv[]) {
    argc ^= 074144;
    std::cout << *(NULL[argv] + 9)
        << (char*)new volatile const signed long long{argc++};
    return 0;
}

Array subscript commutativity

https://learn.microsoft.com/en-us/cpp/cpp/subscript-operator?view=msvc-170

The subscript operator, [], is defined such that a[b] == *(a + b). Because of how C pointer arithmeic works (more on that in a bit), this means that a[b] == b[a], and the expression NULL[argv] is equivalent to argv[NULL].

#include <iostream>

int main(int argc, const char* argv[]) {
    argc ^= 074144;
    std::cout << *(argv[NULL] + 9)
        << (char*)new volatile const signed long long{argc++};
    return 0;
}

NULL

https://en.cppreference.com/w/c/types/NULL.html

But what even is NULL? In C, it is typically defined as a null pointer, but this is implementation defined .

Importantly, it is allowed for NULL to be defined as the constant 0 or, as off C23 , nullptr in order to remain compatible with C++. To avoid breaking this compatibility, it cannot be (void*)0, nor can it be an expression that evaluates to 0, like 10 * 2 - 20.

GCC defines NULL as its own magic keyword, __null , and is supposed to be a null pointer. Therefore, the GCC compiler generates the “converting NULL to non-pointer type” warning when attempting to index an array with it. As such, we’d best just use 0 to access the first element of an array:

#include <iostream>

int main(int argc, const char* argv[]) {
    argc ^= 074144;
    std::cout << *(argv[0] + 9)
        << (char*)new volatile const signed long long{argc++};
    return 0;
}

Pointer arithmetic

https://www.learncpp.com/cpp-tutorial/pointer-arithmetic-and-subscripting/

As mentioned previously, the subscript operator expands to pointer arithmetic, such that a[b] == *(a + b).

However, consider the following:

int a[] = {0, 1, 2, 3, 4, 5, 6, 7};
int b = *(a + 4);

It’s important to note that a + 4 does not simply mean adding 4 to the address of a. Rather, it is adding 4 * sizeof(a[0]), which in this example evaluates to 4 * sizeof(int) == 4 * 4 == 16. Thus, *(a + 4) is equivalent to a[4], and gives the value 4 from the array.

Likewise, our code *(argv[0] + 9) is equivalent to argv[0][9]:

#include <iostream>

int main(int argc, const char* argv[]) {
    argc ^= 074144;
    std::cout << argv[0][9]
        << (char*)new volatile const signed long long{argc++};
    return 0;
}

And since argv is a char** (i.e., an array of char arrays, i.e., an array of null-terminated strings ), argv[0][9] is the 10th character of the 1st string in argv.

At this point, it’s useful to actually see what this string is, because Godbolt’s Compiler Explorer does in fact feed an argument to the program, and that is “./output.s”. Do some basic counting, and we can see that the 10th character in this string is indeed 's'. Let’s make all of this more clear in our code:

#include <iostream>

int main(int argc, const char* argv[]) {
    argc ^= 074144;
    const char* input = argv[0];
    assert(input[9] == 's');
    std::cout << input[9]
        << (char*)new volatile const signed long long{argc++};
    return 0;
}

Octal

https://en.cppreference.com/w/cpp/language/integer_literal.html

Back in the 1970s, octal (base-8) encoding was all the rage.

Unfortunately, this meant that unlike binary literals which are prefixed with 0b or hexadecimal literals which are prefixed with 0x, octal literals are only prefixed with 0 in C (and by extension, C++).

So really, 074144 in our everyday base-10 is 30820, which we can replace here:

#include <iostream>

int main(int argc, const char* argv[]) {
    argc ^= 30820;
    const char* input = argv[0];
    assert(input[9] == 's');
    std::cout << input[9]
        << (char*)new volatile const signed long long{argc++};
    return 0;
}

XOR

https://en.wikipedia.org/wiki/Exclusive_or

^ is C’s exclusive or bitwise operator, and essentially takes the bits of two values and compares their bits in pairs, individually setting the resultant bits to 1 if the pairs do not match, and 0 otherwise.

In our code, argc starts as 1 (because there is one argument given to the program) and then is XOR’d with 30820. If we compute 1 ^ 30820, we get 30821, just so happens to give the same result as if we had added them together.

#include <iostream>

int main(int argc, const char* argv[]) {
    argc = 30821;
    const char* input = argv[0];
    assert(input[9] == 's');
    std::cout << input[9]
        << (char*)new volatile const signed long long{argc++};
    return 0;
}

Post-increment operator

https://en.cppreference.com/w/cpp/language/operator_incdec.html

Later in our code, we also see that argc is being incremented via the post-increment operator (argc++), the operator responsible for C++ being called what it is today .

However, although not immediately obvious, this operator doesn’t actually do anything in this context. This is because we are passing argc++ into the constructor of long long, meaning a new long long is constructed and argc is only incremented after the fact - unlike if ++argc was used, which would increment it before argc is accessed.

Therefore, since argc isn’t used used after this, the operation serves no purpose and can be removed.

#include <iostream>

int main(int argc, const char* argv[]) {
    argc = 30821;
    const char* input = argv[0];
    assert(input[9] == 's');
    std::cout << input[9]
        << (char*)new volatile const signed long long{argc};
    return 0;
}

new

https://en.cppreference.com/w/cpp/language/new.html

Now we’re very close to deciphering this completely!

It is usually advised to new C++ programmers to avoid using new as much as possible, especially for programmers coming from OOP languages like Java which use it extensively. This is because it allocates dynamic memory , unlike normal pointers which use automatic memory management. After all, dynamic memory is computationally expensive to work with!

However, a new expression can also serve another, extremely niche purpose: to get the address of some memory without needing to use the & operator, since new returns the address of the memory it allocates. And that’s exactly what’s happening here!

Therefore, since we would prefer not to use dynamic allocation anyway, let’s just use & to get the address of the existing variable argc rather than duplicate its data:

#include <iostream>

int main(int argc, const char* argv[]) {
    argc = 30821;
    const char* input = argv[0];
    assert(input[9] == 's');
    std::cout << input[9] << (char*)&argc;
    return 0;
}

You’ll also notice that I’ve removed the volatile const signed long long, and that’s because it is just fluff, as will become evident in our final step…

String in disguise

https://medium.com/@ryan_forrester_/c-integer-to-character-conversion-a-comprehensive-guide-ac8bf9e5940a

Finally, we are down to the last layer of obfuscation, and this just uses a neat little trick that isn’t particularly special to C, but rather a quirk of how computers represent data in general.

First, it is important to understand that the char type is just the mapping of a byte-sized number ranging from 0-255 to what is typically an ASCII character. Therefore, a typical C string is just a sequence of these characters - an array of char values.

But what if we take a number that is bigger than a byte? Say, 30821. Well, assuming we are using little endian , 30821 as an int is represented in hexadecimal as 65 78 00 00 (note that each pair of digits is 1 byte). Therefore, an int can also be thought of as an array of bytes - 4 in total if we assume that sizeof(int) == 4.

So what happens if we take this number and treat it as a char array? Well, 0x65 == 'e' and 0x78 == 'x', so we get the string "ex".

However, it’s important to note that for a char array to be a valid C string, it must be null-terminated (i.e., ending with 0x00). As a result, we are able toget a string of maximum length 3 from a single 32-bit integer. "ex" is only of length 2, so it is indeed able to fit within these constraints, and a larger type like the 64-bit long long is unnecessary.

So, when we cast (char*)&argc, what we’re really doing is telling the compiler to process our integer argc as a string instead, and finally it becomes clear why our program outputs “sex”. Let’s remove this conversion and just make the value explicit:

#include <iostream>

int main(int argc, const char* argv[]) {
    const char* input = argv[0];
    assert(input[9] == 's');
    std::cout << input[9] << "ex";
    return 0;
}

And voilà, we have successfully picked apart the original obfuscated code to reveal what it is really doing!

Conclusion

So, it turns out that all this:

%:import "bits/stdc++.h"
auto main(register int(C), const char*(_)<::>) noexcept -> int {
    return operator<<(std::wclog, *(C ^= 074144, NULL<:_:> + 9))
        << (typeof(*_))new volatile const signed long long<%C++%>, not true;
}

is really just an obfuscated way of doing this:

#include <iostream>

int main() {
    std::cout << "sex"; // as in "sextet"
}

To whoever gave this a read, I hope it was as insightful to you as it was fun for me to put together. But do not be fooled! What I have covered here is but the tip of an iceberg that will lead you far into the depths of Hell if you dare to attempt traversing your way to its bottom.

Perhaps I am exaggerating, but if you consider the fact that the comma operator can be overloaded… am I really?

Revisions

The following is a list of changes I’ve made to the original post. Feel free to contact me if you notice any other mistakes or misinformation in my articles!

• [2026-03-04] - Previously said that std::cerr is buffered, but makes more sense to just say it’s not automatically flushed compared to std::clog, as both are technically buffered anyway.
• [2026-03-04] - Previously said that registers are faster to access than RAM , which is true, but it’s more accurate to say memory stores.
• [2026-03-05] - Unobfuscated example at the very end used #import instead of the correct #include.
• [2026-03-05] - Added an example of Haskell’s >> operator in comparison to C’s , operator.
• [2026-03-05] - Fixed wchar_t example, as was missing proper null terminator.
• [2026-03-05] - Added Godbolt links to many of the code examples.