6 ms·
Does anyone know why array arguments decay to pointers?
by acconsta 11y ago
Does anyone know why array arguments decay to pointers?
- doppelganger27 11y agoIn C (and in all other languages I can think of), an array is actually a pointer to a bunch of memory. Indexing into the array calculates offset from the array pointer, and grabs the item at that offset.
- nickcw 11y agoFYI the equivalent Go code would actually copy the whole array on the stack, and so it would be valid if possibly inefficient depending on the size of the array.
- ashearer 11y ago...and for anything larger than a small fixed-size array (like the example), you'd avoid data-copying overhead by passing a slice, which is a bounds-checked bundle of pointer and length.
- 36erhefg 11y agoArray is not a pointer. Your description of indexing is not correct, neither is the phrase "array pointer" you invented. The machine code produced will calculate the offset differently for a pointer and an array.
- doppelganger27 11y agoLet me clarify with an example. Suppose you have an array: int a[10] There is a section of memory of size sizeof(int) * 10 somewhere, and the variable a is a * int that points to that section. When someone does this: int x = a[2] It is equivalent to: int x = *(a+(sizeof(int)*2)) When I said "array pointer" in my previous comment, all it meant was the memory address that the variable (which is an array) points to (in the example, the variable "a") Edit: missing paren
- 36erhefg 11y agoa is a label, or an alias of a memory address. It is not a pointer. ( Your third example has a mistake, the correct increment is: a+2, because pointer arithmetic increments in object size not byte size ) Read this:http://eli.thegreenplace.net/2009/10/21/are-pointers-and-arrays-equivalent-in-c http://eli.thegreenplace.net/2009/10/21/are-pointers-and-arr...
- doppelganger27 11y agoInteresting read. Thanks :)
- GuamPirate 11y agoWell, the information isn't copied... so if you modified the incoming array you modify the original, so in that sense it has to be a pointer. Arrays and pointers are analogous in C except when they are declared, as there is an implicit allocation of information. Since we don't want this when it comes to array arguments, it simply decays.
- syncsynchalt 11y agoBecause that's how the machine sees C arrays. It would take an extra (invisible) parameter on the stack to implicitly pass the array size into the function, a thing which is very much against the spirit of C. The only real surprises/magic in C are things like: - addition/subtraction on typed pointers has an implicit multiply by sizeof(type) - type conversion between floats and ints
- acconsta 11y agoBut the size of C89 arrays is fixed and known at compile time. Why would the length need to be passed?
- klodolph 11y agoIt's not necessarily known by the caller, since the array might be declared with an unspecified size and defined in a different translation unit.
- acconsta 11y ago"might" is the key word there though. What if the array has a statically known size, like the code sample in the email? I suppose it could just be for consistency.
- maximilianburke 11y ago> Because that's how the machine sees C arrays. It would take an extra (invisible) parameter on the stack to implicitly pass the array size into the function, a thing which is very much against the spirit of C. It would only require a separate parameter if you needed to pass arbitrary-sized arrays. In this example, if the prototype contains the array size: int foo(char array[30]); It would not be difficult for the compiler to only allow arrays of that length to be passed as parameters, and no invisible parameters are necessary, assuming also that the function implementation made the same assumption of array length. Developers who handle arrays of arbitrary length tend to already encode a length parameter, it's this case where it looks to the developer like they are encoding a length value that is the deceptive/problematic case.
- augustk 11y agoBecause the compiler gets the length of an array from its declaration. However, inside a function the compiler cannot tell the size of the actual array parameter.
- acconsta 11y agoIf I write: void example(int a[10]); Why can't the compiler tell a is an int array of size 10 instead of a pointer?
- geocar 11y agosizeof(a) is sizeof(int*) in your example because of the C standard: That is to say this is a bug in the standard, and not a bug in any particular compiler.
- doppelganger27 11y agoThere is no strict difference between a pointer and an array (of any size) at run time in C. Arrays are just pointers to a section of memory, and it's up to the programmer to communicate how big that section is.
- 36erhefg 11y agoThere are whole separate chapters describing arrays and pointers in the C Standard. This is by definition a strict difference. You should read those chapters and please stop spreading this beginners misconception of C.
- pjmlp 11y agoBecause C designers decided to ignore other saner systems programming languages and thought it was a cool idea to do that. No, C wasn't the first systems programming language used to write OSes.
- esaym 11y agoBecause as Linus stated: "array arguments in C don't actually exist" The bracket notation ex: myarray[2] is actually just a sugar syntax for: * (myarray+2) An array is nothing more than an address and a (hopefully) know length. Not really a "data structure" or object by no means. You could definitely roll your own though with something like: struct { char * arr, int size } my_struct; for(int i = 0; i < my_struct.size; i++){ printf('%x', my_struct.arr[i]); } ect,
- acconsta 11y agoYeah. But why is that the behavior specified by the standard?