Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Generic dynamic array in 60 lines of C

gist.github.com

Post reply on HN
Print view View original

31–40 of 110 posts

Re: Generic dynamic array in 60 lines of C

#31

Post by jalino23 »

ammar2 wrote: post #15
jalino23 wrote: post #11

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.)

try to find ffmpeg in go or rust that is < 5 years old and complete. how about intel libva,

Re: Generic dynamic array in 60 lines of C

#34

Post by rkeene2 »

nice_byte wrote: post #5

yes, i know growth by a factor of 2 has issues under certain usage patterns. those are less likely to be problematic when there is more stuff going on than just growing the buffer - you can use the "hole" for other allocations.

Hard to tease out what you're saying here, but maybe a Hashed Array Table (HAT) is what you're referring to ? I have a slightly extended version here [0][1]

[0] https://rkeene.org/viewer/tmp/hat.c.htm [1] https://rkeene.org/viewer/tmp/hat.png.htm

Re: Generic dynamic array in 60 lines of C

#35

Post by Night_Thastus »

cperciva wrote: post #14
WalterBright wrote: post #6

Heavy use of macros to do metaprogramming is a strong sign it's time to move to a more powerful language.

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.

Re: Generic dynamic array in 60 lines of C

#37

Post by olliej »

I 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

#38

Post by rootw0rm »

globalreset wrote: post #27
kzrdude wrote: post #13

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

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.

I think sqlite is fairly complex

Re: Generic dynamic array in 60 lines of C

#39

Post by klyrs »

DON'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 has barely even used this.

The code is unacceptably bad and unsafe. I don't usually do this, but I'm going to flag this post. I encourage everybody to do the same.

Apologies to the author. Golf is fun. This is uncool.

edit: changed size to [capacity]

Re: Generic dynamic array in 60 lines of C

#40

Post by int_19h »

cozzyd wrote: post #26
jpollock wrote: post #16

Earlier quoted context omitted.

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...

Yes, but if you're writing code that you want to be bindable to other languages, you essentially have to follow the C ABI, in which case, writing in C is a natural choice (yes, you can expose a C ABI from other languages, but that's usually not natural and you sort of have to understand C anyway to do that).

Unless your API surface constitutes the majority of your code, writing in C still doesn't make sense, because you're paying the tax every time you have to manually juggle strings and whatnot. C++ is a more sensible choice for this - you can still write C-compatible headers (and it's trivial to verify in builds - just include it in a .c file and see if that compiles!) while using STL etc in the implementation.
Post reply on HN