Thread: pointer and array

  1. #16
    Hurry Slowly vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,788
    Quote Originally Posted by Elysia View Post
    Even if it may sound rude or arrogant, I don't care what the standard says. I believe in assembly and assembly says it's a pointer.
    This silly discussion will get nowhere, so why bother?
    Maybe you should forget about C++ and start programming in asm

    But in any case - stop making statements that are against standard, this forum is no place for such statements, people that come here want to learn right habbits, not some humble-mumble stuff
    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

  2. #17
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #18
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Elysia View Post
    Even if it may sound rude or arrogant, I don't care what the standard says. I believe in assembly and assembly says it's a pointer.
    This silly discussion will get nowhere, so why bother?
    No it doesn't:
    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:
    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.

    The above code is something I just hacked up to do roughly this:
    Code:
    char array[] = "Soemstring";
    char *pntr = array;
    
    void func()
    {
       int c;
       for(c = 0; array[c]; c++) ; 
       for(d = 0; pntr[d]; d++) ; 
    }
    I'm sorry, but you're wrong - although pointers and arrays can be used interchangeably in places, they aren't the same thing.

    --
    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.

  4. #19
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #20
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Elysia View Post
    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.
    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.

  6. #21
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    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.
    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".
    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

  7. #22
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Oh, really? Some on the board does not seem to agree.
    I know there was something about this somewhere, sometime, how type* t was wrong and it should be type *t.
    Of course I don't have a link...
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #23
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Elysia View Post
    Oh, really? Some on the board does not seem to agree.
    I know there was something about this somewhere, sometime, how type* t was wrong and it should be type *t.
    Of course I don't have a link...
    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.

  9. #24
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by Elysia View Post
    Oh, really? Some on the board does not seem to agree.
    I know there was something about this somewhere, sometime, how type* t was wrong and it should be type *t.
    Of course I don't have a link...
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #25
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    This isn't about what an array is, but rather how you think.
    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.

    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.

    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.
    Read Stroustrup's answer to the FAQ: Is ``int* p;'' right or is ``int *p;'' right?
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  11. #26
    Registered User
    Join Date
    Jul 2003
    Posts
    110
    Quote Originally Posted by Elysia View Post
    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.
    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.
    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:
    ...and that's why casts DON'T work.

    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.
    Completely wrong, just like your thinking, see above.

    You just removed the first step in the process, to get the address of the the memory block first.
    Duh! That's the whole point! Access through an array needs one memory fetch, a pointer needs two.

  12. #27
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by whoie View Post
    ...and that's why casts DON'T work.
    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].

    Quote Originally Posted by whoie View Post
    Duh! That's the whole point! Access through an array needs one memory fetch, a pointer needs two.
    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.
    Last edited by Elysia; 02-12-2008 at 11:57 AM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #28
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    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.

  14. #29
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Indeed, at least I can agree that it is at least that much.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #30
    Registered User
    Join Date
    Jul 2003
    Posts
    110
    Quote Originally Posted by Elysia View Post
    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].
    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.

    Quote Originally Posted by Elysia View Post
    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.
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. sorting the matrix question..
    By transgalactic2 in forum C Programming
    Replies: 47
    Last Post: 12-22-2008, 03:17 PM
  2. Replies: 2
    Last Post: 07-11-2008, 07:39 AM
  3. pointers
    By InvariantLoop in forum C Programming
    Replies: 13
    Last Post: 02-04-2005, 09:32 AM
  4. Quick question about SIGSEGV
    By Cikotic in forum C Programming
    Replies: 30
    Last Post: 07-01-2004, 07:48 PM
  5. Struct *** initialization
    By Saravanan in forum C Programming
    Replies: 20
    Last Post: 10-09-2003, 12:04 PM