Arrays are not Pointers, right?

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
*/
--
Gary

re: Arrays are not Pointers, right?

"Gary" <glabowitz@comcast.net> wrote in message
news:Z9SdnSyqpN7M1IfdRVn_iw@comcast.com...[color=blue]
> 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
> */[/color]
Arrays are pointers are not same but inter-related.
arr[i] == *(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

re: Arrays are not Pointers, right?

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

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

--
Attila aka WW

re: Arrays are not Pointers, right?

"Attila Feher" <attila.feher@lmf.ericsson.se> wrote in message
news:bvdhmu$oa3$1@newstree.wise.edt.ericsson.se...[color=blue]
> Gary wrote:[color=green]
> > I've always taught that arrays are not pointers. So how come I can do:[/color]
> [SNIP]
>
> Because in certain expressions the name of the array _decays_ into a[/color]
pointer[color=blue]
> to the first element of the array.[/color]

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

re: Arrays are not Pointers, right?

Gary wrote:
[color=blue]
>
> "Attila Feher" <attila.feher@lmf.ericsson.se> wrote in message
> news:bvdhmu$oa3$1@newstree.wise.edt.ericsson.se...[color=green]
>> Gary wrote:[color=darkred]
>> > I've always taught that arrays are not pointers. So how come I can
>> > do:[/color]
>> [SNIP]
>>
>> Because in certain expressions the name of the array _decays_ into a[/color]
> pointer[color=green]
>> to the first element of the array.[/color]
>
> 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.[/color]

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?

re: Arrays are not Pointers, right?

"Rolf Magnus" <ramagnus@t-online.de> wrote in message
news:bvdkve$trl$05$2@news.t-online.com...[color=blue]
> Gary wrote:
>[color=green]
> >
> > "Attila Feher" <attila.feher@lmf.ericsson.se> wrote in message
> > news:bvdhmu$oa3$1@newstree.wise.edt.ericsson.se...[color=darkred]
> >> 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[/color]
> > pointer[color=darkred]
> >> to the first element of the array.[/color]
> >
> > 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.[/color]
>
> 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?[/color]

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

re: Arrays are not Pointers, right?

Gary wrote:[color=blue]
> "Rolf Magnus" <ramagnus@t-online.de> wrote in message
> news:bvdkve$trl$05$2@news.t-online.com...
>[color=green]
>>Gary wrote:
>>
>>[color=darkred]
>>>"Attila Feher" <attila.feher@lmf.ericsson.se> wrote in message
>>>news:bvdhmu$oa3$1@newstree.wise.edt.ericsson.se ...
>>>
>>>>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.[/color]
>>
>>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?[/color]
>
>
> 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.[/color]

If you want the gory details, search news:comp.lang.c for
"Chris Torek" and "The Rule". He has submitted many posts
explaining the relationship between arrays and pointers.
http://groups.google.com/groups?q=Ch...di.com&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

re: Arrays are not Pointers, right?

"Thomas Matthews" <Thomas_MatthewsSpitsOnSpamBots@sbcglobal.net> wrote in
message news:P6uSb.13691$aA4.4453@newssvr16.news.prodigy.c om...[color=blue]
> Gary wrote:[color=green]
> > "Rolf Magnus" <ramagnus@t-online.de> wrote in message
> > news:bvdkve$trl$05$2@news.t-online.com...
> >[color=darkred]
> >>Gary wrote:
> >>
> >>
> >>>"Attila Feher" <attila.feher@lmf.ericsson.se> wrote in message
> >>>news:bvdhmu$oa3$1@newstree.wise.edt.ericsson.se ...[/color][/color][/color]
<snip>[color=blue]
> If you want the gory details, search news:comp.lang.c for
> "Chris Torek" and "The Rule". He has submitted many posts
> explaining the relationship between arrays and pointers.
>[/color]
http://groups.google.com/groups?q=Ch...di.com&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.)
--
Gary

re: Arrays are not Pointers, right?

> >[color=blue]
>[/color]
http://groups.google.com/groups?q=Ch...di.com&rnum=10[color=blue]
>
> 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.)
> --
> Gary
>[/color]

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

re: Arrays are not Pointers, right?

Gary wrote:[color=blue]
> ...
> I checked this reference, and I believe it is wrong. He says (&a)+1 point
> you past the end of the array.[/color]

Yes, it does.
[color=blue]
> I tried it. It doesn't. It takes you to the
> next element of the array.[/color]

You must've misinterpreted the results. Or your compiler is seriously
broken.
[color=blue]
> (See my original post for the code.)[/color]

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

--
Best regards,
Andrey Tarasevich

re: Arrays are not Pointers, right?

Gary wrote:[color=blue]
> ...
> 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);
> ...[/color]

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.

--
Best regards,
Andrey Tarasevich

re: Arrays are not Pointers, right?

Andrey Tarasevich wrote:[color=blue]
> Gary wrote:
>[color=green]
>>...
>>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);
>>...[/color]
>
>
> I don't understand why would you ever expect the result of a pointer
> operation to be "the second byte" of anything.[/color]

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.

re: Arrays are not Pointers, right?

Gianni Mariani wrote:
[color=blue][color=green]
>> I don't understand why would you ever expect the result of a pointer
>> operation to be "the second byte" of anything.[/color]
>
> 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.[/color]

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.

re: Arrays are not Pointers, right?

Gary wrote:
[color=blue]
> I've always taught that arrays are not pointers. So how come I can do:[/color]
[color=blue]
> #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;
> }[/color]

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

re: Arrays are not Pointers, right?

"Andrey Tarasevich" <andreytarasevich@hotmail.com> wrote in message
news:101l9nv50m0gvab@news.supernews.com...[color=blue]
> Gary wrote:[color=green]
> > ...
> > Since you asked: I was just guessing that the array identifier has a[/color][/color]
size of[color=blue][color=green]
> > the full array (correct guess); that array+1 would be the address of the
> > second byte of the array (wrong guess);
> > ...[/color]
>
> 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.[/color]

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

re: Arrays are not Pointers, right?

Gary wrote:
[SNIP][color=blue]
> 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.[/color]

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!

--
Attila aka WW

re: Arrays are not Pointers, right?

"Attila Feher" <attila.feher@lmf.ericsson.se> wrote in message
news:bvlc0n$7qp$1@newstree.wise.edt.ericsson.se...[color=blue]
> Gary wrote:
> [SNIP][color=green]
> > 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.[/color]
>
> 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![/color]
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,
--
Gary

re: Arrays are not Pointers, right?

Gary wrote:
[SNIP][color=blue]
> 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!)[/color]

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

--
Attila aka WW

re: Arrays are not Pointers, right?

Attila Feher wrote:[color=blue]
>
> Gary wrote:
> [SNIP][color=green]
> > 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!)[/color]
>
> Since I have no idea what sleaze is, I give up. :-)[/color]


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