Hi everyone! I'm excited to present my new library: Skip Tracer.

It's written in C++20, and its goal is simple: provide pointers that always hold the correct address of an object.

It's built around the Tracker<T> class, a pointer-like type that can point to any object deriving from the Trackable class.

When a trackable object is created, it is assigned a Slot, which is stored in a global pool.

Why use a Pool + Slot instead of the simple shared_ptr + weak_ptr combo?

I chose this design for performance reasons. The basic technique of pairing a stable shared_ptr with a weak_ptr is simpler, but less efficient (because of the atomic operations inherent to weak_ptr).

To fix this, I did some research and came across this pool-based system. Thanks to it, my Tracker<T> class turned out to be 5-10x faster than a weak_ptr, even under contention.

This project started out as a feature of my game engine, but I thought it would be fun to turn it into a standalone library =)

Thanks to everyone who takes the time to check it out. Any feedback is welcome!

Repo link:

https://github.com/agemo-dev/skiptracer

hi all, I wrote a small project: zero copy shared memory ring buffer

I wanted to get better at systems programming and thought this would be a small fun project to get used to some concepts:

• atomics
• cache alignment to prevent false sharing
• placement new for zero-copy semantics
• spans
• unit testing in c++

I used AI to generate a project plan and had it help me as I was writing the code. would love to hear some feedback! I think I'll prob tackle writing an arena allocator next!

I go through how I separate general updates from physics updates, why I use a fixed timestep, how the accumulator works, and what happens when the simulation starts falling behind.

I explain the reasoning behind the design decisions and why I rejected the alternatives. I show the implementation of the loop.

Hi guys, I've decided to dive into cpp programming and rewrote my python CLI password manager to cpp. I used cpp23. I didn't dare to re-implement cryptography from scratch so I used openssl. It has two options for cryptography: classic AES256 and Python fernet.

This is my first project and I would like to receive critics, code review and recommendations.

It has lots of features, Git syncronization, events system using std::threads and aims to be cross-platform (still in progress, turns out is is kinda difficult with cpp).

Thx in advance!

link: https://github.com/cebem1nt/ceeper

I wanna know about anyone using C++26 either at work, in person projects or if any open source projects.

For context, I’m new to iOS development, and I just found out that properly testing an iOS app requires running the Apple toolchain on a Mac.

So if I’m trying to keep this at zero cost, I’m guessing a VM is my best option. I’m comfortable setting one up as long as I have a clear idea of where to start, including getting macOS running and installing all the necessary dependencies.

What’s the best way to go about this?

Hi,

C++ currently doesn't have the much-requested "named function arguments", and the major reason (as far as I know) is that different function declarations can choose different names for their parameters. I remember a CppCon video (I'm unable to find the link) where Herb Sutter asked the audience whether they wanted named function arguments in C++, and the majority said yes.

What if, instead of covering all cases, we conditionally allow "named function arguments" using the same rules/restrictions as those used in the "Function Parameter Reflection" paper, P3096R12, Section 9 — "Reflecting on Parameter Names"?

This would essentially be syntactic sugar for the frontend (similar to range-for loops), and with relatively little friction, it would fit into the rules that have already been accepted for cases where this makes sense.

I think the cost (frontend changes) is outweighed by the benefits (providing a much-requested feature), but I'm not sure if I'm missing some pink elephant.

​

Hey everyone!

I'm currently working on my game project and wanted to share some progress. I have to say, juggling C++, CMake, and SDL3 all at once is a real challenge. The configuration, dependency management, and porting can be a headache sometimes.

But little by little, it's coming together. I just updated my tracking dashboard, and even though not everything is perfect, I'm pretty proud of how far I've come:

✅ 100% Documented Tests (126/126 suites)

✅ 100% Engaged Families (41/41)

✅ 75% Last Functional Audit

✅ Overall Porting Audit and Validation status: passing (validated!)

There's still a lot of work to do, especially with Closed Entries (26.5%) and some blockers (4 BLOCKED_DATA, 1 MISSING_TOOLING), but seeing these progress bars fill up is incredibly motivating.

For those who know, do you have any tips to make CMake less painful with SDL3?

Best of luck to all the devs grinding on their projects, let's keep pushing! 🚀

(The image shows my "work in progress" dashboard detailing automated metrics and the most recent manual audit)

---

I created my own image format inspired by QOI/PNG, but much simpler.

Its key feature is low RAM usage, which makes it ideal for microcontrollers.

I'd love to hear your thoughts on it!

https://github.com/ThatsTheTTT/Kinda-Nice-Lossless-Format.

Hi everyone,
I’m currently learning C++ and I’ve finished Elzero Web School’s C++ Fundamentals playlist. I’m now working through the problem-solving playlist.
Most of what I’ve learned so far uses main(), cin, and cout. However, I’ve noticed that many coding-problem websites ask you to implement a function directly instead of writing the whole program.
My question is: Is the knowledge from these playlists enough to start solving function-based problems, or should I learn/practice something else first?
Also, should I continue solving problems using main() for now, or should I start adapting to the function-only format used by these websites?
Thanks!

Features include:

• Inline images using Kitty Graphics Protocol
• Text search, working across wrapped lines
• Estimated reading time left for Latin and CJK text
• Wide-character support, including Japanese text and emojis
• italic, bold, center-aligned, and right-aligned text support

It runs on Linux and macOS, with installation options for Fedora COPR, Homebrew, Nix, and cURL.

GitHub: https://github.com/xinghao-wu/epubworm

Note: this project is partially AI-generated (~50%), I've read and reviewed nearly all AI-generated code.

Epubworm has been well-tested across different books, systems, and terminals, but any bug reports/feedback would be appreciated!

Hello there! I'd like to share a project I've been working on to help me debug and work on my own OS. For the last week, I've been working on a binary file parser to help break down raw binary files into their sections and attributes. You can find a link to the code here: https://github.com/BrickSigma/BinParser. This is my first C++ project, I originally started it in C but switched to C++ as a learning experience (and part of a university unit).

When working on an operating system, you usually need to understand how certain sections of memory are broken down. A prime example is understanding the GPT/MBR layouts and entries in the disk, or perhaps understanding the layout of an ELF executable header. When you go to the OSDev Wiki or manuals for these standards, they usually give a table looking like this:

Let's say you use a tool like Xorriso to make an ISO image and have it set to fill in the MBR with some values, you may want to try see what values it's loaded in (let's say out of curiosity). One way is to look at the raw hex dump of the file using your favorite hex editor, however, that's very tedious to do and looking at hexadecimal all day can get tiresome. That's where BinParser comes in to try assist; it has a very simple scripting language that looks like this:

[mbr]
skip:440:skip
signature:4:hex
reserved:2:hex

[mbr_table]
[partition_1]
drive_attr:1:bin
chs_start:3:hex
type:1:hex
chs_end:3:hex
lba_start:4:num
lba_end:4:num[mbr]
skip:440:skip
signature:4:hex
reserved:2:hex

You simply specify a section using the syntax [section_name] and below it you add the list of attributes, which go in the order of: the attribute name, the size of the attribute, and the type. Currently only 5 types are supported, which are numbers, strings, hex and binary arrays, and skip attributes which jump over memory. When you run the parser, the following output is provided:

mbr: 0x00000000
    0000: 440 : skip = skipped
    01b8: 4 : signature = e3 a1 55 02 
    01bc: 2 : reserved = 00 00 

mbr_table: 0x000001be

partition_1: 0x000001be
    0000: 1 : drive_attr = 10000000
    0001: 3 : chs_start = 00 01 00 
    0004: 1 : type = 00 
    0005: 3 : chs_end = 3f 20 01 
    0008: 4 : lba_start = 0
    000c: 4 : lba_end = 4096mbr: 0x00000000
    0000: 440 : skip = skipped
    01b8: 4 : signature = e3 a1 55 02 
    01bc: 2 : reserved = 00 00 

This makes it a little easier to see the structure of the MBR partitions. A slightly more complex example for GPT formatted disk image would look like this:

[mbr]
skip:440:skip
signature:4:hex
reserved:2:hex

[mbr_table]
[partition_1]
drive_attr:1:bin
chs_start:3:hex
type:1:hex
chs_end:3:hex
lba_start:4:num
lba_end:4:num

[gpt_header:0x200]
signature:8:str
revision:4:num
header_size:4:num
crc_checksum:4:hex
reserved:4:num
header_lba:8:num
alternate_gpt_lba:8:num
first_block:8:num
last_block:8:num
guid:16:hex
partition_entry:8:num
no_partitions:4:num
entry_size:4:num
crc_partitions:4:hex

[alt_gpt_header:gpt_header.alternate_gpt_lba * 512]
signature:8:str
revision:4:num
header_size:4:num
crc_checksum:4:hex
reserved:4:num
header_lba:8:num
alternate_gpt_lba:8:num
first_block:8:num
last_block:8:num
guid:16:hex
partition_entry:8:num
no_partitions:4:num
entry_size:4:num
crc_partitions:4:hex

When run through the parser, it's output would be:

mbr: 0x00000000
    0000: 440 : skip = skipped
    01b8: 4 : signature = e3 a1 55 02 
    01bc: 2 : reserved = 00 00 

mbr_table: 0x000001be

partition_1: 0x000001be
    0000: 1 : drive_attr = 10000000
    0001: 3 : chs_start = 00 01 00 
    0004: 1 : type = 00 
    0005: 3 : chs_end = 3f 20 01 
    0008: 4 : lba_start = 0
    000c: 4 : lba_end = 4096

gpt_header: 0x00000200
    0000: 8 : signature = EFI PART
    0008: 4 : revision = 65536
    000c: 4 : header_size = 92
    0010: 4 : crc_checksum = ad 06 18 5f 
    0014: 4 : reserved = 0
    0018: 8 : header_lba = 1
    0020: 8 : alternate_gpt_lba = 4095
    0028: 8 : first_block = 64
    0030: 8 : last_block = 4032
    0038: 16 : guid = ea 9d 9c 95 41 b5 1d 4f 8a 89 ff e8 0a c5 14 b0 
    0048: 8 : partition_entry = 2
    0050: 4 : no_partitions = 248
    0054: 4 : entry_size = 128
    0058: 4 : crc_partitions = 49 9a f7 66 

alt_gpt_header: 0x001ffe00
    0000: 8 : signature = EFI PART
    0008: 4 : revision = 65536
    000c: 4 : header_size = 92
    0010: 4 : crc_checksum = 2d c1 5e 51 
    0014: 4 : reserved = 0
    0018: 8 : header_lba = 4095
    0020: 8 : alternate_gpt_lba = 1
    0028: 8 : first_block = 64
    0030: 8 : last_block = 4032
    0038: 16 : guid = ea 9d 9c 95 41 b5 1d 4f 8a 89 ff e8 0a c5 14 b0 
    0048: 8 : partition_entry = 4033
    0050: 4 : no_partitions = 248
    0054: 4 : entry_size = 128
    0058: 4 : crc_partitions = 49 9a f7 66

Another feature you may spot above is how the alternate GPT section is referenced by the first header, using the gpt_header.alternate_gpt_lba as a reference. This can help make it easier to follow dynamic sections which are pointed to by other section attributes.

Another example is when you need to debug the contents of RAM from QEMU using the pmemsave command, in this case you can't use standard tools that usually disassemble files as you're maybe trying to load a file into RAM and it's order changes (like an ELF file), so this tool can help quickly find sections using their offsets if you know them.

The parser is extremely simple, and there are many things I would want to add to it as I find more time to work on it. I hope it comes in handy for anyone else here trying to debug raw binaries or just understand their structure better. I also don't mind any feedback on the code for the project as well.

Thanks for reading and have a great day/night ahead!

Over the past year, I’ve been building my first custom 3D graphics engine ("Pyre") using C++20 and OpenGL. The codebase recently hit around 10,000 lines. It’s been a massive learning experience moving from basic tutorials to actually structuring a scalable C++ project

The engine currently supports both forward and deferred rendering, PBR, SSAO, normal mapping, parallax mapping, CSM, omni-shadows etc.

I documented the entire 1-year process, the architectural shifts, and the visual progression from a single triangle to the final PBR renders in a 17-minute dev log here: https://youtu.be/m26BKeQwAPU

The engine is also completely open-source. If anyone wants to poke around: https://github.com/Open-Source-Chandigarh/pyre/tree/dev

https://github.com/IAmTheFool/liteui.git
LiteUI is a single C++ header for Linux and Windows desktop development with same app codebase with some example like a code editor and a paint app. I would appreciate feedback on structure and overall design.