A pointer to the first element of an array is a pointer to the array itself?

This is a discussion on A pointer to the first element of an array is a pointer to the array itself? within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by psychopath Make sure you're passing glDrawArrays a pointer to the first element of you're vertex array, not ...

  1. #1
    Massively Single Player AverageSoftware's Avatar
    Join Date
    May 2007
    Location
    Buffalo, NY
    Posts
    141
    Quote Originally Posted by psychopath View Post
    Make sure you're passing glDrawArrays a pointer to the first element of you're vertex array, not a pointer to the array itself.


    A pointer to the first element of the array is a pointer to the array itself.

    m_vertex_array and &m_vertex_array[0] are equivalent statements.
    There is no greater sign that a computing technology is worthless than the association of the word "solution" with it.

  2. #2
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by AverageSoftware View Post
    A pointer to the first element of the array is a pointer to the array itself.
    Not true, even if some non-compliant compilers don't know the difference.

    m_vertex_array and &m_vertex_array[0] are equivalent statements.
    Also not true. It depends on the context. m_vertex_array can be implicitly converted to a pointer to the first element, while &m_vertex_array[0] explicitly is a pointer to the first element.
    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

  3. #3
    Massively Single Player AverageSoftware's Avatar
    Join Date
    May 2007
    Location
    Buffalo, NY
    Posts
    141
    Quote Originally Posted by CornedBee View Post
    Not true, even if some non-compliant compilers don't know the difference.


    Also not true. It depends on the context. m_vertex_array can be implicitly converted to a pointer to the first element, while &m_vertex_array[0] explicitly is a pointer to the first element.
    I don't buy it.

    m_vertex_array[0] evaluates to *(m_vertex_array + 0)
    &m_vertex_array[0] is therefore &*(m_vertex_array + 0)
    The &* cancels out, leaving m_vertex_array + 0
    m_vertex_array + 0 = m_vertex_array
    There is no greater sign that a computing technology is worthless than the association of the word "solution" with it.

  4. #4
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Yes, but only in this context. Take, on the other hand, this:

    Code:
    void byref(int (&args)[4])
    {
      std::cout << args[0] + args[1] + args[2] + args[3] << std::endl;
    }
    
    void byptr(int (*args)[4])
    {
      std::cout << (*args)[0] + (*args)[1] + (*args)[2] + (*args)[3] << std::endl;
    }
    
    int main()
    {
      int four[4] = { 1, 2, 3, 4 };
      int three[3] = { 1, 2, 3 };
    
      byref(four);
      byptr(&four);
    
      //byref(three);
      //byptr(&three);
    }
    Try uncommenting the two commented lines - it will fail. Try any other combination of the thing, it will fail. In particular, byref(four+0) will fail, thus proving that the equivalence you claim is not universal.

    On some compilers, all calls to byptr might fail.

    The thing is, array is NOT the same as &array[0]. The exact distinction lies with the differences between r-values and l-values, but the human-readable explanation is that array only decays to a pointer to its first element when needed.
    See also 4.1 and 4.2 of the C++ standard. The first is normal l-value to r-value conversion, but it explicitly excludes arrays. The second says that when an r-value is needed but an array type l-value is provided, the r-value is the address of the first element of the array.
    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

  5. #5
    Massively Single Player AverageSoftware's Avatar
    Join Date
    May 2007
    Location
    Buffalo, NY
    Posts
    141
    The first point I will concede, that an array is a pointer to its first element, I had forgotten about some of the exceptions that you later mentioned.

    However, the statement that array is equivalent to &array[0] stands. If two things are equivalent, it means that they have the same value. I'm not sure what you're taking the word to mean, but it's not what I intended.
    There is no greater sign that a computing technology is worthless than the association of the word "solution" with it.

  6. #6
    Registered Abuser
    Join Date
    Jun 2006
    Location
    Toronto
    Posts
    591
    Quote Originally Posted by AverageSoftware View Post
    A pointer to the first element of the array is a pointer to the array itself.
    If "array" is an array, then *array is its first element, &array[0] is a pointer to its first element and &array is a pointer to the array. Thus he is correct to say that a pointer to the array is not the same as the array itself. Or in other words:
    &array[0] != &array
    "pointer to first element" != "to pointer to array itself"
    pointer to type array[0] != pointer to type pointer to type array[0]

    I think you might have been confusing it with the idiom that "a pointer to the first element of an array is the array itself.", which is subtely different from "a pointer to the first element of the array is a pointer to the array itself", but means something else entirely.

  7. #7
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by AverageSoftware View Post
    THowever, the statement that array is equivalent to &array[0] stands. If two things are equivalent, it means that they have the same value. I'm not sure what you're taking the word to mean, but it's not what I intended.
    I'm taking it to mean the same as you. I'm just disputing your universal claim that array and &array[0] have the same value, because it is simply not true. array can be, if the context requries it, converted to the same value as &array[0] is, but it is not inherently so.
    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

  8. #8
    Massively Single Player AverageSoftware's Avatar
    Join Date
    May 2007
    Location
    Buffalo, NY
    Posts
    141
    Quote Originally Posted by CornedBee View Post
    I'm taking it to mean the same as you. I'm just disputing your universal claim that array and &array[0] have the same value, because it is simply not true. array can be, if the context requries it, converted to the same value as &array[0] is, but it is not inherently so.
    I think you have a different meaning of value then I do.

    The C/C++ standards define array[index] as *((array) + (index)). In the case where index is 0, this has the same value as *array.

    That is to say, if you cout << array << " " << &array[0]; you will get the same value twice.

    I think I've proven this mathematically above, I don't believe there's an exception, barring some crazy overloaded operator magic.

    Just to see, I compiled this silly function down to assembly:
    Code:
    void test()
    {
    	int array[10];
    
    	if (array == &array[0])
    	{
    		array[0] = 1234;
    	}
    	else
    	{
    		array[0] = 5678;
    	}
    }
    And got this:
    Code:
    __Z4testv:
    LFB2:
    	stmw r30,-8(r1)
    LCFI0:
    	stwu r1,-96(r1)
    LCFI1:
    	mr r30,r1
    LCFI2:
    	li r0,1234
    	stw r0,24(r30)
    	lwz r1,0(r1)
    	lmw r30,-8(r1)
    	blr
    GCC optimizes out the conditional, because the condition is provably true. The else branch doesn't even appear in the assembly output.
    Last edited by AverageSoftware; 07-19-2007 at 05:16 AM.
    There is no greater sign that a computing technology is worthless than the association of the word "solution" with it.

  9. #9
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,303
    This thread has been split from glDrawArrays().
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  10. #10
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,762
    Maybe where CornedBee has stated value, he means type; particularly in this context:
    I'm taking it to mean the same as you. I'm just disputing your universal claim that array and &array[0] have the same value, because it is simply not true. array can be, if the context requries it, converted to the same value as &array[0] is, but it is not inherently so.
    Insofar I think the times when CornedBee means a true assignable value, or when he is talking about the arrays not being an l-value is the source of confusion between the two of you. There is no secondary argument beyond where you've already conceded, and maybe I can explain.

    True the C Standard defines what array[index] is supposed to do, and from what I see CornedBee does not dispute this.

    When array is not an l-value, what array contains isn't going to be what changes, so &array[0] == array, or variants aren't going to prove anything new. Its type changes and dictates what you can and cannot do with the object. You just happen to luck out because, as of yet, whenever you try to test this concept, the array will be converted to a pointer, and array in that context becomes an l-value. What array contains will change in that context, and that impacts the logic of your examples.

    That's the key difference, and it has less to do with hemming and hawing about what array "means" because as far as I can tell that's not the issue when it comes to array-type or non l-value variables.

    I know you've conceded to this, but it bears repeating the type difference.
    Code:
    int main( )
    {
      int array[3] = { 4, 5, 7 };
      int *foo = &array[0];
    
      array = foo; // can't assign? can't be equal either
    
      return 0;
    }

  11. #11
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,484
    sizeof array
    sizeof &array[0]

    Are they always the same?
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  12. #12
    Massively Single Player AverageSoftware's Avatar
    Join Date
    May 2007
    Location
    Buffalo, NY
    Posts
    141
    Values come from expressions. Assuming something like int array[10];, array is an expression. &array[0] is also an expression. These two expressions have the same value. I'm talking about numbers here, not types, not sizes, plain old numbers.

    If this were not true, you could provide a counterexample in which array == &array[0] (also an expression) evaluates to false.

    If you can do this, I will concede the point.

    Code:
    if (array == &array[0])
    {
        cout << "The expressions are equal.\";
    }
    else
    {
        cout << "The expressions are not equal.\n";
    }
    Show me an array that prints the second statement.
    There is no greater sign that a computing technology is worthless than the association of the word "solution" with it.

  13. #13
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,762
    It's not a foo == bar problem. If foo == bar you have a compilable example. There are situations where array is not a pointer as CornedBee and I have demonstrated, and what array means will change. The difference is that the situations where array is used as an l-value where it isn't one do not compile; it is impossible to provide an example like the one you requested.

  14. #14
    Massively Single Player AverageSoftware's Avatar
    Join Date
    May 2007
    Location
    Buffalo, NY
    Posts
    141
    Quote Originally Posted by citizen View Post
    It's not a foo == bar problem.
    This is because you are arguing the wrong point. What I am asserting is a foo == bar problem.

    There are situations where array is not a pointer as CornedBee and I have demonstrated, and what array means will change.
    CornedBee's example is a type violation. It has nothing to do with values. If you force the issue with a reinterpret_cast, it works just fine. The last array element will be a garbage value, but that's a different problem.

    The difference is that the situations where array is used as an l-value where it isn't one do not compile
    I'm not contending that. Once again, my assertion is that the expressions array and &array[0] have the same numeric value. Neither of these expressions produce an l-value, nor have I ever claimed that they do.

    it is impossible to provide an example like the one you requested.
    Then I consider my point established.
    There is no greater sign that a computing technology is worthless than the association of the word "solution" with it.

  15. #15
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,762
    Oh, okay.

    I apologize for misunderstanding then. As long as you understand the type difference, then there's no issue. Saying that &array[0] will always be the same as array is wrong, but they will always be the same object. That's ... apparent, actually.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Why does C need pointer conversion
    By password636 in forum C Programming
    Replies: 2
    Last Post: 04-10-2009, 08:33 AM
  2. pointer to first element in array
    By someprogr in forum C Programming
    Replies: 4
    Last Post: 01-10-2009, 02:52 AM
  3. sorting the matrix question..
    By transgalactic2 in forum C Programming
    Replies: 47
    Last Post: 12-22-2008, 03:17 PM
  4. Replies: 7
    Last Post: 11-25-2008, 01:50 AM
  5. Modify an single passed array element
    By swgh in forum C Programming
    Replies: 3
    Last Post: 08-04-2007, 09:58 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21