Timeline for C - Dynamic array handling advice
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 31, 2014 at 3:47 | vote | accept | Hr. Rabe | ||
| Dec 31, 2014 at 3:47 | history | edited | Hr. Rabe | CC BY-SA 3.0 |
added 1937 characters in body
|
| Dec 31, 2014 at 2:22 | comment | added | The Paramagnetic Croissant |
@Hr.Rabe … as you can no longer store 0 in the array, even though it's almost always desirable to be able to do so. What if you want an array of integers? Do you want { 1, 0, 2 } to be invalid? Surely not.
|
|
| Dec 31, 2014 at 2:21 | comment | added | The Paramagnetic Croissant |
@Hr.Rabe "Basically I do only need the space to store a integer 0 at the end of the stream, right? No matter the actual datatype." - no, that's wrong. In C, arrays are homogenous. If you are 0-terminating an array of Ts, then you need to terminate it with (T)0. "Can you elaborate a bit more on the error phrone bit? What are the errors I could expect?" - for one, you may forget the 0-terminator. (People forget to NUL-terminate their strings all over the place, even experts.) "Why is it so ugly?" - because it breaks symmetry, and you lose part of the domain…
|
|
| Dec 31, 2014 at 1:24 | comment | added | Lee Daniel Crocker | This will be deadly slow. Common vector implementations in C do a couple of things: first, keep the current allocation size, current occupied size, a pointer to the memory block, and other data in a struct. Also, they initially allocate some small amount of space like for 8 or ten items, then realloc more when needed rather than every time. A common strategy is to grow 1.5X when needed, that way performance on inserts scales well. | |
| Dec 31, 2014 at 0:45 | comment | added | dwn | (Not the original replier) I think in most implementations of vector, the capacity is the power of 2 >= the size. You may want to realloc in a similar fashion. I can see the error-prone issue, if you do for some reason need to store a NULL. In a large project, this would probably happen due to someone's carelessness. The performance, too, if it matters in your application. Seems like you could also use a stack, and keep null at the bottom, then just find it when you want to read from the bottom, if you are not wanting to store another pointer/var and will not be seeking the bottom often. | |
| Dec 31, 2014 at 0:41 | answer | added | hugomg | timeline score: 2 | |
| Dec 31, 2014 at 0:41 | answer | added | Hans Klünder | timeline score: 0 | |
| Dec 31, 2014 at 0:26 | comment | added | Hr. Rabe |
Hey, thanks for the comment. 1. Why would malloc(sizeof(NULL))fail? Basically I do only need the space to store a integer 0 at the end of the stream, right? No matter the actual datatype. 2. I buy the performance argument, that makes sence, thanks. 3. Can you elaborate a bit more on the error phrone bit? What are the errors I could expect? Why is it so ugly?
|
|
| Dec 31, 2014 at 0:24 | comment | added | The Paramagnetic Croissant |
malloc(sizeof(NULL)) will fail miserably if sizeof(NULL) < sizeof(void *). A safer idiom is T *p = malloc(sizeof *p) for some type T. Anyway, this 0-terminated array thing is very ugly, error-prone, and linear-time length querying can become a performance problem for large arrays. The usual practice when implementing a dynamic array is to maintain a base pointer and an explicit size.
|
|
| Dec 31, 2014 at 0:20 | history | asked | Hr. Rabe | CC BY-SA 3.0 |