#Resizable Structs in Zig

1 messages · Page 1 of 1 (latest)

ionic flame
spark drift
#

I never follow bare links without more context on what's at the other end. Care to say a illtle more about why this is of interest and where it is applicable?

ionic flame
#

it is about resizable structs in Zig; which is interesting because structs are not usually thought of as resizable. it's applicable when you would like to resize a struct in Zig

#

I apologize for being snarky but I just don't know how to expand on it anymore than the title without regurgitating the article 😛

#

it's a static site with no JS and it won't hurt, promise

dry quarry
#

Neat article. The way you implemented it and the API you came up with is pretty good. I've got some cases where I piece out a single allocation as multiple slices of differing types, and the pointer arithmetic and casting can be kinda brittle - an abstraction like this would help a lot.

I will say though that despite being very familiar with the concept, I didn't fully understand what the article was about until I got about 70% through and read this line:

And yet, all of this data is stored contiguously in memory, without having to allocate each individual field separately!
The term 'resizable struct' was super unclear to me. It would be worth explaining the exact memory layout of such a thing at the start of the article; I guess you could describe it as a length header followed by a variable number of elements for each field all in one allocation. Flexible array members in C are a very similar concept, so referencing them would be good too.

glass turtle
#

Damned, this is even better than VLA because you can have more than one at the end of a struct !

ionic flame
#

The term 'resizable struct' was super unclear to me.

I totally agree that there is room for improvement here. It's the big reason why I am looking for more use-cases. What this thing is, is not clear, but I can tell it can be useful for more people.

I think the current name gives too much of an impression that it IS the data that it stores behinds its pointer, but it's more akin to an (as someone rudely put it) 'obese' slice. so I think a name that conceptualizes it as a utility rather than a struct might be better.

I did not write it with the intent of holding onto the value it produces for very long. it's basically a tool for fool-proof pointer arithmetic

crystal agate
#

Very cool! I was just wondering if something like this existed.