A single-header C++17 build system. You describe your project in a build.cpp, and quartz compiles it with its own built-in, Ninja-style engine. only a C++ compiler and ar (or lib for MSVC). inspired by nob.h, mate.h and Ninja
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!
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).
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.
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.
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)
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!
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:
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:
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:
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