#Writing i32s to byte array - idiomatic zig?

1 messages · Page 1 of 1 (latest)

regal loom
#

I came up with this.

test "writing ints to byte array" {
    const x: i32 = 74;
    const y: i32 = -9880;

    var result: [8]u8 = undefined;

    var index: usize = 0;
    
    for (@bitCast([4]u8, x)) |b| {
        result[index] = b;
        index += 1;
    }

    for (@bitCast([4]u8, y)) |b| {
        result[index] = b;
        index += 1;
    }

    try testing.expectEqual(@bitCast(i32, result[0..4].*), x);
}
torpid basin
cinder abyss
#

I would do:
std.mem.bytesAsValue(i32, &four_bytes).* = my_i32_value;

torpid basin
cinder abyss
#

so your example would look like:

test "writing ints to byte array" {
    const x: i32 = 74;
    const y: i32 = -9880;

    var result: [8]u8 = undefined;

    std.mem.bytesAsValue(i32, result[0..4]).* = x;
    std.mem.bytesAsValue(i32, result[4..8]).* = y;

    try testing.expectEqual(@bitCast(i32, result[0..4].*), x);
}
torpid basin
#

or use an fbs

cinder abyss
#

i guess it depends what he's trying to do

torpid basin
#

right

cinder abyss
#

if he wants just to do this once or twice, my method makes sense

frigid dust
#

std.mem.writeInt is a good one

cinder abyss
#

Otherwise, I'd personally opt for a std.io.FixedBufferStream

#

but yeah, looping over the individual bytes probably not the best idea

glass quiver
#

I would consider this:

@ptrCast(*align(1) i32, &array[0..]).* = my_i32;
@ptrCast(*align(1) i32, &array[4..]).* = my_i32;
torpid basin
#

but why

cinder abyss
#

v unsafe aaaa

torpid basin
#

there's perfectly good stuff in std

regal loom
#

I have to be honest I don't understand the types of std.mem.writeInt.

I tried

test "writing ints to byte array" {
    const x: i32 = 74;
    const y: i32 = -9880;

    var result: [8]u8 = undefined;

    std.mem.writeIntSlice(i32, result[0..4], x, .Little);
    std.mem.writeIntSlice(i32, result[4..8], y, .Little);

    try testing.expectEqual(@bitCast(i32, result[0..4].*), x);
    try testing.expectEqual(@bitCast(i32, result[4..8].*), y);
}
torpid basin
#

wdym by the types of std.mem.writeInt?

regal loom
#

buffer: *[@divExact(@typeInfo(T)..bits, 8)]u8

torpid basin
#

that just means

#

a non-const slice that can hold your int

#

that's it

cinder abyss
#

as an optimisation nitpick, try to ensure that your array is aligned correctly, as in:
var result: [8]u8 align(@alignOf(i32)) = undefined;

#

this will speed up your code if it's particularly performance-sensitive

glass quiver
torpid basin
regal loom
cinder abyss
#

since zig can't generate code with a single write, it'll have to write byte-by-byte

regal loom
torpid basin
#

wdym??

#

you can totally

glass quiver
torpid basin
#

^

cinder abyss
#

lewis

#

what are you actually using this for?

torpid basin
#

also writeIntSlice and writeInt(Little/Big) etc.

#

are literally the same thing

regal loom
torpid basin
#

except the endianess is specified differently

cinder abyss
regal loom
glass quiver
torpid basin
#

slices are just struct {len: usize, ptr: [*]T}

#

that's it

regal loom
torpid basin
#

but yeah please use a writer of some sort if you're gonna write tons of stuff out, it'll just be easier and futureproof your setup when you wanna change where you're writing to/how you're writing

torpid basin
#

that doesn't really mean anything

#

a slice is a slice

#

oh if you mean [x..y] is a slice and that it acts like passing any old pointer than yes kinda

regal loom
#

yeah can't remember the exact term

#

looks like it wasn't "degrade", not in manual

glass quiver
#

I think you mean 'decay' --- though, Zig doesn't do that here; it actually just yields a different type based on whether the indices are comptime-known or not.

#

Which can trip you up if you're assuming it's always a slice 😄

regal loom
torpid basin
#

also please dont prematurely optimize

regal loom
#

please read that knuth quote in context 😉

torpid basin
#

hey you do you

#

your software your problem

#

:P

regal loom
#

no I think it's important to understand what knuth was actually saying

#

because you'll find when you get into industry a lot of people throw it around without grokking it

cinder abyss
#

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

regal loom
#

thanks @cinder abyss I was trying to find it

cinder abyss
#

too many programmers think this means "don't optimise when you haven't written everything yet"

regal loom
#

this bit is the critical 3%

torpid basin
#

yes but is this really the 3%?

cinder abyss
#

easier to optimise when laying things out from the start, than have to rework and refactor

torpid basin
#

that'd probably be your db logic rather than how you encode data in your database tbh

regal loom
#

it's absolutely the critical 3%

torpid basin
#

ok now measure that and tell me how much it improves performance

#

you'll find a lot of programmers grok optimization techniques

#

without verifying the original context first

#

:v)

cinder abyss
#

i don't see much harm in ensuring optimal alignment here

torpid basin
#

ik im just trolling now

cinder abyss
#

i can tell :^)

torpid basin
#

anyways i think this question is answered right?

#

gotta clean up the clutter or whatever so i dont give the forum haters ammo

regal loom
#

marks as SOLVED