All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
I worded it wrong, it seems. It should state "how an array is similar to a pointer" or the like. This isn't about what an array is, but rather how you think.
If you'd take a look at pointers and type, which is right:
int* p;
int * p;
int *p;
The first says that the type is a pointer to integer, but the other two doesn't, and I'm not mistaken, not one of them is entirely right.
So it's a matter of thinking. When I think of an array as a pointer, I don't get confused when an array "decays" to a pointer, because it's just always a pointer. And I don't have to worry about syntax as passing an array always passes a pointer. And taking the address of an array takes the address of the pointer, so it would be come type**. You can see why treating an array as a pointer gives advantages to confusion.
So I don't make statements against the standard, I make statements of how I or others could possibly think in lines of, to make things easier when dealing with the language.
No it doesn't:
Yes, the code is similar, but pntr contains a different value and the opcode to load eax is different - first piece of code takes the offset (address of) the array, the second takes the content of a dword.Code:array db "Somestring", 0 pntr dw array func: mov eax, offset array xor ecx, ecx 1: mov bl, [eax+ecx] test bl, bl jz $2 inc ecx jmp $1 2: mov eax, dword ptr pntr 4: mov bl, [eax+edx] test bl, bl jz $3 inc edx jmp $4 3:
The above code is something I just hacked up to do roughly this:
I'm sorry, but you're wrong - although pointers and arrays can be used interchangeably in places, they aren't the same thing.Code:char array[] = "Soemstring"; char *pntr = array; void func() { int c; for(c = 0; array[c]; c++) ; for(d = 0; pntr[d]; d++) ; }
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
But mats, from the code I see, the compiler treats the array just like any other variable on the stack and therefore takes the address of that local stack variable, similarly to the pointer where you also take the address.
The array is stored on the stack, this we know, but the array, the name of the variable of the array, is treated like a pointer. That's what my thinking is all about and why I treat array and pointer the same.
You just removed the first step in the process, to get the address of the the memory block first.
But as I mentioned already, it's just a matter of thinking, not stating.
Yes, of course, if it's a local array, you'd get a "lea" (load effective address) to get the address, rather than the offset of a global variable - the local variable is kept as an offset from the top of stack. But they are still different - yes, the ACCESSING OF THE CONTENT IS THE SAME - which is what makes them similar. But they are still different.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
More nonsense. The three lines differ by whitespace only. They consist of the same token sequence and thus are absolutely, 100% identical to the compiler. All three define a variable p of type "pointer to int".int* p;
int * p;
int *p;
The first says that the type is a pointer to integer, but the other two doesn't, and I'm not mistaken, not one of them is entirely right.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
The reason for that is purely style and practice:
if you use "int* blah" then it's easy to think that if you change that to "int *blah, bleh", that both of those are pointers. If the star ties to the variable-name, then it's easier to identify that you need to have a star for bleh too - assuming you want it to be a pointer of course.
As for the compiler, it's even valid to type int*blah - it will compile, but we don't like reading it.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I agree. I told my operating systems tutorial class recently when I gave a presentation that they could ignore the difference between an array and a pointer in understanding my example.This isn't about what an array is, but rather how you think.
I think this is easy enough: instead of insisting that an array is a pointer, insist that people can treat an array as a pointer (to its first element), with some exceptions.
Read Stroustrup's answer to the FAQ: Is ``int* p;'' right or is ``int *p;'' right?Just to clarify that. Some argued that a pointer was not a type, so int* is not a type, and we should therefore type int *t instead of int* t. I was merely surprised to see someone contradict that.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Wrong. The first portion uses the address OF the array, the second uses the address IN the pointer.
The loading of the eax register in the array portion of that code uses immediate addressing mode, the pointer portion uses direct addressing.
...and that's why casts DON'T work.Code:array db "Somestring", 0 pntr dw array func: mov eax, offset array ; immediate xor ecx, ecx 1: mov bl, [eax+ecx] test bl, bl jz $2 inc ecx jmp $1 2: mov eax, dword ptr pntr ; direct 4: mov bl, [eax+edx] test bl, bl jz $3 inc edx jmp $4 3:
Completely wrong, just like your thinking, see above.The array is stored on the stack, this we know, but the array, the name of the variable of the array, is treated like a pointer. That's what my thinking is all about and why I treat array and pointer the same.
Duh! That's the whole point! Access through an array needs one memory fetch, a pointer needs two.You just removed the first step in the process, to get the address of the the memory block first.
Casts do work. You can cast a 2d array to a single pointer and access everything. If it's say, 4x4, then pointer[5] will access array[1][0] and pointer[4] will access array[0][3].
The point was that you removed the first step of using the array by putting the address in a pointer. An array, like everything else, is just a block of contiguous memory, and it must therefore fetch the address to that memory first to be able to work with it.
You just removed that step (or more precisely, already performed it), so it doesn't need to do it again.
Holy crap, are we still in this same argument?
OK, why not describe it like this (I don't know how technically correct it is, but this isn't going anywhere, so what the hell):
A 1D array is like a 1D pointer to a block of memory on the stack.
A 2D+ array is like a 1D pointer to a block of memory on the stack (except accessing a particular set of rows/columns is a pain in the ass using pointer syntax)
Hopefully that should satisfy both sides of this argument.
Amazing . Not only do you misunderstand pointers and arrays, but you can't even do simple pointer arithmetic. I warned you to stop posting your nonsense, now you are exposing yourself worse.
You can cast anything to a pointer to char and access it that way. Not just 2d arrays, but everthing else. Because, every object can be viewed as an array of chars.
The cast for the example that started this thread was to a (char **), which doesn't work. Only someone who thought, as you do, that arrays and pointers are the same would be confused by this. Thinking that arrays are really just pointers will only confuse you more, it doesn't help. This thread is a case in point.
The point, is that it DOESN'T fetch the address to the array. It is already known, unlike dereferencing through a pointer. Your first sentence here is total nonsense. Your last sentence is one source of your confusion.