Stop using C++

This is the latest video in the “Stop using XYZ” series by tony(-btw)

5 Likes

Easier said then done. There are a couple of really essential libraries only avalable as C++.

For instance just in the context of game-dev / rendering:

…etc etc…

…e.g. if you want to do game-dev or 3D rendering, having to deal with C++ libraries is the norm. If you’re lucky those libraries have officially maintained C APIs which simplify language bindings but it’s far from common :confused:

12 Likes

I’ve been really curious about this one because I feel like in zig, it should be technically possible to compile shaders at comptime rather than using a separate program as a part of the build process to generate a .zig file. But I didn’t see an easy solution when I searched.

You can compile SPIR-V shaders with zig itself and @embedFile them into your program. Using other shader compilers or spir-v cross needs you to compile them with build.zig and generate the outputs build time using runsteps though.

1 Like

I wish more beginner videos would use zig init as it helps avoid a lot of the initial confusion users have about printing and file handling, and even makes a nice commented build file.

There is no magic that upgrades old videos to the latest iteration of Zig. IO is changing rapidly, so videos go stale really fast.

Best advice I have is to learn how to learn by means other than just videos. That is, by reading code in std and other projects, documentation, and following discussions here and on Discord.

But this is a new video. I’m not a beginner, I just see people who are running into difficulties that can be avoided by starting with zig init.

Time to make that video and get it out there, then!

2 Likes

Sometimes this makes me wonder, perhaps I should have just sticked to C++. Perhaps I would have gone insane, at least for a different reason.

If the ecosystem is not there for a language, does it makes sense for you to use that language? If you asked me this a year ago I would have said: “I can build %80 of it, the rest is probably too much for me anyways”. Now, seeing the consequences to my actions, I sometimes regret it. Though I have become much better at programming, idea of “by the time I built %80, I would have probably finished what I needed to” still lingers and does not help lol.

EDIT: There is also the fact that you can’t just use C++ in Zig, at least in a easy way.

I find I prefer using C++ with Zig build to cmake. Also there isn’t much point rewriting a C++ library unless a) you’re an expert that wants to improve the existing one or b) you’re doing it for the learning experience.

Not mine, but GitHub - Justus2308/zuballoc: A hard realtime O(1) allocator for sub-allocating memory regions with minimal fragmentation. · GitHub

3 Likes

That was great!

Only improvement I could suggest would be doing the inner string copies with the arena that is already provided in init. Or, slurping up the entire input file into an arena-allocated buffer since the line data needed to be duplicated anyway. That would complete the narrative, that Zig puts the allocations in your face - but then offers a way to make them actually go away.

5 Likes

Which honestly is why memory handling in zig is MUCH easier, almost competing with GC languages in convenience and manages this completely without the performance cost. In fact it’s possible to outperform the heap and beat clean c++ code in performance while still writing clean readable code.

1 Like

A good approach for integrating C++ libraries (without a C API) into mixed-language projects is to write ‘meaty’ portions of the code accessing this library in C++, and expose a much simpler C API to the non-C++ code.

For instance in my ‘visual CPU remix’ tools (e.g. for the Z80: Visual Z80 Remix), the bulk of the code is written in plain C, but all the UI code is written in C++, talking to the Dear ImGui C++ API.

The complex C++ UI code is then hidden behind a fairly simple C API like this (it’s not a master class in API design but it does the job):

The same approach would work for Zig in a mixed C++/Zig project.

(PS: tbh though, today I would simply use the official Dear ImGui C bindings in this specific case, but the same approach works for other C++ libraries too of course)

PPS: similar approach here with ozz-animation: this basically creates a small ‘domain-specific’ wrapper library around the ozz-animation C++ API in a C++ file, and exposes it as a much simpler C API to the rest of the code: sokol-samples/libs/ozzutil at master · floooh/sokol-samples · GitHub)

4 Likes