Arrays are not Pointers, right?

[Gary]

I've always taught that arrays are not pointers. So how come I can do:
#include <iostream>
#include <cstdlib>

using namespace std;

int main( )
{
int myArray[10]={1, 10};
cout << sizeof(myArray) << endl;
cout << sizeof(myArray+1) << endl;
cout << *myArray << endl;
cout << *(myArray+1) << endl;

system("Pause");
return 0;
}
/*results are
40
4
1
10
*/

 

[Attila Feher]

I've always taught that arrays are not pointers. So how come I can do:

[SNIP]

Because in certain expressions the name of the array _decays_ into a pointer
to the first element of the array.

 

[Sharad Kala]

I've always taught that arrays are not pointers. So how come I can do:
#include <iostream>
#include <cstdlib>

using namespace std;

int main( )
{
int myArray[10]={1, 10};
cout << sizeof(myArray) << endl;
cout << sizeof(myArray+1) << endl;
cout << *myArray << endl;
cout << *(myArray+1) << endl;

system("Pause");
return 0;
}
/*results are
40
4
1
10
*/

Arrays are pointers are not same but inter-related.
arr == *(arr+i)
arr is the address of the starting element of the array.
arr+1 is the address of the 2nd element of the array.
*arr is the value of the 1st element
*(arr+1) is the 2nd element of the array.
Simple

-Sharad

 

[Gary]

I've always taught that arrays are not pointers. So how come I can do:

[SNIP]

Because in certain expressions the name of the array _decays_ into a pointer
to the first element of the array.

Yeah, but I was surprised that I could do pointer arithmetic on the beast.
sizeof(array+1) came back okay. I would have thought it would be the address
of the second byte of the entire array. Oh, well.

 

[Rolf Magnus]

I've always taught that arrays are not pointers. So how come I can
do:

[SNIP]

Because in certain expressions the name of the array _decays_ into a pointer
to the first element of the array.

Yeah, but I was surprised that I could do pointer arithmetic on the
beast. sizeof(array+1) came back okay. I would have thought it would
be the address of the second byte of the entire array. Oh, well.

array+1 not the address of the second byte, but rather of the second
element. sizeof(array+1) returns the size of a pointer to int for an
array of int. What would you expect an address to be stored in?

 

[Gary]

Gary wrote:
I've always taught that arrays are not pointers. So how come I can
do:
[SNIP]

Because in certain expressions the name of the array _decays_ into a pointer
to the first element of the array.

Yeah, but I was surprised that I could do pointer arithmetic on the
beast. sizeof(array+1) came back okay. I would have thought it would
be the address of the second byte of the entire array. Oh, well.

array+1 not the address of the second byte, but rather of the second
element. sizeof(array+1) returns the size of a pointer to int for an
array of int. What would you expect an address to be stored in?

Since you asked: I was just guessing that the array identifier has a size of
the full array (correct guess); that array+1 would be the address of the
second byte of the array (wrong guess); that sizeof array+1 would be
undefined (wrong guess). At least I checked. But I was surprised, that's
all.

 

[Thomas Matthews]

Gary wrote:

Gary wrote:

I've always taught that arrays are not pointers. So how come I can
do:

[SNIP]

Because in certain expressions the name of the array _decays_ into a

pointer

to the first element of the array.

Yeah, but I was surprised that I could do pointer arithmetic on the
beast. sizeof(array+1) came back okay. I would have thought it would
be the address of the second byte of the entire array. Oh, well.

array+1 not the address of the second byte, but rather of the second
element. sizeof(array+1) returns the size of a pointer to int for an
array of int. What would you expect an address to be stored in?

Since you asked: I was just guessing that the array identifier has a size of
the full array (correct guess); that array+1 would be the address of the
second byte of the array (wrong guess); that sizeof array+1 would be
undefined (wrong guess). At least I checked. But I was surprised, that's
all.

If you want the gory details, search for
"Chris Torek" and "The Rule". He has submitted many posts
explaining the relationship between arrays and pointers.
http://groups.google.com/groups?q=C...ng.c.*&[email protected]&rnum=10
{The above URL should be on one line with no spaces}

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[Gary]

If you want the gory details, search for
"Chris Torek" and "The Rule". He has submitted many posts
explaining the relationship between arrays and pointers.

http://groups.google.com/groups?q=C...ng.c.*&[email protected]&rnum=10

I checked this reference, and I believe it is wrong. He says (&a)+1 point
you past the end of the array. I tried it. It doesn't. It takes you to the
next element of the array. (See my original post for the code.)

 

[John Harrison]

http://groups.google.com/groups?q=C...ng.c.*&[email protected]&rnum=10

I checked this reference, and I believe it is wrong. He says (&a)+1 point
you past the end of the array. I tried it. It doesn't. It takes you to the
next element of the array. (See my original post for the code.)

He's right, if your compiler gets this wrong it is broken.

a decays to a pointer to the first element but
&a is a pointer to the _whole_ array so (&a) + 1 must point past the end of
the whole array.

John

 

[Andrey Tarasevich]

...
I checked this reference, and I believe it is wrong. He says (&a)+1 point
you past the end of the array.

Yes, it does.

I tried it. It doesn't. It takes you to the
next element of the array.

You must've misinterpreted the results. Or your compiler is seriously
broken.

(See my original post for the code.)

In terms of your original post it should be '&myArray + 1'. I don't see
anything similar there.

 

[Andrey Tarasevich]

...
Since you asked: I was just guessing that the array identifier has a size of
the full array (correct guess); that array+1 would be the address of the
second byte of the array (wrong guess);
...

I don't understand why would you ever expect the result of a pointer
operation to be "the second byte" of anything. Units of pointer
arithmetic are complete objects, not "bytes". The closest you can get to
"byte pointer arithmetic" is using a 'char*' pointer. But you don't have
any 'char*'s in your code.

 

[Gianni Mariani]

I don't understand why would you ever expect the result of a pointer
operation to be "the second byte" of anything.

Well, I can. When I wrote my first C code (using BDS C) I was coming
off assembler code and my natural thought was that a pointer offset was
allways in bytes - it wasn't until I could not figure out why the
compiler was doing what it was and I cracked open my K&R that I read all
about pointer arithmetic and it finally made sense.

It's also one of my standard interview questions.

If p is a pointer to objects of type T, what does the expression (p+1)
evaluate to.

After having asked that question for many years, I still get the "one
byte after" answer on occaision.

 

[Rolf Magnus]

Well, I can. When I wrote my first C code (using BDS C) I was coming
off assembler code and my natural thought was that a pointer offset
was allways in bytes - it wasn't until I could not figure out why the
compiler was doing what it was and I cracked open my K&R that I read
all about pointer arithmetic and it finally made sense.

Heh, similar for me. It really took me a while to grasp the whole idea
of pointer types and get a clue of why that's a good concept. After
all, when you're in assembler, a pointer is just a variable that holds
a memory address, and it's me who decides what will be at that address.

 

[E. Robert Tisdale]

I've always taught that arrays are not pointers. So how come I can do:

#include <iostream>
#include <cstdlib>

using namespace std;

int main( ) {
int myArray[10]={1, 10};
cout << sizeof(myArray) << endl;
cout << sizeof(myArray+1) << endl;
cout << *myArray << endl;
cout << *(myArray+1) << endl;
return 0;
}

myArray is the *name* of the array.
The size of myArray is 40 bytes.
There is an *implicit* conversion of the name myArray
into a pointer to the first element of myArray
in the expressions 'myArray+1', '*myArray' and *(myArray+1)'.
The size of a pointer is 4 bytes on your machine.
*myArray is a reference to myArray[0] and
*(myArray+1) is a reference to myArray[1].

 

[Gary]

I don't understand why would you ever expect the result of a pointer
operation to be "the second byte" of anything. Units of pointer
arithmetic are complete objects, not "bytes". The closest you can get to
"byte pointer arithmetic" is using a 'char*' pointer. But you don't have
any 'char*'s in your code.

Thank you Andrey. What really amazes me is the quickness with which you guys
respond. I saw my error in my testing rather quickly after posting and
recalled that post. In the five minutes it was "in the wild" I got 5
answers! Maybe cancel isn't working on your feed.
Your posts, Andrey, strike me as the most understandable, with the added
grace that they don't attack or downplay the intelligence of the OP.
BTW, I wasn't attempting to troll, it just happened accidentally.
I guess it just drives me crazy when I see "Use of an array decays to a
pointer to the first element IN MOST CASES." Never an explanation of what
cases it doesn't, just the hint. Then my imagination runs wild.

 

[Attila Feher]

Gary wrote:
[SNIP]

I guess it just drives me crazy when I see "Use of an array decays to
a pointer to the first element IN MOST CASES." Never an explanation
of what cases it doesn't, just the hint. Then my imagination runs
wild.

Since you address me. When such comment is written, it is written to get
you into the right direction. If you need more information, you ask. And
you did. Others were faster than me and jumped in and answered you, so I
was not needed anymore.

As for my post, please point out the text where I have accused you of
trolling. If you cannot, please do not accuse me of doing that!

 

[Gary]

Gary wrote:
[SNIP]

I guess it just drives me crazy when I see "Use of an array decays to
a pointer to the first element IN MOST CASES." Never an explanation
of what cases it doesn't, just the hint. Then my imagination runs
wild.

As for my post, please point out the text where I have accused you of
trolling. If you cannot, please do not accuse me of doing that!

I was not accusing anyone of accusing me of trolling. Does that compute?
It occurred to me that someone might think I was just trolling, which I
didn't mean to do, and so I add that comment in case one of the others got
that idea.
Anyway, it is not you for sure. You have always been a real gentleman,
except when dealing with sleaze. (...and then we'll get 'em!)
Thanks,

 

[Attila Feher]

Gary wrote:
[SNIP]

Anyway, it is not you for sure. You have always been a real gentleman,
except when dealing with sleaze. (...and then we'll get 'em!)

Since I have no idea what sleaze is, I give up.

 

[Default User]

Gary wrote:
[SNIP]

Anyway, it is not you for sure. You have always been a real gentleman,
except when dealing with sleaze. (...and then we'll get 'em!)

Since I have no idea what sleaze is, I give up.

It's backformed from "sleazy".


One entry found for sleazy.
Main Entry: slea·zy
Pronunciation: 'slE-zE also 'slA-
Function: adjective
Inflected Form(s): slea·zi·er; -est
Etymology: origin unknown
1 a : lacking firmness of texture : FLIMSY b : carelessly made of
inferior materials : SHODDY
2 a : marked by low character or quality <sleazy tabloids> b : SQUALID,
DILAPIDATED <sleazy bars>



I believe sense 2a is the indicated one.



Brian Rodenborn