[ad_1]
\n<\/p>\n
Arrays vs. pointers<\/strong> is probably one of the harder topics of C (and C++ which inherited that from C). It’s actually easy once you understood the concept behind but that concept might be unexpected by starters \u2013 I never saw anything similar in other programming languages.<\/p>\n Borgleader told in his comment: The trueth is:<\/p>\n Hence, the definition of OP has type mismatch errors:<\/p>\n The elements of This is exactly what clang tells in the Live Demo of Bob__ on Wandbox<\/strong><\/a>:<\/p>\n Bob__ used C with I changed it to C++ with Actually, I was confused by a comment on Quora which had this example.<\/p>\n<\/blockquote>\n Considering that C has ever been quite tolerant concerning non-matching types, the example might have worked. To illustrate this, I made a slightly extended example on godbolt.org:<\/p>\n For for for Live Demo on godbolt<\/strong><\/a><\/kbd><\/p>\n Without going into too much depth, nearly the same code has been produced for all three lines. (The only differences are the addresses after It’s not that surprising that By definition, the subscript operator but even the initialization with pointers of wrong types didn’t make a difference.<\/p>\n IMHO, this is good for two lessons:<\/p>\n Using correct types by introducing the necessary dereference operators prevents warnings (in C), errors (in C++).<\/p>\n<\/li>\n Optimizing away dereference operators (at the cost of warnings) doesn’t improve the generated binary code.<\/p>\n<\/li>\n<\/ol>\n In another comment, the OP stated that<\/p>\n To my understanding “a” is a pointer to the whole array…<\/p>\n<\/blockquote>\n That’s wrong. That’s a difference, and it’s easy to illustrate by an example:<\/p>\n Output:<\/p>\n Live Demo on ideone<\/strong><\/a><\/kbd><\/p>\n The confusion about arrays and pointers comes probably from the fact that arrays decay in most cases to pointers. Even the subscript operator ( As arrays may not be used as arguments, there is no such difference anymore in function int a[3][3]<\/code> decays to int*<\/code><\/s> but that’s false! (If it were true the issue of OP wouldn’t exist.)<\/p>\n\n
a<\/code> is of type int [3][3]<\/code>.<\/li>\na<\/code> may decay to int (*)[3]<\/code> (a pointer to array 3 of int<\/a>)<\/li>\n<\/ol>\nint *p[3] = {a+0, a+1, a+2};\n<\/code><\/pre>\np<\/code> have type int*<\/code> but a+0<\/code> (as well as a+1<\/code>, a+2<\/code>) provide an expression of int (*)[3]<\/code>.<\/p>\nprog.c:7:18: warning: incompatible pointer types initializing 'int *' with an expression of type 'int (*)[3]' [-Wincompatible-pointer-types]\n int *p[3] = {a+0, a+1, a+2};\n ^~~\n<\/code><\/pre>\n-std=c11<\/code> and -pedantic<\/code>.<\/p>\n-std=c++17<\/code> and no -pedantic<\/code>. C++ reports this as error because it’s by default much stricter concerning type compatibility.<\/p>\n
\n\n
#include <stdio.h>\n\nint main()\n{\n int a[3][3] = {{10,20,30},{40,50,60},{70,80,90}};\n int *p[3] = { a + 0, a + 1, a + 2 };\n int *p1[3] = { *(a + 0), *(a + 1), *(a + 2) };\n int *p2[3] = { a[0], a[1], a[2] };\n return 0;\n}\n<\/code><\/pre>\nint *p[3] = { a + 0, a + 1, a + 2 };<\/code> it compiled:<\/p>\n mov rcx, qword ptr [rbp - 168] # load rcx with address of a\n mov qword ptr [rbp - 80], rcx # store rcx to p[0] \n mov rcx, qword ptr [rbp - 168] # load rcx with address of a\n add rcx, 12 # add 12 to rcx (1 * 3 * sizeof (int))\n mov qword ptr [rbp - 72], rcx # store rcx to p[1]\n mov rcx, qword ptr [rbp - 168] # load rcx with address of a\n add rcx, 24 # add 24 to rcx (2 * 3 * sizeof (int))\n mov qword ptr [rbp - 64], rcx # store rcx to p[2]\n<\/code><\/pre>\nint *p1[3] = { *(a + 0), *(a + 1), *(a + 2) };<\/code>:<\/p>\n mov rcx, qword ptr [rbp - 168] # load rcx with address of a\n mov qword ptr [rbp - 112], rcx # store rcx to p1[0] \n add rcx, 12 # add 12 to rcx (1 * 3 * sizeof (int))\n mov qword ptr [rbp - 104], rcx # store rcx to p1[1] \n mov rcx, qword ptr [rbp - 168] # load rcx with address of a\n add rcx, 24 # add 24 to rcx (2 * 3 * sizeof (int))\n mov qword ptr [rbp - 96], rcx # store rcx to p1[2]\n<\/code><\/pre>\nint *p2[3] = { a[0], a[1], a[2] };<\/code>:<\/p>\n mov rcx, qword ptr [rbp - 168] # load rcx with address of a\n mov qword ptr [rbp - 144], rcx # store rcx to p2[0] \n add rcx, 12 # add 12 to rcx (1 * 3 * sizeof (int))\n mov qword ptr [rbp - 136], rcx # store rcx to p2[1] \n mov rcx, qword ptr [rbp - 168] # load rcx with address of a\n add rcx, 24 # add 24 to rcx (2 * 3 * sizeof (int))\n mov qword ptr [rbp - 128], rcx # store rcx to p2[2]\n<\/code><\/pre>\nmov qword ptr [rbp -<\/code>… as the initializations are stored into variables which have different addresses on stack, of course.)<\/p>\n*(a + 0)<\/code> and a[0]<\/code> result in equivalent code because according to cppreference: Subscript<\/a>:<\/p>\n\n
E1[E2]<\/code> is exactly identical to *((E1)+(E2))<\/code>.<\/p>\n<\/blockquote>\n\n
\n\n
a<\/code> is an array. It may decay to a pointer if required.<\/p>\n#include <stdio.h>\n\nvoid printSizes(int a[3][3], int (*p)[3])\n{\n puts(\"when a and p passed to a function:\");\n printf(\"sizeof a: %u\\n\", (unsigned)sizeof a);\n printf(\"sizeof p: %u\\n\", (unsigned)sizeof p);\n}\n\nint main()\n{\n int a[3][3] = {{10,20,30},{40,50,60},{70,80,90}};\n int (*p)[3] = { a + 0, a + 1, a + 2 };\n printf(\"sizeof a: %u\\n\", (unsigned)sizeof a);\n printf(\"sizeof p: %u\\n\", (unsigned)sizeof p);\n return 0;\n}\n<\/code><\/pre>\nsizeof a: 36\nsizeof p: 8\nwhen a and p passed to a function:\nsizeof a: 8\nsizeof p: 8\n<\/code><\/pre>\noperator[]<\/code><\/a>) is defined for pointers but not for arrays. The sizeof<\/code> operator is one of the few exceptions and shows the difference.<\/p>\nprintSize()<\/code>. Even with giving the array type the compiler uses the pointer type resulting from array decay.<\/p>\n<\/p><\/div>\n