On: Memory-efficient enum arrays in Zig

[kazinator]

You can solve this problem if a few clear lines of GNU C. We declare two sister types, one of which is packed:

  typedef struct taggedunion {
    unsigned char tag;
    union tu {
      uint64_t   u64;
      uint32_t   u32;
      uint8_t    u8;
    } u;
  } taggedunion_t;

  typedef struct __attribute__((packed)) packed_taggedunion {
    unsigned char tag;
    union tu u;
  } packed_taggedunion_t;

Then accesses to our dynamic array will convert between the packed stored representation and the unpacked one in a straightforward way:

  taggedunion_t array_get(packed_taggedunion_t *a, size_t i)
  {
    return (taggedunion_t){ a[i].tag, a[i].u };
  }

[loeg → kazinator]

Your packed union eliminates pure padding, yes, but it still costs 9 bytes to store a u8 value and misaligns accesses for wider elements. These are both significant misses on "solving the problem." You also need to copy each element on access, which could be expensive for larger plain-old-data types, or especially for non-POD types.

[cryptonector → kazinator]

But it's C. The idea here is to have higher-level, type-safe languages do this transformation automatically.

[WhereIsTheTruth → kazinator]

For any language to be labeled as a "better c" language, it must solve this problem, having better enums is a requirement

It's actually one of the reason I initially gave Zig a try, not Comptime, it was Tagged Union

[masfuerte → kazinator]

But this still takes 9 bytes (at least) to store a tagged uint8_t.

[kazinator → masfuerte]

The article's approach requires 8 bytes, plus a separate array of 1 byte tags.

The article reduces it to 4 bytes, plus an array of 1 byte tags, by dropping the requirement for a 64 bit member.

If we have to grow the array, we have to do two reallocations.

Caching is worsened: the tag and content are going to be in separate cache lines.

[masfuerte → kazinator]

The final approach in the article is an array for each unique object size plus tagged indices/pointers. This would take one byte per uint8_t and doesn't suffer from the problems you mention, though it does have others. If memory pressure is your main problem it's a big win.