New blog post! Learning Jai via Advent of Code.
This is a pretty lengthy summary of my early impressions.
https://www.forrestthewoods.com/blog/learning-jai-via-advent-of-code/
I'm a little nervous posting this one because it's the kind of topic where people have, ahem, strong opinions. Be kind y'all.
@forrestthewoods Thanks for writing this! I've been curious about Jai but it was really hard to find info on it (especially in textual form).
Small questions:
I assume if you copy a relative pointer somewhere else and then dereference it, it will just silently go wrong? Avoiding that in general would seem to require a full system of copy/move constructors etc. (or perhaps pinned types)
Big question:
Do you have any executive summary level thoughts or impressions on how it compares to Zig, especially w.r.t. the compile-time evaluation features? I've read various blog posts about Zig but haven't used it.
@glaebhoerl I did not have a good time when I tried Zig. So I can’t compare.
@glaebhoerl if the data needs to persist for some defined amount of time then it’s probably not appropriate for the temp allocator.
Temp is good if function is returning something it doesn’t care further about. And the caller only needs it briefly.
If you need more granularity you probably want to specify an arena. I think Jai is still figuring out the best way to handle cat2 and cat3 allocations. Like I said in the post.
@forrestthewoods Ah indeed, seems I got 1 and 2 mixed up there. Thanks!
@glaebhoerl it would explode if you didn’t also copy what it’s pointing at.
If you have a vector of structs with relptrs pointing to other elements in the vector and you make a copy it’d work. If they point to something else it’ll explode.
Which isn’t any different from copying structs with raw pointers. Except sometimes relptrs can be copied. For example loading an asset blob from disk that is full of internal relptr.
@forrestthewoods
The temporary allocator stuff is interesting... I was thinking that since there's only one, it sounds like a disaster waiting to happen when different parts of the code (especially once you have more than one module/library/etc) expect their temporary allocations to stay alive for different periods. Is there some general logic by which this is expected to be avoided? Does actually having multiple separate temporary allocators via contexts figure into it?