418

What is array to pointer decay? Is there any relation to array pointers?

Konrad Rudolph
  • 482,603
  • 120
  • 884
  • 1,141
Vamsi
  • 5,123
  • 6
  • 27
  • 32
  • 80
    little known: The unary plus operator can be used as an "decay operator": Given `int a[10]; int b(void);`, then `+a` is an int pointer and `+b` is a function pointer. Useful if you want to pass it to a template accepting a reference. – Johannes Schaub - litb Sep 22 '09 at 18:36
  • 3
    @litb - parens would do the same (e.g., (a) should be an expression that evaluates to a pointer), right?. – Michael Burr Sep 22 '09 at 19:30
  • 25
    `std::decay` from C++14 would be a less obscure way of decaying an array over unary +. – legends2k Mar 25 '15 at 06:43
  • 23
    @JohannesSchaub-litb since this question is tagged both C and C++, I'd like to clarify that although `+a` and `+b` are legal in C++ , it is illegal in C (C11 6.5.3.3/1 "The operand of the unary `+` or `-` operator shall have arithmetic type") – M.M May 31 '15 at 13:41
  • @matt you are right. But I already mentioned that this goodness only works in C++. Still I am thanksful to you for noting it for the case where someone else will miss my note aswell. – Johannes Schaub - litb May 31 '15 at 16:50
  • 5
    @lege Right. But I suppose that is not as little known as the trick with unary +. The reason I mentioned it wasn't merely because it decays but because it is some fun stuff to play with ;) – Johannes Schaub - litb May 31 '15 at 16:54
  • @JohannesSchaub-litb: It completely slipped my mind there even _exists_ a [unary plus operator](http://en.cppreference.com/w/cpp/language/operator_arithmetic) :-( – einpoklum Sep 22 '17 at 15:02
  • @JohannesSchaub-litb: this begs the question of whether use of a little-known language feature is good practice. What does this do to the readability of the code, both for the other present developers in the team and future developers? – Technophile Sep 10 '18 at 14:00
  • A made-up term. Until the addition of [`std::decay`](https://en.cppreference.com/w/cpp/types/decay) with C++11 the word "decay" appears exactly *zero* times in either the C or C++ standards throughout their *lifetimes*. That continues to be the case for C. I had a question on SO years ago pondering who first coined the term. No one knew. The furthest back anyone was able to trace was a uunet reply post c.1987. It made me wonder what people used to confuse new C engineers before that. – WhozCraig Oct 21 '18 at 03:17
  • @WhozCraig That's because the standard uses more formal terminology. See §6.7.6.3 7. – S.S. Anne Mar 20 '20 at 16:03

10 Answers10

305

It's said that arrays "decay" into pointers. A C++ array declared as int numbers [5] cannot be re-pointed, i.e. you can't say numbers = 0x5a5aff23. More importantly the term decay signifies loss of type and dimension; numbers decay into int* by losing the dimension information (count 5) and the type is not int [5] any more. Look here for cases where the decay doesn't happen.

If you're passing an array by value, what you're really doing is copying a pointer - a pointer to the array's first element is copied to the parameter (whose type should also be a pointer the array element's type). This works due to array's decaying nature; once decayed, sizeof no longer gives the complete array's size, because it essentially becomes a pointer. This is why it's preferred (among other reasons) to pass by reference or pointer.

Three ways to pass in an array1:

void by_value(const T* array)   // const T array[] means the same
void by_pointer(const T (*array)[U])
void by_reference(const T (&array)[U])

The last two will give proper sizeof info, while the first one won't since the array argument has decayed to be assigned to the parameter.

1 The constant U should be known at compile-time.

Community
  • 1
  • 1
phoebus
  • 13,661
  • 2
  • 30
  • 35
  • 9
    How is the first passing by value? – rlbond Sep 22 '09 at 18:54
  • 11
    by_value is passing a pointer to the first element of the array; in the context of function parameters, `T a[]` is identical to `T *a`. by_pointer is passing the same thing, except the pointer value is now qualified `const`. If you want to pass a pointer *to the array* (as opposed to a pointer to the first element of the array), the syntax is `T (*array)[U]`. – John Bode Sep 22 '09 at 19:35
  • 4
    "with an explicit pointer to that array" - this is incorrect. If `a` is an array of `char`, then `a` is of type `char[N]`, and will decay to `char*`; but `&a` is of type `char(*)[N]`, and will _not_ decay. – Pavel Minaev Sep 22 '09 at 19:39
  • 1
    oO the first and second declare the same function (the top-level const right before `array` is ignored). In C99, the toplevel const can also be specified for the first case - you can do `void by_value(const T array[const]);` - but this isn't significant in determining what function is declared. In any case, this answer probably should mention that `void f(int array[N]);` for any N > 0 is the same as `void f(int *array);`. – Johannes Schaub - litb Sep 22 '09 at 19:41
  • @rlbond: It's idiomatically "by value", not literally. – phoebus Sep 22 '09 at 20:12
  • @litb It's just meant to show some varying syntactic sugar there. – phoebus Sep 22 '09 at 20:35
  • 1
    In the third example, why would you even use `sizeof` when you already know that the array has `U` elements? :) – fredoverflow Jun 05 '14 at 10:37
  • 5
    @FredOverflow: So if `U` changes you don't have to remember to change it in two places, or risk silent bugs... Autonomy! – Lightness Races in Orbit Jun 05 '14 at 10:40
  • @LightnessRacesinOrbit If `U` changes its value or its name? – fredoverflow Jun 05 '14 at 10:41
  • 1
    @FredOverflow: Notice that these examples are not templates; `U` is presumably a stand-in for an integer literal, not a template parameter. Thus, the answer to your question, is "its value". – Lightness Races in Orbit Jun 05 '14 at 10:44
  • 1
    Array decay happens on function call, but also anywhere else an array is used but for `sizeof`, `&`, `decltype`, `alignof`, `alignas`. – Deduplicator Jun 09 '14 at 14:15
  • 5
    "If you're passing an array by value, what you're really doing is copying a pointer" That makes no sense, because arrays can''t be passed by value, period. – juanchopanza Sep 20 '15 at 13:38
  • There are actually six ways to pass in an array: the three non-mutating versions, which the answer already mentioned, and their mutating counterparts: `(T* arr)`, `T (*arr)[U]`, and `T (&arr)[U]`. – L. F. May 14 '19 at 13:19
108

Arrays are basically the same as pointers in C/C++, but not quite. Once you convert an array:

const int a[] = { 2, 3, 5, 7, 11 };

into a pointer (which works without casting, and therefore can happen unexpectedly in some cases):

const int* p = a;

you lose the ability of the sizeof operator to count elements in the array:

assert( sizeof(p) != sizeof(a) );  // sizes are not equal

This lost ability is referred to as "decay".

For more details, check out this article about array decay.

system PAUSE
  • 33,478
  • 18
  • 60
  • 59
  • 54
    Arrays are *not* basically the same as pointers; they are completely different animals. In most contexts, an array can be treated *as though* it were a pointer, and a pointer can be treated *as though* it were an array, but that's as close as they get. – John Bode Sep 22 '09 at 19:39
  • 21
    @John, please pardon my imprecise language. I was trying to get to the answer without getting bogged down in a lengthy backstory, and "basically...but not quite" is as good an explanation as I ever got in college. I'm sure anyone who's interested can get a more accurate picture from your upvoted comment. – system PAUSE Sep 23 '09 at 15:17
  • "works without casting" means the same as "happen implicitly" when talking about type conversions – M.M Mar 17 '15 at 03:39
51

Here's what the standard says (C99 6.3.2.1/3 - Other operands - Lvalues, arrays, and function designators):

Except when it is the operand of the sizeof operator or the unary & operator, or is a string literal used to initialize an array, an expression that has type ‘‘array of type’’ is converted to an expression with type ‘‘pointer to type’’ that points to the initial element of the array object and is not an lvalue.

This means that pretty much anytime the array name is used in an expression, it is automatically converted to a pointer to the 1st item in the array.

Note that function names act in a similar way, but function pointers are used far less and in a much more specialized way that it doesn't cause nearly as much confusion as the automatic conversion of array names to pointers.

The C++ standard (4.2 Array-to-pointer conversion) loosens the conversion requirement to (emphasis mine):

An lvalue or rvalue of type “array of N T” or “array of unknown bound of T” can be converted to an rvalue of type “pointer to T.”

So the conversion doesn't have to happen like it pretty much always does in C (this lets functions overload or templates match on the array type).

This is also why in C you should avoid using array parameters in function prototypes/definitions (in my opinion - I'm not sure if there's any general agreement). They cause confusion and are a fiction anyway - use pointer parameters and the confusion might not go away entirely, but at least the parameter declaration isn't lying.

Michael Burr
  • 311,791
  • 49
  • 497
  • 724
  • 2
    What is an example line of code where an "expression that has type 'array of type'" is "a string literal used to initialize an array"? – Garrett Jul 08 '14 at 02:45
  • 4
    @Garrett `char x[] = "Hello";` . The array of 6 elements `"Hello"` does not decay; instead `x` gets size `6` and its elements are initialized from the elements of `"Hello"`. – M.M Mar 17 '15 at 03:40
33

"Decay" refers to the implicit conversion of an expression from an array type to a pointer type. In most contexts, when the compiler sees an array expression it converts the type of the expression from "N-element array of T" to "pointer to T" and sets the value of the expression to the address of the first element of the array. The exceptions to this rule are when an array is an operand of either the sizeof or & operators, or the array is a string literal being used as an initializer in a declaration.

Assume the following code:

char a[80];
strcpy(a, "This is a test");

The expression a is of type "80-element array of char" and the expression "This is a test" is of type "16-element array of char" (in C; in C++ string literals are arrays of const char). However, in the call to strcpy(), neither expression is an operand of sizeof or &, so their types are implicitly converted to "pointer to char", and their values are set to the address of the first element in each. What strcpy() receives are not arrays, but pointers, as seen in its prototype:

char *strcpy(char *dest, const char *src);

This is not the same thing as an array pointer. For example:

char a[80];
char *ptr_to_first_element = a;
char (*ptr_to_array)[80] = &a;

Both ptr_to_first_element and ptr_to_array have the same value; the base address of a. However, they are different types and are treated differently, as shown below:

a[i] == ptr_to_first_element[i] == (*ptr_to_array)[i] != *ptr_to_array[i] != ptr_to_array[i]

Remember that the expression a[i] is interpreted as *(a+i) (which only works if the array type is converted to a pointer type), so both a[i] and ptr_to_first_element[i] work the same. The expression (*ptr_to_array)[i] is interpreted as *(*a+i). The expressions *ptr_to_array[i] and ptr_to_array[i] may lead to compiler warnings or errors depending on the context; they'll definitely do the wrong thing if you're expecting them to evaluate to a[i].

sizeof a == sizeof *ptr_to_array == 80

Again, when an array is an operand of sizeof, it's not converted to a pointer type.

sizeof *ptr_to_first_element == sizeof (char) == 1
sizeof ptr_to_first_element == sizeof (char *) == whatever the pointer size
                                                  is on your platform

ptr_to_first_element is a simple pointer to char.

John Bode
  • 106,204
  • 16
  • 103
  • 178
16

Arrays, in C, have no value.

Wherever the value of an object is expected but the object is an array, the address of its first element is used instead, with type pointer to (type of array elements).

In a function, all parameters are passed by value (arrays are no exception). When you pass an array in a function it "decays into a pointer" (sic); when you compare an array to something else, again it "decays into a pointer" (sic); ...

void foo(int arr[]);

Function foo expects the value of an array. But, in C, arrays have no value! So foo gets instead the address of the first element of the array.

int arr[5];
int *ip = &(arr[1]);
if (arr == ip) { /* something; */ }

In the comparison above, arr has no value, so it becomes a pointer. It becomes a pointer to int. That pointer can be compared with the variable ip.

In the array indexing syntax you are used to seeing, again, the arr is 'decayed to a pointer'

arr[42];
/* same as *(arr + 42); */
/* same as *(&(arr[0]) + 42); */

The only times an array doesn't decay into a pointer are when it is the operand of the sizeof operator, or the & operator (the 'address of' operator), or as a string literal used to initialize a character array.

pmg
  • 98,431
  • 10
  • 118
  • 189
  • 5
    "Arrays have no value" - what's that supposed to mean? Of course arrays have value... they're objects, you can have pointers, and, in C++, references to them, etc. – Pavel Minaev Sep 22 '09 at 19:40
  • 2
    I believe, strictly, "Value" is defined in C as the interpretation of an object's bits according to a type. I have a hard time figuring out a useful meaning of that with an array type. Instead, you can say that you convert to a pointer, but that's not interpreting the array's contents, it just gets its location. What you get is the value of a pointer (and it's an address), not the value of an array (this would be "the sequence of values of the contained items", as used in the definition of "string"). That said, i think it's fair to say "value of array" when one means the pointer one gets. – Johannes Schaub - litb Sep 22 '09 at 19:56
  • anyway, i think there is a slight ambiguity: Value of an object, and value of an expression (as in, "rvalue"). If interpreted the latter way, then an array expression surely has a value: It's the one resulting from decaying it to an rvalue, and is the pointer expression. But if interpreted the former way, then of course there is no useful meaning for an array object. – Johannes Schaub - litb Sep 22 '09 at 20:01
  • 1
    +1 for the phrase with a small fix; for arrays it's not even a triplet just a couplet [location, type]. Did you have something else in mind for the third location in array's case? I can't think of any. – legends2k Jul 08 '14 at 14:50
  • 1
    @legends2k: I think I used the third location in arrays to avoid making them a special case of only having a couplet. Maybe [location, type, *void*] would have been better. – pmg Jul 08 '14 at 15:55
  • @pmg what are you citing when you write `"decays into a pointer" (sic)`? I would like to read the original source of that information, but couldn't find it. – Rafael Eyng Jan 15 '20 at 02:59
  • @RafaelEyng: maybe it's abuse of the "(sic)" ... I've seen the usage `"arrays decay to a pointer"` (even `"arrays rot"`) in many posts here and other sites and that's why I used the `(sic)`. I tend to not use the expression myself and prefer `"arrays are converted to a pointer to their first element"` (though I may use the shorter version every now and then) because that is how the Standard describes what happens. – pmg Jan 15 '20 at 09:26
  • No problem. I thought you were citing some book of standard, I was interested in reading it – Rafael Eyng Jan 15 '20 at 20:55
9

It's when array rots and is being pointed at ;-)

Actually, it's just that if you want to pass an array somewhere, but the pointer is passed instead (because who the hell would pass the whole array for you), people say that poor array decayed to pointer.

Michael Krelin - hacker
  • 122,635
  • 21
  • 184
  • 169
  • Nicely said. What would be a nice array that does not decay to a pointer or one that is prevented from decaying? Can you cite an example in C? Thanks. – Unheilig Jan 10 '14 at 05:20
  • @Unheilig, sure, one can vacuum-pack an array into struct and pass the struct. – Michael Krelin - hacker Jan 10 '14 at 09:13
  • I'm not sure what do you mean by "work". It's not allowed to access past the array, though it works as expected if you expect what is really to happen. That behaviour (though, again, officially undefined) is preserved. – Michael Krelin - hacker Jan 10 '14 at 20:08
  • Decay also happens in many situations that are not passing the array anywhere (as described by other answers). For example, `a + 1` . – M.M Mar 17 '15 at 03:42
4

Array decaying means that, when an array is passed as a parameter to a function, it's treated identically to ("decays to") a pointer.

void do_something(int *array) {
  // We don't know how big array is here, because it's decayed to a pointer.
  printf("%i\n", sizeof(array));  // always prints 4 on a 32-bit machine
}

int main (int argc, char **argv) {
    int a[10];
    int b[20];
    int *c;
    printf("%zu\n", sizeof(a)); //prints 40 on a 32-bit machine
    printf("%zu\n", sizeof(b)); //prints 80 on a 32-bit machine
    printf("%zu\n", sizeof(c)); //prints 4 on a 32-bit machine
    do_something(a);
    do_something(b);
    do_something(c);
}

There are two complications or exceptions to the above.

First, when dealing with multidimensional arrays in C and C++, only the first dimension is lost. This is because arrays are layed out contiguously in memory, so the compiler must know all but the first dimension to be able to calculate offsets into that block of memory.

void do_something(int array[][10])
{
    // We don't know how big the first dimension is.
}

int main(int argc, char *argv[]) {
    int a[5][10];
    int b[20][10];
    do_something(a);
    do_something(b);
    return 0;
}

Second, in C++, you can use templates to deduce the size of arrays. Microsoft uses this for the C++ versions of Secure CRT functions like strcpy_s, and you can use a similar trick to reliably get the number of elements in an array.

snr
  • 13,515
  • 2
  • 48
  • 77
Josh Kelley
  • 50,042
  • 19
  • 127
  • 215
  • 1
    decay happens in many other situations, not just passing an array to a function. – M.M Mar 17 '15 at 03:44
1

tl;dr: When you use an array you've defined, you'll actually be using a pointer to its first element.

Thus:

  • When you write arr[idx] you're really just saying *(arr + idx).
  • functions never really take arrays as parameters, only pointers - either directly, when you specify an array parameter, or indirectly, if you pass a reference to an array.

Sort-of exceptions to this rule:

  • You can pass fixed-length arrays to functions within a struct.
  • sizeof() gives the size taken up by the array, not the size of a pointer.
einpoklum
  • 86,754
  • 39
  • 223
  • 453
  • arrays can be passed by reference to functions. And I don't get how `sizeof` giving the size of the array instead of the pointer is an exception to functions not taking arrays as parameters. The common problem is that `sizeof` does return the size of a pointer when used on a pointer originating from passing an array to a function – 463035818_is_not_a_number Mar 25 '21 at 10:35
  • 1
    @largest_prime_is_463035818 : My TL;DR talked about using an array in general, not just about passing it to a function. Also, edited to clarify you can pass an array by reference. – einpoklum Mar 25 '21 at 11:30
  • thanks, got it. "Sort-of exception" refers to the first line not to the "Thus" as I first misread it – 463035818_is_not_a_number Mar 25 '21 at 11:34
0

I might be so bold to think there are four (4) ways to pass an array as the function argument. Also here is the short but working code for your perusal.

#include <iostream>
#include <string>
#include <vector>
#include <cassert>

using namespace std;

// test data
// notice native array init with no copy aka "="
// not possible in C
 const char* specimen[]{ __TIME__, __DATE__, __TIMESTAMP__ };

// ONE
// simple, dangerous and useless
template<typename T>
void as_pointer(const T* array) { 
    // a pointer
    assert(array != nullptr); 
} ;

// TWO
// for above const T array[] means the same
// but and also , minimum array size indication might be given too
// this also does not stop the array decay into T *
// thus size information is lost
template<typename T>
void by_value_no_size(const T array[0xFF]) { 
    // decayed to a pointer
    assert( array != nullptr ); 
}

// THREE
// size information is preserved
// but pointer is asked for
template<typename T, size_t N>
void pointer_to_array(const T (*array)[N])
{
   // dealing with native pointer 
    assert( array != nullptr ); 
}

// FOUR
// no C equivalent
// array by reference
// size is preserved
template<typename T, size_t N>
void reference_to_array(const T (&array)[N])
{
    // array is not a pointer here
    // it is (almost) a container
    // most of the std:: lib algorithms 
    // do work on array reference, for example
    // range for requires std::begin() and std::end()
    // on the type passed as range to iterate over
    for (auto && elem : array )
    {
        cout << endl << elem ;
    }
}

int main()
{
     // ONE
     as_pointer(specimen);
     // TWO
     by_value_no_size(specimen);
     // THREE
     pointer_to_array(&specimen);
     // FOUR
     reference_to_array( specimen ) ;
}

I might also think this shows the superiority of C++ vs C. At least in reference (pun intended) of passing an array by reference.

Of course there are extremely strict projects with no heap allocation, no exceptions and no std:: lib. C++ native array handling is mission critical language feature, one might say.

Chef Gladiator
  • 659
  • 4
  • 18
0

Arrays are automatically passed by pointer in C. The rationale behind it can only be speculated.

int a[5], int *a and int (*a)[5] are all glorified addresses meaning that the compiler treats arithmetic and deference operators on them differently depending on the type, so when they refer to the same address they are not treated the same by the compiler. int a[5] is different to the other 2 in that the address is implicit and does not manifest on the stack or the executable as part of the array itself, it is only used by the compiler to resolve certain arithmetic operations, like taking its address or pointer arithmetic. int a[5] is therefore an array as well as an implicit address, but as soon as you talk about the address itself and place it on the stack, the address itself is no longer an array, and can only be a pointer to an array or a decayed array i.e. a pointer to the first member of the array.

For instance, on int (*a)[5], the first dereference on a will produce an int * (so the same address, just a different type, and note not int a[5]), and pointer arithmetic on a i.e. a+1 or *(a+1) will be in terms of the size of an array of 5 ints (which is the data type it points to), and the second dereference will produce the int. On int a[5] however, the first dereference will produce the int and the pointer arithmetic will be in terms of the size of an int.

To a function, you can only pass int * and int (*)[5], and the function casts it to whatever the parameter type is, so within the function you have a choice whether to treat an address that is being passed as a decayed array or a pointer to an array (where the function has to specify the size of the array being passed). If you pass a to a function and a is defined int a[5], then as a resolves to an address, you are passing an address, and an address can only be a pointer type. In the function, the parameter it accesses is then an address on the stack or in a register, which can only be a pointer type and not an array type -- this is because it's an actual address on the stack and is therefore clearly not the array itself.

You lose the size of the array because the type of the parameter, being an address, is a pointer and not an array, which does not have an array size, as can be seen when using sizeof, which works on the type of the value being passed to it. The parameter type int a[5] instead of int *a is allowed but is treated as int * instead of disallowing it outright, though it should be disallowed, because it is misleading, because it makes you think that the size information can be used, but you can only do this by casting it to int (*a)[5], and of course, the function has to specify the size of the array because there is no way to pass the size of the array because the size of the array needs to be a compile-time constant.

Lewis Kelsey
  • 2,465
  • 1
  • 13
  • 21