Heavy use of macros to do metaprogramming is a strong sign it's time to move to a more powerful language.
Lisp?
Generic dynamic array in 60 lines of C
41–50 of 110 posts
Re: Generic dynamic array in 60 lines of C
#42Re: Generic dynamic array in 60 lines of C
#43Not 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
Who didn't. Almost any C program dealing with strings and collections has to have their own implementation or import one. Part of the reason why C developers "feel" productive, but can't produce anything of meaningful complexity.
Anyway, I think this HN posting has this "crazy" flavor of using macros to simulate generics, and that's the specific kind of implementation that I meant, which klib also does.
Re: Generic dynamic array in 60 lines of C
#44DON'T USE THIS As fpoling points out, capacity is a 32-bit unsigned. That can overflow. There is no safety in append: if capacity is zero no new space will be made, if capacity overflows the realloc will not have enough space -- in either case, you end up writing past the end. Allocating a [capacity] zero array and appending to it is extremely common. That you'll write past the end in that case shows that the author…
Re: Generic dynamic array in 60 lines of C
#45I dislike this - having the “array” be a struct containing the pointer and size fields makes it easy to “copy” the array such that you get dangling pointers. Similarly there’s no way to track lifetime or ownership of the array. There are long term ABI benefits to these data structures just being opaque pointers outside of the implementing libraries
Re: Generic dynamic array in 60 lines of C
#46DON'T USE THIS As fpoling points out, capacity is a 32-bit unsigned. That can overflow. There is no safety in append: if capacity is zero no new space will be made, if capacity overflows the realloc will not have enough space -- in either case, you end up writing past the end. Allocating a [capacity] zero array and appending to it is extremely common. That you'll write past the end in that case shows that the author…
I have been using this for years. Capacity is not size. A zero size array will have non zero capacity. All c code is unsafe.
a.capacity
"all c code is unsafe" is not an excuse to permit bloody obvious, undocumented memory overruns.I write a lot of c. Avoiding the unsafe bits, avoiding UB, is the skill required to write good c. "C code is unsafe" is a Rustacean marketing slogan. Don't believe it, but definitely don't practice it.
Re: Generic dynamic array in 60 lines of C
#47Re: Generic dynamic array in 60 lines of C
#48Earlier quoted context omitted.
C + a set of macros is a more powerful programming language.
Also a far worse language though. Macros have their place, but trying to do anything complex with them just turns into a total nightmare. They're hard to reason about, walk through, or modify. If heavy macro usage is found, it's definitely time to reconsider the approach.
Macros can be a nightmare, but when they're used properly they're not.
Re: Generic dynamic array in 60 lines of C
#49Earlier quoted context omitted.
I have been using this for years. Capacity is not size. A zero size array will have non zero capacity. All c code is unsafe.
Where do you check that capacity is nonzero? When capacity is zero, what happens on this line? a.capacity "all c code is unsafe" is not an excuse to permit bloody obvious, undocumented memory overruns. I write a lot of c. Avoiding the unsafe bits, avoiding UB, is the skill required to write good c. "C code is unsafe" is a Rustacean marketing slogan. Don't believe it, but definitely don't practice it.
Re: Generic dynamic array in 60 lines of C
#50Not 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
Who didn't. Almost any C program dealing with strings and collections has to have their own implementation or import one. Part of the reason why C developers "feel" productive, but can't produce anything of meaningful complexity.