Would a constant-size array int x[20] be smaller than a dynamic array int * x = new int[20], since the dynamic array is a pointer, which takes up space? Or is the constant-sized array a pointer too? Why or why not?
Another question: Something I've never been 100% sure about is, on a 32-bit machine, are pointers 32 bits long? And are pointers treated the same way as regular variables when it comes to the location in the RAM in which they are stored?
Help would be very much appreciated.
The dynamic array is not a pointer - but you do need a pointer as well as the array, so the allocated version uses more space. The advantage of the allocated version is that you can allocate the correct amount of space, rather than having to allocate more space than you normally use (e.g. you can allocate exactly 37 integers, rather than having to allocate 100 just in case the size is as big 100).
Yes, 32-bit machines have 32-bit pointers, essentially without exception.
Yes, pointers are treated the same as other variables when located in RAM.
Would a constant-size array int x[20] be smaller than a dynamic array int * x = new int[20], since the dynamic array is a pointer, which takes up space?
The memory address(es) of both have to be stored, be it the offset of the first element in the constant-sized array or the pointer to the dynamic array. The arrays themselves are equal size and (I believe) the other data is as well.
The constant-sized array variable, x, can be used in some ways similar to a pointer, but is not a pointer in and of itself, it's an array.
The 32-bit and 64-bit typically refer to the memory addressing, so pointers are 32-bits on a 32-bit system and 64 on 64.
Pointers are very much like integers and are stored in memory the same way (you can convert a pointer on a 32-bit machine to a dword and it won't lose information). They simply refer to an offset in memory somewhere else, where the actual data is stored.
The dynamic one will use more memory; how much more depends on the size of pointers and the size of the memory allocator's metadata.
On any modern machine, as @Jonathan says, 32-bit machines use 32-bit pointers and there is no significant difference (aside from stack vs. heap) in how pointers are handled vs. data. Older machines (or even a newer one if you build in "real mode" with split instruction and data spaces) will distinguish between function and data pointers, but not in where they themselves are so much as which address space they point within.
Some very old machines and some experimental architectures — none of which you are ever likely to encounter — actually manage pointers and sometimes data differently; Emacs's historical handling of integers (stealing one or more bits for internal use) reflects the use of "tag bits" on some old architectures. You may also occasionally encounter (mostly older) programs which "know" that pointers should be aligned on 4-byte boundaries and borrow the bottom 2 bits of pointers for other purposes (garbage collection state was a common use).
My understanding is that the constant-size array name is a pointer to the first item in the array (essentially)
This depends on what you want to know the size of.
The size of the variable x will certainly be smaller in the case of the int* x = new int[20]. In this case x is just a pointer and hence has pointer size (typically 4 bytes on a 32 bit system and 8 bytes on a 64 bit system). In the other case x is actually a statically allocated array of length 20 so it's size will be sizeof(int) * 20.
If you're talking about the size of the actual array though there really is no difference. The issue is where will it be allocated. In the int x[20] it will be typically on the stack while the pointer version will be on the heap
