21–30 of 110 posts
Why use macros instead of inline functions?
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.
Heavy use of macros to do metaprogramming is a strong sign it's time to move to a more powerful language.
Here's one I've written a few years ago: https://github.com/kiryk/mlisp/blob/master/vector.c
You may find it dirty, but it can be wrapped using macros, and used both on LHS and RHS like in "string(v, i) = ch"
(the macros BTW) https://github.com/kiryk/mlisp/blob/71d028738d2f9607fa7ce8c1...
(and a usecase) https://github.com/kiryk/mlisp/blob/71d028738d2f9607fa7ce8c1...
Earlier quoted context omitted.
I don't have this luxury if I want to learn about ffmpeg libraries, its all written in c, almost all media and hardware accelerator libraries are written in c, you go to another language they just bind to c. its soo frustrating but I've no choice but to stick with c.
huh? What's wrong with using the higher level languages if they take care of binding to the C parts for you. (I know these are far an in-between for ffmpeg, too many leaky abstractions.)
Earlier quoted context omitted.
I don't have this luxury if I want to learn about ffmpeg libraries, its all written in c, almost all media and hardware accelerator libraries are written in c, you go to another language they just bind to c. its soo frustrating but I've no choice but to stick with c.
Most languages have the ability to call C functions. Use the language that helps you write your code and convert to call the third party API. For example, a C++ Vector provides a generic container and the code can still call C functions with the underlying array. This is in the "Doctor it hurts if I do X" bucket. https://stackoverflow.com/questions/2923272/how-to-convert-v...
Not an entirely uncommon idea. I've written one. There's also a well-known one here, in klib: https://github.com/attractivechaos/klib/blob/master/kvec.h
Part of the reason why C developers "feel" productive, but can't produce anything of meaningful complexity.
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.
Nevermind, I see how it's supposed to work now.
To your point, `RESIZE` is definitely incorrect. It should be checking the length before calling `realloc`.
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.
this somewhat mirrors what happens with a std::vector when you call resize() except of course c doesn't have default ctors. the point of resize is to make exactly "size" elements of the dynamic array addressable.
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.
~~Isn't the handling of `endptr` incorrect in `DYN_ARR_RESET` as well? `a.endptr = a.data;` feels very incorrect to me.~~ Nevermind, I see how it's supposed to work now. To your point, `RESIZE` is definitely incorrect. It should be checking the length before calling `realloc`.