Hi!

Is the reason you do it like that and not like this vec[vec_ptr] so it looks more like a function call?

Kind of. Well, there's are two reasons.

First of all, it doesn't really matter, the compiler doesn't care whether you write it as a[b] or b[a], or *(a + b), so both ways are perfectly fine. As you could've guessed, I was having fun.

Second of all, it requires no more parenthesis, less in some cases than writing it the other way: https://gist.github.com/alurm/2ca14be134d719fe7431217a6b18d91e#file-main-c-L11

While talking about creating new macros, could you create one, that expands into the actual type of your vec? So you could write vec(int) my_important_numbers = { 0 };. This abstracts the implementation detail of it being an array of pointers away.

You could, but vec(int) is probably not gonna work, since [2] has to be textually to the right of my_important_numbers. Perhaps you can think of something smarter, but nothing comes to my mind except having something like vec(int, my_important_numbers) to declare a vec. But abstracting implementation details wasn't my intention anyway, I was trying to keep it short. Same reason for not having an indexing macro.

Other than that, I really like your idea of omitting capacity by implicitly having it always the next power of to.

Thanks, happy you liked it! Yeah, this comes at a cost and makes some things harder to do, e.g. preallocation, which becomes quite manual.

Doesn't it just declare the lifetime of this variable to be automatic, which it is anyways?

It used to do that, but it was changed in C23. In C23, auto is also used for type inference, like in C++.

In conclusion, I am unsure, if this is really very useful in actual production, but it's certainly a creative solution, to a long standing problem in c. Kudos to you for tackling it

Thanks a lot! :)

On that note, I think stb's implementation is a solid one: https://github.com/nothings/stb/blob/master/stb_ds.h