Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
As for "da": dstring append. Thus, dasprintf is "sprintf to a dstring, but append it to what's already there". If you mean dag_t, that's "directed acyclic graph".
And the code itself: heh, close. Not linked lists, but sets. The sets are implemented via a bit array (but that's a private implementation detail
). The code certainly code be implemented via linked lists (and the initial dag code did use lists), but using sets proved much easier (impossible to double-remove or double-add an item: no more looping through lists for removal, no worries about adding an item twice ).C's for-loops would have to be one of my favorite features of C. Any initializer, any test, any iterator. Using functions like I did in that code means I can change how sets are implemented and not worry about any code that uses them.
Alloca: hmm, well, I can think of a time: you're deep in the quake renderer somewhere and need a little bit of (variable sized) data. Since you're in a few loops deep, you don't want to use malloc (and friends). Hunk_TempAlloc is out of the question for some reason (does any engine other than QF have that one? I don't remember if I wrote it). alloca is your friend here: grab a chunk off the stack (very fast operation: two instructions on x86: sub esp,X; mov var,esp), work on the data, return from the function without worrying about freeing the code (exact same cost as having not used alloca: mov esp,ebp). Look in QF's libs/video/renderer/gl/gl_sky_clip.c for an example: very inner-loop. Or libs/video/renderer/r_light.c
For tool code: generally better to not use alloca. Image loaders: if you're in an inner-loop, you're doing it wrong
(doesn't mean alloca isn't handy, though). Anyway, alloca is a powerful tool that should not be used lightly. Much like that weapon in Krull: if you're not sure, it's not time to use it.
but then you also need to use freea so same story as malloc and free with the twitch that _malloca uses stack mem untill it overflows and then changes to heap mem.
C is usually pretty clear on where you might have done something it does not like on C++ though you get things like undefined vtables and other not so clear messages but it does indeed make certain operations easier when you get it right