C interoperability

The official zig documentation gives you the Zig primitives and their equivalent in C, it is recommended to have a look at both of these links in order to realize what are the Zig equivalents for each C types.

In Zig, the for loop is not used as much as in C. Instead, the while loop is used more often. The for loop is used when iterating over multiples elements of a container (typically slices or arrays), so it basically is a kind of foreach loop. In all the other cases the while loop is used. Note that this changed recently and now Zig has new a way to simply iterrate in a loop with a for. But keep in mind that all the old code might still have that old while loop, even the official documentation still has some of them.

  const stdout = std.io.getStdOut().writer();
  const items = [_]u16 { 1, 4, 0, 1 };
  var sum: u16 = 0;

  // "foreach"
  for (items) |value| {
      sum += value;
  }

  stdout.print("Sum: {}\n", .{sum});

  // Old way
  while (i < 3) :(i += 1) {
      stdout.print("i: {}\n", .{i});
  }

  // New way
  for (0..3) |i| {
      stdout.print("i: {}\n", .{i});
  }

Zig has 2 different pointers:

• Single-item pointers: *T
• Many-item pointers: [*]T

Which can both be optional by adding a ?.

But actually…. there is a third pointer type:

• The C pointer: [*c]T

This one is to be avoided as much as possible. The only reasons for its existence is for the translation from C code to Zig code, when the translater is not able to know what to convert it to in Zig (eg. sometimes it does not know if it can convert it to a non-optional pointer or not which could cause undefined behaviors).

Since in Zig there is no implicit conversions, depending on the project you might end up having "ugly" code with a lot of explicit type conversions. The code is more verbose but it is also less error-prone. For instance in Zig:

  fn rgb_to_grayscale_1d(img: *imageh.img_1D_t, result: *imageh.img_1D_t) void {
      var i: usize = 0;
      while (i < @as(usize, @intCast(img.height * img.width))) : (i += 1) {
          const index = i * @as(usize, @intCast(img.components));
          const grayscale_value: u8 = @intFromFloat(imageh.FACTOR_R * @as(f64, @floatFromInt(img.data[imageh.R_OFFSET + index])) +
              imageh.FACTOR_G * @as(f64, @floatFromInt(img.data[imageh.G_OFFSET + index])) +
              imageh.FACTOR_B * @as(f64, @floatFromInt(img.data[imageh.B_OFFSET + index])));
          result.data[i] = grayscale_value;
      }
  }

and the C equivalent:

  void rgb_to_grayscale_1D(const struct img_1D_t *img, struct img_1D_t *result) {
    printf("height: %d", img->height);
    for (size_t i = 0; i < img->height * img->width; i++) {
      int index = i * img->components;
      uint8_t grayscale_value = (uint8_t)(FACTOR_R * img->data[R_OFFSET] +
                                          FACTOR_G * img->data[G_OFFSET] +
                                          FACTOR_B * img->data[B_OFFSET]);
      result->data[i] = grayscale_value;
    }
  }

export the function to the outside so that the C ABI can see it.

extern is used to link against an exported variable from an other object.

Zig documentation for those 2 keywords.

To test if integrating C code in Zig projects is really as seemless as some claims, I have decided to compare the C integration with Python.

In order to do that I wrote a small C library:

  int add(int a, int b) { return a + b; }

What I am going to do is test how much time it takes each program to run this function x times. (in this case x = 100'000'000)

Note: I did not use any optimization in flag in python (because it did not change anything) and neither in Zig because I did not want the compiler to try to optimize the code and not act as intended.

Then in order to compare the 2 languages I wrote 4 programs:

1: Zig code that has and add function implementation in Zig

  const std = @import("std");
  
  fn add(a: u32, b: u32) u32 {
      return a + b;
  }
  
  pub fn main() !void {
      var i: usize = 0;
      while (i < 100000000) : (i += 1) {
          _ = add(3, 7);
      }
      std.debug.print("done\n", .{});
  }

Result: ~0.38sec

2: Vanilla Python code that has and add function implementation in Python

  def add(a, b):
      return a + b
  
  
  for i in range(100000000):
      add(3, 7)
  print("done!")

Result: ~10sec

3: Zig code that imports the C library

  const std = @import("std");
  pub const c = @cImport({
      @cInclude("mylib.c");
  });
  
  pub fn main() !void {
      var i: usize = 0;
      while (i < 100000000) : (i += 1) {
          _ = c.add(3, 7);
      }
      std.debug.print("done!\n", .{});
  }

Result: ~0.41sec

4: Python code that imports the C library

  import ctypes
  
  mylib = ctypes.CDLL('./mylib.so')
  
  mylib.add.argtypes = (ctypes.c_int, ctypes.c_int)
  mylib.add.restype = ctypes.c_int
  
  for i in range(100000000):
      result = mylib.add(3, 4)
  
  print("Result of last addition:", result)

Result: ~50sec