Live data from Hacker News

Packed structs in Zig make bit/flag sets trivial

devlog.hexops.com

141–147 of 147 posts

Re: Packed structs in Zig make bit/flag sets trivial

#141

One area where this is still less flexible than regular bit masking is that quite often I want to access groups of bits as a value. For instance if the bits represent in/out pins on a chip emulator, sometimes I want to access unique data bus pins, and sometimes I want to set or get the data bus value. Maybe Zig can handle this case with unions though, I haven't tried this yet (this would require that unions can work…

`@bitCast` addresses this use case:

    const std = @import("std");
    const expect = std.testing.expect;

    test {
        const group1: P = .{ .a = true, .b = true };
        const group2: P = .{ .c = true };
        const group3 = @bitCast(P, @bitCast(u4, group1) | @bitCast(u4, group2));
        try expect(group3.a);
        try expect(group3.b);
        try expect(group3.c);
        try expect(!group3.d);
    }

    const P = packed struct {
        a: bool = false,
        b: bool = false,
        c: bool = false,
        d: bool = false,
    };

Re: Packed structs in Zig make bit/flag sets trivial

#142
post #119

Earlier quoted context omitted.

Not really relevant to a discussion about CPUs and compiler implementations...

It's a language design feature that makes some sorts of networking code much easier to write. Why wouldn't that be relevant?

Nobody ever writes code for memory mapped network devices!!

Re: Packed structs in Zig make bit/flag sets trivial

#143

Earlier quoted context omitted.

There is nothing arbitrary whatsoever about the conversion of any string of bits to a boolean, it is false iff none of the bits are 1. If you want to call it arbitrary, it's been arbitrated decades ago, but Boolean logic is much older than computers and works as it does for a reason. I suspect you know that.

the number 9, is not the same thing as "true". some people may want it to be, it might be convenient for some people if a compiler treats them as the same thing, but they aren't. In my opinion, its an anti-pattern to have the compiler make these type of decisions. Instead of writing and reading code that is explicit, you're writing an abbreviated version of what you want, and assuming that the compiler will know what…

It's Go pretending it's a kind of language it isn't, and making the user do the teapot dance instead of cooperating.

People keep telling me this koolaid is delicious but I just don't see it.

Re: Packed structs in Zig make bit/flag sets trivial

#144

Earlier quoted context omitted.

the number 9, is not the same thing as "true". some people may want it to be, it might be convenient for some people if a compiler treats them as the same thing, but they aren't. In my opinion, its an anti-pattern to have the compiler make these type of decisions. Instead of writing and reading code that is explicit, you're writing an abbreviated version of what you want, and assuming that the compiler will know what…

It's Go pretending it's a kind of language it isn't, and making the user do the teapot dance instead of cooperating. People keep telling me this koolaid is delicious but I just don't see it.

It seems you ran out of actual arguments, sorry to hear that.

Re: Packed structs in Zig make bit/flag sets trivial

#145

Earlier quoted context omitted.

It's Go pretending it's a kind of language it isn't, and making the user do the teapot dance instead of cooperating. People keep telling me this koolaid is delicious but I just don't see it.

It seems you ran out of actual arguments, sorry to hear that.

You can't argue with someone who doesn't understand logic, which is literally true here. I have run out of jokes at Go's expense.

Re: Packed structs in Zig make bit/flag sets trivial

#146

Earlier quoted context omitted.

It seems you ran out of actual arguments, sorry to hear that.

You can't argue with someone who doesn't understand logic, which is literally true here. I have run out of jokes at Go's expense.

I think I made my point known. Converting int to boolean is not a settled task, as different people might not agree on what the correct way is to do that. False could be zero, or negative one, or any negative number, or even one. So its better not to have the compiler make that decision, and just have the code be explicit about what its trying to do.

Re: Packed structs in Zig make bit/flag sets trivial

#147
post #7

if (mask & (WGPUColorWriteMask_Alpha|WGPUColorWriteMask_Blue)) { // alpha and blue are set.. } Doesn't this give you if alpha OR blue is set? Errors like this are another reason syntactical sugar for readability is important.

You don't need syntactical sugar. Just write a function. static bool all_bits_set(i32 value, i32 mask) { return (value & mask) == mask; } Here I'm assuming 32-bit values. In C, with relatively little support for generics, you can consider making multiple versions, possibly using _Generic (note, I haven't evaluated the sanity of using _Generic). Alternatively you can use a #define. However, you need to use "mask" twic…

Yeah the usual way in C would be to use statement expression (which is a GCC extension but is supported by at least clang and msvc)

    #define all_bits_set(value, mask) ({__typeof__(value) v = (value), m = (mask); (v & m) == m; })
I personally would go for the extension aboveor a single 64 bit function, but here's the _Generic version:

    static bool all_bits_set32(i32 value, i32 mask) { return (value & mask) == mask; }
    static bool all_bits_set64(i64 value, i64 mask) { return (value & mask) == mask; }
    #define all_bits_set(value, mask) _Generic((value), int32_t: all_bits_set32, int64_t: all_bits_set64)(value, mask)
Post reply on HN