C++ to Zig retrospective

[pfeatherstone]

Out of interest, has the transition from c++ to zig paid off? Has it helped developer experience, robustness, performance, etc? Has it eliminated a source of bugs? Just curious

[arrufat]

Hi! I am overall very happy with the language.

Here are the main things I appreciate from Zig:

• everything is explicit: error handling and even memory allocations
  • you have to handle all errors: in C++ or C you can just open files, read them, close them, and not handle any errors, and it won't complain during compilation. Zig code won't compile
  • this makes you think twice before allocating memory, probably resulting code with better performance
• cross-compilation is amazing:
  • the same code runs on linux/windows/macos/android/webassembly and can be compiled directly from my machine with just some flags in the build command.
  • yes, we have the virtual makeup running natively on android and it's a breeze to build (you still have to go through the JNI bridge, though).
• it's really easy to write portable SIMD code, due to native support in the language (this might become easier in C++ 26, though)
• the code compiles way faster: in C++ it took up to a minute to build the virtual makeup library from scratch, in Zig it takes about 10 seconds (and they're working on making the compiler faster)
• Zig's compile time reflection make metaprogramming a breeze compared to C++ templates or Rust's macros: it's all Zig.
• integrated tests in the language are a nice thing to have (and fuzzing is coming, too).
• optional types are great for null dereference stuff (mostly solved by C++ references though), but it makes Zig just have one kind of pointer, not pointers and references.
• the Zig build system is great: I don't miss CMake at all.

Probably the features I miss the most are:

• operator overloading from C++ (this goes against of the "everything is explicit" mantra of Zig, since overloaded operators could allocate memory, etc. That's why the matrix interface here is a bit cumbersome to use. Dlib's one is the best I've ever tried.
• default arguments for functions: again, they break the explicitness, you can go around by creating a function that takes a struct with default-initialized fields as an argument, though.

Some annoyances (compiler errors, as far as I know the Zig compiler does not have warnings):

• number casting is a bit tedious especiall for math operations: you have to do stuff like @as(f32, @floatFromInt(my_integer_variable))
• you can't declare var variables and don't mutate them
• you can't have unused variables
  But, on the other hand: https://andrewkelley.me/post/openzfs-bug-ported-zig.html

In C++ I was always going to cppreference to check for corner cases, etc.
I feel this language is small enough for my brain.
The bottom line is really this quote from their website:

Focus on debugging your application rather than debugging your programming language knowledge.

And Zig has few features but they're kind of orthogonal: no overlap and they compose together really well.
Something equivalent to Rust's traits or C++ concepts can be easily implemented with Zig's comptime and reflection.

Don't get me wrong, I love C++, but these are some nice things that I am not sure I can live without, unless I am doing dlib stuff.
That's right, I have been spoiled, I only want to do C++ in dlib.

Regarding the breaking changes of the language due to it not being stable yet:

• In about two years, there has been maybe a couple of times that my code broke, but it was very obvious how to fix it.
• A few days ago this landed, and it took me a bit longer to port the code, but I am excited about the direction of the project.
  • Writergate ziglang/zig#24329

Today I just wrote this, which I think it's kind of amazing to simplify the test for color space conversion: All my color types have methods to convert to other types: e.g.: rgb.toHsv(), rgb.toLab(), etc. If I have N color types, there are N-1 methods (the method to self-convert does not exist):

The code belows does this:

• define an array with all the color types
• from that list generate the names of all methods (concatenate "to" with the type name)
• iterate through all types and check it has all the methods except for the self one.
• perform a round trip conversion from RGB through the current color space and check the result.

This kind of stuff is a nightmare in C++.

zignal/src/color.zig

Lines 378 to 452 in 6f6992b

	/// List of color types to test. This is the only thing to update when adding a new color space.
	const ColorTypes = .{ Rgb, Rgba, Hsl, Hsv, Lab, Lch, Xyz, Lms, Oklab, Oklch, Xyb, Ycbcr };
	/// Strips all type names to their unqualified base names.
	fn getSimpleTypeName(comptime T: type) []const u8 {
	const full_name = @typeName(T);
	if (std.mem.lastIndexOf(u8, full_name, ".")) |dot_index| {
	return full_name[dot_index + 1 ..];
	}
	return full_name;
	}
	/// Generates the list of conversion methods based on the color type names.
	fn generateConversionMethods() [ColorTypes.len][]const u8 {
	var methods: [ColorTypes.len][]const u8 = undefined;
	inline for (ColorTypes, 0..) |ColorType, i| {
	const simple_name = getSimpleTypeName(ColorType);
	methods[i] = "to" ++ simple_name;
	}
	return methods;
	}
	/// Skip self-conversion methods (e.g., Rgb.toRgb doesn't exist)
	fn shouldSkipMethod(comptime ColorType: type, comptime method_name: []const u8) bool {
	if (method_name.len < 3 or !std.mem.startsWith(u8, method_name, "to")) return false;
	const target_type_name = method_name[2..]; // Remove "to" prefix
	const current_type_name = getSimpleTypeName(ColorType);
	return std.mem.eql(u8, current_type_name, target_type_name);
	}
	test "comprehensive color conversion method validation and round-trip testing" {
	@setEvalBranchQuota(10000);
	// Test colors for round-trip validation
	const test_colors = [_]Rgb{
	.{ .r = 255, .g = 0, .b = 0 }, // Pure red
	.{ .r = 0, .g = 255, .b = 0 }, // Pure green
	.{ .r = 0, .g = 0, .b = 255 }, // Pure blue
	.{ .r = 255, .g = 255, .b = 255 }, // White
	.{ .r = 128, .g = 128, .b = 128 }, // Gray
	.{ .r = 255, .g = 64, .b = 32 }, // Orange-red
	.{ .r = 64, .g = 192, .b = 128 }, // Teal-green
	};
	// Use metaprogramming to verify all color types have expected conversion methods
	// and test round-trip accuracy for each conversion
	inline for (ColorTypes) |ColorType| {
	inline for (comptime generateConversionMethods()) |method_name| {
	// Skip self-conversion and special cases
	if (comptime shouldSkipMethod(ColorType, method_name)) continue;
	// Verify method exists using @hasDecl
	try expect(@hasDecl(ColorType, method_name));
	// Test round-trip conversion accuracy for this specific method
	if (comptime std.mem.eql(u8, method_name, "toRgb")) {
	// For toRgb methods, test conversion from each test color
	for (test_colors) |test_rgb| {
	const intermediate_color = convertColor(ColorType, test_rgb);
	const recovered_rgb = intermediate_color.toRgb();
	try expectEqualDeep(test_rgb, recovered_rgb);
	}
	}
	// Special case: test RGBA round-trip
	if (comptime ColorType == Rgba and std.mem.eql(u8, method_name, "toRgb")) {
	for (test_colors) |test_rgb| {
	const rgba = test_rgb.toRgba(255);
	try expectEqualDeep(test_rgb, rgba.toRgb());
	}
	}
	}
	}
	}

[arrufat]

Right, most of the cross-compilation features of Zig are possible due to LLVM. However, Zig ships with the libc for all supported targets. Actually, you can have easier cross-compilation support in C and C++ by setting CC=zig cc and CXX=zig c++, then you can use them as drop-in replacement for a C compiler. It's also easier to install (zig is a statically linked binary that contains LLVM stuff).

That's why I started working on porting dlib to the zig build system. It would be especially useful for Python users, since zig is also available in pypi.

[pfeatherstone]

Regarding meta programming. Have you looked at these repos https://github.com/qlibs/reflect and https://github.com/qlibs/mp ? They substiantially simplify metaprogramming in C++20, probably even more so than actual c++26 reflection.

[arrufat]

I didn't know those, thank you!

[pfeatherstone]

Not having overloading for me would be a big loss. I see C++ as "C with overloading" more so than "C with classes"

[arrufat]

It was hard to accept... But debugging is way easier, you always know what function is being called. Still, the first months I missed it a lot.