91–100 of 110 posts
I don't like the use of macros for things like this. Macros in general should rarely or sparingly be used. I'm also not certain one should use "end pointers." Conventionally, it seems more advisable to use `size_t capacity`, `size_t length`, and `void *data`. Great use of Cunningham's Law, though! I appreciate C posts on Hacker News.
Amusingly, Ward Cunningham denies inventing Cunningham's law and I feel compelled to correct that potential misunderstanding.
DYN_ARR_RESET should probably be called DYN_ARR_INIT instead, as calling it more than once will leak memory. The handling of endptr in DYN_ARR_RESIZE seems to be incorrect. If I have an array with 2 elements and capacity of 3 and I DYN_ARR_RESIZE it to 5, I now have an array with 5 elements, 3 of which are garbage values.
Why do you say this is wrong? That's exactly what I would expect.
Seriously, in this day and age, why are we still stuck with C? There are battle tested container libraries in C++ for e.g.
I've seen too many C developers re-write C++ containers in C because they are afraid of C++, its madness.
This isn't C, this is preprocessor. Tomato tomato, who cares if it is 60 lines or 600. https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#400 https://docs.rs/containers/latest/src/containers/collections...
Section 6.10 (Page 145): Preprocessing Directives
Hey, would you look at that! The preprocessor is a mandatory part of the language!
Seriously, in this day and age, why are we still stuck with C? There are battle tested container libraries in C++ for e.g.
Yep, once you find yourself writing containers that are found in C++ its time to switch to it. I've seen too many C developers re-write C++ containers in C because they are afraid of C++, its madness.
The result is that you can easily link C code to almost any language, including C++, with almost any linker. But for C++, you usually have to use the linker that comes with the C++ compiler that compiled your library. You can write code in C++ that is as compatible as C, but you have to go out of your way to achieve that, extern "C" is only the beginning.
As a result, when the overhead of using C instead of a more complete language is not too great, I prefer to write my libraries in ANSI-C, for maximum compatibility.
[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3003.pdf
The biggest problem with this is that you cannot assign, pass, or return an "instance" of the array struct itself. That's because it's declared as an unnamed struct and in C two unnamed structs are not type compatible even if they have identical fields. C23 did improve struct compatibility [1] but unfortunately not for unnamed structs. [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3003.pdf
a.capacity That's not ideal. Imagine you are at 32GB capacity, the next realloc will ask for 64GB which is pretty excessive.
My understanding is that this is the typical behavior of dynamic arrays
Good ones might resize by the golden ratio, and enlarge by blocksize if larger