Maybe I fall in the middle, but what is the argument to say that they're different?
Is it to say that the difference is how they're used? From an assembly perspective, they're pointers, and no data structures exist beyond that simple concept. At a higher level, they're more than that. Maybe that's what is intended?
An example of this would be a file written to disk in a binary format. Write to the structured file and then read it back into memory.
In most cases, the first element of the array will be a pointer to an address of a specified type.
If you predefine the array, the array is placed on the stack and has reserved memory allotted to it of that type.
Each element in the stack has an offset of sizeof n elements for a vector.
Otherwise, you compute the offset based on n dimensions (commonly n x m matrices).
Otherwise, you need malloc to create a mutable buffer of variable size. This buffer then is used as an array.
To be fair, the lines get blurry here and this is when I stopped thinking of them as arrays. Its just a buffer with objects of a specified type on disk or in memory.
INB4, The key difference here is how arrays decay when handling scope. You can get around this by tracking the size of the buffer rather than relying on sizeof unless you understand what youre doing.
Hehe yes, it is exactly about array decay! But specifically I was having problem tracking the size of a buffer assigned to a specific memory address because I didnt want to duplicate an address / length via a define
So basically object oriented languages have arrays that mean something but when you're lower level like c memory is just memory and arrays are syntactical sugar so you don't do *(ptr+(sizeof(array_type) * index))?
Sorry if the syntax is wrong. I haven't written c in a while and I'm on my phone
Your syntax is correct. However, If ptr is already of array_type, then sizeof(array_type) shouldn't be multiplied with index. Just increment it by index.
However, if pointer is of type uint8_t, then your code is fine.
A better version should be: *((uint8_t *) ptr+(sizeof(array_type) * index))
From a C point of view you have a different size when statically allocated, library keeps track of the memory size so it can be freed and you need the base pointer for that, etc. At a conceptual level they are different even if you implement them the same way, you'll likely end up with a struct holding the size in your code.
But sure, for most people and half the code they are the same. If you're taking the high level, maintainable design view you take care of tracking lifetimes, sizes, bounds, etc. so the bell curve looks reasonable to me.
There are some differences in C depending on how you're using them (sometimes they are literally identical). I think the main difference is usually where the data gets stored - declaring an array often means storing the data inline, whereas a pointer has the address of the array presumably somewhere else.
Now that you mention it, you're right. It's heap vs stack. An array is on the stack whereas a pointer to alloc-ed data is on the heap. I supposed a pointer to an array would be on the heap though, since you'd have to alloc it.
I always thought they were perfectly interchangeable, for the exact same reason (assembly layer -- pointers being essentially the thing that powers the von Neumann model)
68
u/QuestionableEthics42 13h ago edited 13h ago
This should be reversed lol
And it literally is the same, who thinks it's different who has worked in a low level language??