121–130 of 147 posts
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.
if WGPUColorWriteMask.Alpha in mask and WGPUColorWriteMask.Blue in mask: ...Earlier quoted context omitted.
D just went ahead and implemented bit fields. They work, and it's hard to find any way to improve on them.
It's hard but they aren't perfect. You shouldn't rely on them for packing memory at all if you want to talk to other programs. Similarly bitfields mean you end up with "ints" that are actually 3 bits wide and so on.
While the layout is indeed implementation dependent, pragmatically if you stick to using ints the layouts are portable as far as I can tell. Just like the size of ints is implementation dependent, but is reliably 32 bits on 32 and 64 bit machines.
So `unsigned flag:1`?
These are not standard, so you need some preprocessor magic to choose the right thing. And so on...
Earlier quoted context omitted.
You can absolutely initialize bitfield members in structs, not sure where your memory is from… maybe it was broken on some specific compiler vendors/versions?
(6): error C7582: 't': default member initializers for bit-fields requires at least '/std:c++20' It is c++20 apparently https://godbolt.org/z/qvso544dr
In my opinion, syntactic sugar is, in fine, more useful and positive than "powerful" or "expressive" features that can lead to shorter but harder to decipher code. Syntactic sugar neve hurts.
Note that the main difference between packed structs and regular structs is not the dense bit packing, rather that regular structs are allowed to reorder the fields however they wish in memory. The compiler is free to optimize your struct. It's not free to do so in other languages (like C for example). Thus you get a way to define structs exactly, with bit level precision, to build complex protocols where you can decide what every bit means.
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.
Yes it would need to be: if ((mask & (WGPUColorWriteMask_Alpha|WGPUColorWriteMask_Blue)) == (WGPUColorWriteMask_Alpha|WGPUColorWriteMask_Blue)) { ... } ...which is quite a mouthful.
if (@popCount(mask & (WGPUColorWriteMask_Alpha|WGPUColorWriteMask_Blue)) == 2)
If it has some concise way to flip all the bits, then this would be another possibility that isn't too verbose, but might raise other objections. Let fmask be mask with all the bits flipped (how would one do that in Zig?).
if ((fmask & (WGPUColorWriteMask_Alpha|WGPUColorWriteMask_Blue)) == 0)
Earlier quoted context omitted.
Yes it would need to be: if ((mask & (WGPUColorWriteMask_Alpha|WGPUColorWriteMask_Blue)) == (WGPUColorWriteMask_Alpha|WGPUColorWriteMask_Blue)) { ... } ...which is quite a mouthful.
If you are willing to assume that the masks each only have 1 bit set, this would be less of a mouthful although it would draw other objections: if (@popCount(mask & (WGPUColorWriteMask_Alpha|WGPUColorWriteMask_Blue)) == 2) I do not know Zig, so the syntax might not be right. I did check to see that it has popcount [1]. If it has some concise way to flip all the bits, then this would be another possibility that isn't…
if (mask.alpha and mask.blue) {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.
static bool all_bits_set(i32 value, i32 mask) { return (value & mask) == mask; }
Alternatively you can use a #define. However, you need to use "mask" twice, so that gets tricky - either it requires care to keep the corresponding expression at the call site side-effect free. Or the macro needs to be written using compiler extensions like statement expressions and typeof() variable declarations à la Linux kernel.
Earlier quoted context omitted.
>always convert to big endian when sending data over a wire What is this awful advice. Only convert to big-endian where legacy demands it.
Meh. Network byte order is big endian. Otoh close to every device uses little endian internally and the conversion is pointless except for convention. Otoh it doesn't really matter, because the conversion is extremely fast (including hardware support in common processors). Endianness is really perfectly named: a meaningless difference that generations of people fight holy wars over.
It was a flip of a coin choice.
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…