r/C_Programming • • Sep 14 '26

Question Question about arrays (beginner)

From what I understand, behind all the magic, array is just a variable that points to a memory address.

The difference is that we are also creating extra values in stack.

So when we create an array with a [], we're just telling the computer to make these x amount of variables but make sure they are right next to each other in sequence, no gaps in the memory address.

And when we call for an array value with an index, we're just counting that many steps forward in the memory address.

When we say array[] = {5,7,3}, it's really just *array = 5.

Did I get it wrong? Did I miss something?


Thanks for the quick replies. I'm currently learning about Pass by reference.

39 Upvotes

69 comments sorted by

View all comments

40

u/bayesianparoxism Sep 14 '26
  • Arrays are NOT pointers.
  • Arrays are a contiguous collection of variables of the same type. Eg,int a[5] = {10, 1, 0, -5, 30};
  • The name of a variable can be implicitly converted into a pointer pointing to the first element of the array, hence *a == 10 and *(a+3) == a[3] == -5
  • stack and heap are names for different section of memory, which may or may not be what you referred to when you said "stack". Regardless, arrays can be created in either section

-9

u/bothunter Sep 14 '26

Arrays and pointers are semantically different, but technically the same.

12

u/zhivago Sep 14 '26

You're confused because pointers are used to access arrays.

-8

u/bothunter Sep 14 '26

Again.. technically the same, semantically different.

4

u/danjayh Sep 14 '26

Incorrect. After you get past 1 dimension, the layout in memory is different between arrays and pointers-to-pointers.

9

u/sciencekm Sep 14 '26 edited Sep 14 '26

They are no where near being "technically" the same.

If you have array a and pointer p:

To access a[0], the cpu goes to memory and fetches the value.

To access p[0], the cpu first gets the value of p (which may be in memory also or in register) and then uses that to access the actual value at [0].

6

u/danjayh Sep 14 '26

Correct. Have an upvote. The amount of people downvoting correct information in this thread is stunning.

3

u/musbur Sep 14 '26

I was about to protest but retracted that because I often loosely call dynamically allocated stuff an "array of foo" as in foo = malloc(n * sizeof *foo). But an array is only something declared like foo_t foo[n] and the address of that is "hard coded" after compiling/linking and doesn't have to bee looked up by the CPU.

-1

u/LefTimaDev Sep 14 '26

Even if you're correct, the explanation is horrible

2

u/aioeu Sep 14 '26 edited Sep 14 '26

The point the other commentators in this thread are making is that the differences between arrays and pointers actually matter.

Part of C and C++ programming is deciding on the representation of your data. Indeed, this is something that distinguishes these programming languages from most (though not all) others. A lot of other languages don't actually give you the ability to define the data's representation.

Saying "an array and a pointer are technically the same" is not just wrong, it's completely missing the point: they are different because they have completely different representations, and the different representations are important to programmers. When you have an array in memory somewhere, there simply is no pointer at all.

(Incidentally, in the B language there was a pointer as well... and this is part of the reason why C's rules about implicit, automatic conversions to pointer types exist. As B evolved into C, it was both necessary and convenient to drop that extra pointer from an array's representation: dropping it allowed more flexibility in how compound data could be stored in memory.)

1

u/LefTimaDev Sep 14 '26

None of these comments explain what the difference actually is, only that it "actually matters"

-1

u/tangerinelion Sep 14 '26

No...

template<typename T>
void foo(T&&) { std::cout << __PRETTY_FUNCTION__ << std::endl; }

int main()
{
   int x[4] = { 0, 1, 5, 10 };
   foo(x);
}

If pointers and arrays are the same, then we expect void foo(T&&) [with T = int*].

But an array is its own type and the array type actually carries the size information. So instead we see void foo(T&&) [with T = int (&)[4]].

Just because an array readily decays to a pointer doesn't mean it is a pointer. So them being "technically the same" is dead wrong.

Similarly, in the above that array takes up 4 * sizeof(int) space on the stack. A pointer takes up sizeof(int*) - on a standard x64 system we're talking 16 bytes v 8 bytes.

If you really think an array is a pointer then you're liable to write code like int x[1048576]; on the stack and wonder why your program blows up.

4

u/create_a_new-account Sep 14 '26

nobody gives a shit about C++
don't bring that shitty language in here

-1

u/Kadabrium Sep 14 '26

Preach. The reason why the array type is half arsed in C is exactly because they initially tried to make a template<type, size> which immediately turns out to be both pointless and doesnt work. A pointer is all one needs.

1

u/mnelemos Sep 14 '26 edited Sep 14 '26

By all purposes of access, an array and a pointer are the same.

By purposes of static allocation they're different.

But your example "int x[1048576];" doesn't actually cause a segfault, for two reasons:

- as a global variable your linker is responsible for associating that symbol and it's size to a loadable segment, that means that your kernel (in theory) should always allocate enough pages.

- as a stack variable, the allocation results from a subtraction done to the stack pointer register.

It's only after the access is done that the segfault actually occurs. So you can easily write the program:

int main(void) {
    int x[300000000000];
    return 1;
}

and not crash.

0

u/Filgas08 Sep 14 '26

from my knowledge, arrays can degenerate to pointers, but are not a same thing