Well defined meaning of pointer to an array

[Paul]

A char* can point to a single char or an array of chars.

char* p= new char[64];
The above is a pointer points to an array of 64 chars.

I have no more to say on this subject especially to idiots who do not
understand the difference between:
a) pointer to array objects
b) pointer to array data type

 

[Juha Nieminen]

I have no more to say on this subject

Haha. You are quite the joker, aren't you?

Let's count how long it takes before you make another post on this very
same subject. Bet starts at 1 day.

 

[Paul]

A char* can point to a single char or an array of chars.

char* p= new char[64];
The above is a pointer points to an array of 64 chars.

I have no more to say on this subject especially to idiots who do not
understand the difference between:
a) pointer to array objects

should be pointer to an array OF objects.

 

[Johannes Schaub]

A char* can point to a single char or an array of chars.

char* p= new char[64];
The above is a pointer points to an array of 64 chars.

Does it?

"If an object of type T is located at an address A, a pointer of type cv T*
whose value is the address A is said to *point to* that object, regardless
of how the value was obtained."

Your use of "points to" is not covered by the text, I think. You can say
that "p" stores or represents the address of an array of 64 chars, though.

 

[Paul]

A char* can point to a single char or an array of chars.

char* p= new char[64];
The above is a pointer points to an array of 64 chars.

Firstly please excuse my typos as I just battered this out on the keyboard
and chaged it from "above is a pointer to" to "above pointer points to".
To avoid the repetative bullshit that "is a pointer to " does not mean the
same as "points to".

Does it?

"If an object of type T is located at an address A, a pointer of type cv
T*
whose value is the address A is said to *point to* that object, regardless
of how the value was obtained."

Your use of "points to" is not covered by the text, I think.

So why mention that text if it doesn't cover it?

You can say
that "p" stores or represents the address of an array of 64 chars, though.

I can say that p points to an array of chars.

 

[Juha Nieminen]

I can say that p points to an array of chars.

Betting ends. It took you a bit less than 4 hours to say something
about the subject you didn't have anything else to say.

 

[Paul]

Paul wrote:

A char* can point to a single char or an array of chars.

char* p= new char[64];
The above is a pointer points to an array of 64 chars.

Firstly please excuse my typos as I just battered this out on the keyboard
and chaged it from "above is a pointer to" to "above pointer points to".
To avoid the repetative bullshit that "is a pointer to " does not mean the
same as "points to".

Does it?

"If an object of type T is located at an address A, a pointer of type cv
T*
whose value is the address A is said to *point to* that object,
regardless
of how the value was obtained."

Your use of "points to" is not covered by the text, I think.

So why mention that text if it doesn't cover it?

You can say
that "p" stores or represents the address of an array of 64 chars,
though.

I can say that p points to an array of chars.

You could say that Elvis lives too. Which would equally be technically
incorrect, but to the die hard Elvis fans, they would gladly qualify their
meaning that "Elvis lives on in their hearts".

The point is that just because you can say something, does not make it
technically precise or even technically correct in a technical C++
discussion
that has a topic regarding well-defined.

Its not just me that is saying this , Bjarne Stroustrup says this too , and
its in the C FAQ's.

 

[Paul]

Betting ends. It took you a bit less than 4 hours to say something
about the subject you didn't have anything else to say.

I wouldn't have bothered if I hadn't made a few typos , but now I have to
clarify the technical correctness of the underlying argument.

 

[Paul]

A char* can point to a single char or an array of chars.

Yes if being technically inaccurate and equating pointing to an array
element with pointing to an array.

char* p= new char[64];
The above is a pointer points to an array of 64 chars.

That makes no sense.

I have no more to say on this subject especially to idiots who do not
understand the difference between:
a) pointer to array objects

That makes no sense.

b) pointer to array data type

Who cares about terms *you* define?

Typical trollish behaviour, pounce on the typos and ignore the underlying
technical argument.

 

[Paul]

On 18/04/2011 10:13, Paul wrote:
A char* can point to a single char or an array of chars.

Yes if being technically inaccurate and equating pointing to an array
element with pointing to an array.


char* p= new char[64];
The above is a pointer points to an array of 64 chars.

That makes no sense.


I have no more to say on this subject especially to idiots who do not
understand the difference between:
a) pointer to array objects

That makes no sense.

b) pointer to array data type

Who cares about terms *you* define?

Typical trollish behaviour, pounce on the typos and ignore the
underlying technical argument.

Based on your past behaviour you deserve little respect. My replies are
technically accurate even if troll-like; trolling a troll is perfectly
acceptable behaviour if the trolling is also a valid correction (which
they are).

You are a http://redwing.hutman.net/~mreed/warriorshtm/ferouscranus.htm

 

[Jens Thoms Toerring]

A char* can point to a single char or an array of chars.
No.

char* p= new char[64];
The above is a pointer points to an array of 64 chars.

No, that's a pointer to a single char, the one at the
very start of the array. If you want a pointer to an
array of 64 chars you need

char (*p64)[64];

It's really simple: If you increment a pointer by 1 it
always points to the address directly behind the object
it pointed to (its value is increased by the size of the
type of object it points to). And if you incrememt 'p'
by 1 it points to the next char in the array, so it's a
pointer to a single char, not an array of so many chars.
That it points to the first element of the array doesn't
change anything about that. But if you increment 'p64' by
1 it points directly past the end of the array, so that's
a pointer to an array of 64 chars.

Perhaps you should read Chris Torek's nice article about
pointers and arrays

http://web.torek.net/torek/c/pa.html

and also

http://web.torek.net/torek/c/expr.html#therule

(which might address the reasons behind your confusion).
While it's about C C++ works the same way.

 

[Paul]

No.

Ah so this is wrong?

<quote ref=http://c-faq.com/aryptr/aryptr2.html>
"The pointer declaration char *p, on the other hand, requests a place which
holds a pointer, to be known by the name ``p''. This pointer can point
almost anywhere: to any char, or to any contiguous array of chars, or
nowhere"

char* p= new char[64];
The above is a pointer points to an array of 64 chars.

No, that's a pointer to a single char, the one at the
very start of the array. If you want a pointer to an
array of 64 chars you need

char (*p64)[64];

Ok so this is also wrong?
<quote ref=http://www2.research.att.com/~bs/glossary.html>
"char* - pointer to a char or an array of char."
</quote>

It's really simple: If you increment a pointer by 1 it
always points to the address directly behind the object
it pointed to (its value is increased by the size of the
type of object it points to). And if you incrememt 'p'
by 1 it points to the next char in the array, so it's a
pointer to a single char, not an array of so many chars.
That it points to the first element of the array doesn't
change anything about that. But if you increment 'p64' by
1 it points directly past the end of the array, so that's
a pointer to an array of 64 chars.

Perhaps you should read Chris Torek's nice article about
pointers and arrays

http://web.torek.net/torek/c/pa.html

and also

http://web.torek.net/torek/c/expr.html#therule

(which might address the reasons behind your confusion).
While it's about C C++ works the same way.

Thanks for your post but I think you should read the quotes I posted above
from Bjarbne Stroustrup and Steve Summit.

 

[Noah Roberts]

Betting ends. It took you a bit less than 4 hours to say something
about the subject you didn't have anything else to say.

Technically speaking, its not a contradiction. He DOESN'T have anything
ELSE to say. He's actually just repeating the same things he's already
said many, many, many times already.

Sooner or later I'm sure the deceased Equidae will reanimate and
motivate down the highway if he (and the rest for that matter) just
keeps hitting it with the same set of sticks.

 

[Jens Thoms Toerring]

Ah so this is wrong?

<quote ref=http://c-faq.com/aryptr/aryptr2.html>
"The pointer declaration char *p, on the other hand, requests a place which
holds a pointer, to be known by the name ``p''. This pointer can point
almost anywhere: to any char, or to any contiguous array of chars, or
nowhere"
</quote>

Sloppy speaking. What's really meant is "to the first element
of any continuous array" (and then we could also ask "what's
a non-continous array?"). Since a char and an array of chars
are completely different types a pointer to char can only
point to a char, not also at the same time to the different
type of array of chars - only to an element of the array. But
there are so many cases were an array (when used in value
context) gets converted to a pointer to its first element
that it has become common lingo to call that also "a poin-
ter to the array" when it actually just is a pointer to the
first element. Perhaps unfortunate, but that's life. And when
you go to the next point in the C FAQ (6.3 instead of 6.2)

http://c-faq.com/aryptr/aryptrequiv.html

you will find that it then goes into greater detail, explicitly
speaking about the "first element of an array":

| A reference to an object of type array-of-T which appears
| in an expression decays (with three exceptions) into a pointer
| to its first element; the type of the resultant pointer is
| pointer-to-T.

The word "decays" seems to be at the heart of many misunder-
standings: this is a conversion the compiler does under cer-
tain circumstances but does not imply equality.

char* p= new char[64];
The above is a pointer points to an array of 64 chars.

No, that's a pointer to a single char, the one at the
very start of the array. If you want a pointer to an
array of 64 chars you need

char (*p64)[64];

Ok so this is also wrong?
<quote ref=http://www2.research.att.com/~bs/glossary.html>
"char* - pointer to a char or an array of char."
</quote>

Again lingo, not wrong when meant in the right way, just a
bit sloppily expressed. It might have been better if he had
said "...or the first element of an array", but then this is
a glossary, not an in-depth explanation.

Thanks for your post but I think you should read the quotes I posted above
from Bjarbne Stroustrup and Steve Summit.

I did but I don't think they really support your point of view.

 

[Paul]

Sloppy speaking. What's really meant is "to the first element
of any continuous array" (and then we could also ask "what's
a non-continous array?").

How do you know he means pointing to the first element of an array?
The pointer can point to any element or even to the end of the array.

And what is a non-continuous array then? I think C++ arrays are guaranteed
to be contiguous.

Since a char and an array of chars
are completely different types a pointer to char can only
point to a char, not also at the same time to the different
type of array of chars - only to an element of the array.

A char within an array is the same type as a single char.
What type of object do you think an array of chars contains, if not a char
type?

But
there are so many cases were an array (when used in value
context) gets converted to a pointer to its first element
that it has become common lingo to call that also "a poin-
ter to the array" when it actually just is a pointer to the
first element.

It's not just a pointer to the first element. It's a pointer that can be
offset to index the array.

Perhaps unfortunate, but that's life. And when
you go to the next point in the C FAQ (6.3 instead of 6.2)

http://c-faq.com/aryptr/aryptrequiv.html

you will find that it then goes into greater detail, explicitly
speaking about the "first element of an array":

Yes and there is nothing wrong with being specific about what element a
pointer points to. But there is something wrong if you treat the pointer as
if it ONLY points to that element, and is not also a pointer to the array.

| A reference to an object of type array-of-T which appears
| in an expression decays (with three exceptions) into a pointer
| to its first element; the type of the resultant pointer is
| pointer-to-T.

The word "decays" seems to be at the heart of many misunder-
standings: this is a conversion the compiler does under cer-
tain circumstances but does not imply equality.

The term decays is used , becasue an array has typeinfo which is lost when
its converted to a pointer.

char* p= new char[64];
The above is a pointer points to an array of 64 chars.

No, that's a pointer to a single char, the one at the
very start of the array. If you want a pointer to an
array of 64 chars you need

char (*p64)[64];

Ok so this is also wrong?
<quote ref=http://www2.research.att.com/~bs/glossary.html>
"char* - pointer to a char or an array of char."
</quote>

Again lingo, not wrong when meant in the right way, just a
bit sloppily expressed. It might have been better if he had
said "...or the first element of an array", but then this is
a glossary, not an in-depth explanation.

Again why would he say pointer the nth element, when the pointer can point
to any element?

I did but I don't think they really support your point of view.

\They clearly state exactly my POV.
That a char* can point to a single char or an array of chars.

 

[Jens Thoms Toerring]

How do you know he means pointing to the first element of an array?
The pointer can point to any element or even to the end of the array.

And what is a non-continuous array then? I think C++ arrays are guaranteed
to be contiguous.

I don't know, I just meant that as an example that there are
also other places were the formulation leaves a bit to be
wished for. But then a FAQ should be readable and, as every
explanation, somethimes small white lies are useful to avoid
getting the reader confused with too many concepts at once.
You only have to make it clear further on that this was not
the complete picture...

A char within an array is the same type as a single char.
What type of object do you think an array of chars contains, if not a char
type?

I never made any claims otherwise. The important difference
is that a pointer to a char points always to a single char
while a pointer to an array points to a continuous collec-
tion of chars, involving e.g. information about the number
of elements. You can obtain that information from a pointer
to an array of chars, but not from a mere pointer to one
of it's elements, be it the first or any other.

It's not just a pointer to the first element. It's a pointer that can be
offset to index the array.

Yes, as well as you can add some value to it. So what?
But you can't make it jump just to the end of the array
unless you have external information about how long the
array is. With a pointer to an array you can't access the
individual elements directly but you can junp to the end
of it (or the next array, if you have an array of arrays).

Yes and there is nothing wrong with being specific about what element a
pointer points to. But there is something wrong if you treat the pointer as
if it ONLY points to that element, and is not also a pointer to the array.

Again, an array is a completely different beast from an
element of it. These are two different types. And a pointer
can only have a single type, the type it was created with.
So a pointer to char is not a pointer to an array of chars,
it remains a pointer to char whereever you make it point to.
Just because you store the address of the first element of
an array in it, which has the same address as the array it-
self, does not make it a pointer to the array.

A pointer does not only have a value but also has a type.
That two pointer of different types have the same value does
not make them equal.

Perhaps you have spent a long time doing assembler program-
ming. There, if two addresses are the same that's all you
care about. But when you go to a languages with a type
system things are different. It isn't just about memory
addresses anymore. Suddenly, two addresses being the same
isn't all there is since pointers with different types also
have different properties, like different behaviour when
being incremented. They add a new meaning that can't be
expressed in terms of just their values. A lot of things
become simpler but at the cost of having to think in two
and not just one "dimension" - value and type instead of
just value.

The term decays is used , becasue an array has typeinfo which is lost when
its converted to a pointer.

Yes, and because that loss of information would not happen
when you go from an array-of-T to an pointer-to-array-of-T.
The type array-to-T e.g. "knows" abouth the number of ele-
ments, as does the type pointer-to-array-of-T, while the
type pointer-to-T has no notion at all of something like
"numbers of elements" - there are no elements, just a
pointer to a single instance of T.

char* p= new char[64];
The above is a pointer points to an array of 64 chars.

No, that's a pointer to a single char, the one at the
very start of the array. If you want a pointer to an
array of 64 chars you need

char (*p64)[64];

Ok so this is also wrong?
<quote ref=http://www2.research.att.com/~bs/glossary.html>
"char* - pointer to a char or an array of char."
</quote>

Again lingo, not wrong when meant in the right way, just a
bit sloppily expressed. It might have been better if he had
said "...or the first element of an array", but then this is
a glossary, not an in-depth explanation.

Again why would he say pointer the nth element, when the pointer can point
to any element?

I did but I don't think they really support your point of view.

\They clearly state exactly my POV.
That a char* can point to a single char or an array of chars.

Why then does incrementing pointers of different types re-
sult in different values? You seem to be avoiding that point.
Or you're using your private definition of "pointer", probably
one that turns a blind eye to pointers having a type beside a
value. That's nothing I'm going to have sleepness nights about,
but it makes discussions a bit difficult and, if you insist on
your definition, futile in the longer (or even shorter) run.

 

[Paul]

I don't know, I just meant that as an example that there are
also other places were the formulation leaves a bit to be
wished for. But then a FAQ should be readable and, as every
explanation, somethimes small white lies are useful to avoid
getting the reader confused with too many concepts at once.
You only have to make it clear further on that this was not
the complete picture...



I never made any claims otherwise. The important difference
is that a pointer to a char points always to a single char

This is not true. A pointer is a varaible with a memory address for a value.
The object stored at the memory location is not defined by the pointer-type,
for example:
int x =0;
char* p = 0;
p= (char*)&x;
p[2] =1;

The pointer-type is char* , but its initialised to point to nothing, then it
is assgined the address of an int. At no time does this pointer point to an
object of type char.

while a pointer to an array points to a continuous collec-
tion of chars, involving e.g. information about the number
of elements. You can obtain that information from a pointer
to an array of chars, but not from a mere pointer to one
of it's elements, be it the first or any other.

This is a pointer to an array type.
You need to acknowledge that an array-type is not the same as an array
entity.
When we say a char* can point to an array we are speaking about an array
entity.
When an array is converted to a pointer, the pointer-type is a pointer to a
(n-1) dimensional array.

You can't say a statement such as "a char* can point to an array of chars"
is sloppy because you have interpreted it incorrectly. You are confusing the
obvious(IMO) context of an array entity, with array-type.

Yes, as well as you can add some value to it. So what?
But you can't make it jump just to the end of the array
unless you have external information about how long the
array is. With a pointer to an array you can't access the
individual elements directly but you can junp to the end
of it (or the next array, if you have an array of arrays).

If you cannot access the array , then its not a pointer to the array.
A pointer to an array , when dereferenced must access the array.

What you describe is an indirect pointer to an array, you must dereference
it twice to access the array.

Again, an array is a completely different beast from an
element of it. These are two different types.

An array of chars is not a type, its an entity.

And a pointer
can only have a single type, the type it was created with.
So a pointer to char is not a pointer to an array of chars,
it remains a pointer to char whereever you make it point to.
Just because you store the address of the first element of
an array in it, which has the same address as the array it-
self, does not make it a pointer to the array.

A pointer of type char* can point to an array of chars, when dereferenced it
returns one element of the array.
You cannot get any pointer type that addresses a whole array simultaneously,
unless the array is sized one or something silly like that.

A pointer does not only have a value but also has a type.
That two pointer of different types have the same value does
not make them equal.

This depends on what you mean by being equal.
are the following two variables equal:
int x=0
char c=0;

Perhaps you have spent a long time doing assembler program-
ming. There, if two addresses are the same that's all you
care about. But when you go to a languages with a type
system things are different. It isn't just about memory
addresses anymore. Suddenly, two addresses being the same
isn't all there is since pointers with different types also
have different properties, like different behaviour when
being incremented. They add a new meaning that can't be
expressed in terms of just their values. A lot of things
become simpler but at the cost of having to think in two
and not just one "dimension" - value and type instead of
just value.

Yes there is obviously a difference in opinions on this. I think neither POV
can be said to be right or wrong.

But having this acceptance for others' POV I feel its wrong to suggest one
POV is sloppy and somehow incorrect when it's a failure to understand the
other POV.

Yes, and because that loss of information would not happen
when you go from an array-of-T to an pointer-to-array-of-T.
The type array-to-T e.g. "knows" abouth the number of ele-
ments, as does the type pointer-to-array-of-T, while the
type pointer-to-T has no notion at all of something like
"numbers of elements" - there are no elements, just a
pointer to a single instance of T.

But sometimes you don't need the type info.
And often you have no option because you are using a function that takes a
pointer to an array , not a reference.
Perhaps it would be better if C++ pointers to array were of the type you
describe but this is not the case , I think we are stuck with the present
case which we inhereted from C

char* p= new char[64];
The above is a pointer points to an array of 64 chars.

No, that's a pointer to a single char, the one at the
very start of the array. If you want a pointer to an
array of 64 chars you need

char (*p64)[64];

Ok so this is also wrong?
<quote ref=http://www2.research.att.com/~bs/glossary.html>
"char* - pointer to a char or an array of char."
</quote>

Again lingo, not wrong when meant in the right way, just a
bit sloppily expressed. It might have been better if he had
said "...or the first element of an array", but then this is
a glossary, not an in-depth explanation.

Again why would he say pointer the nth element, when the pointer can
point
to any element?

It's really simple: If you increment a pointer by 1 it
always points to the address directly behind the object
it pointed to (its value is increased by the size of the
type of object it points to). And if you incrememt 'p'
by 1 it points to the next char in the array, so it's a
pointer to a single char, not an array of so many chars.
That it points to the first element of the array doesn't
change anything about that. But if you increment 'p64' by
1 it points directly past the end of the array, so that's
a pointer to an array of 64 chars.

Perhaps you should read Chris Torek's nice article about
pointers and arrays

http://web.torek.net/torek/c/pa.html

and also

http://web.torek.net/torek/c/expr.html#therule

(which might address the reasons behind your confusion).
While it's about C C++ works the same way.

Thanks for your post but I think you should read the quotes I posted
above
from Bjarbne Stroustrup and Steve Summit.

I did but I don't think they really support your point of view.

\They clearly state exactly my POV.
That a char* can point to a single char or an array of chars.

Why then does incrementing pointers of different types re-
sult in different values? You seem to be avoiding that point.
Or you're using your private definition of "pointer", probably
one that turns a blind eye to pointers having a type beside a
value. That's nothing I'm going to have sleepness nights about,
but it makes discussions a bit difficult and, if you insist on
your definition, futile in the longer (or even shorter) run.

I don't see that I'm avoiding anything.
You ask why does incremeenting pointers of different types result in
different values.

I think you mean by different values , you probably mean different stepping
increments and not the value of the pointer.
The way I see it an array is converted to a pointer of type pointer to (n-1)
dimensional array. So with a 2dim array the pointer-type it's converted to
is:
T (*)[Dim2]

incrementing this pointer-type would result in stepping increments
sizeof(T)*Dim2, which effectively would step over a whole sub-array. This
allows the following 2d subscripting with 2d array pointers:
p[0][0];

 

[Jens Thoms Toerring]

This is not true. A pointer is a varaible with a memory address
for a value.

You're again thinking only in terms of the values of pointers,
i.e. memory addresses, and are disregarding that a pointer is
more than an address - it has another quality, it got 'type'.

The object stored at the memory location is not defined by the pointer-type,
for example:
int x =0;
char* p = 0;
p= (char*)&x;
p[2] =1;

The pointer-type is char* , but its initialised to point to nothing,
then it is assgined the address of an int. At no time does this
pointer point to an object of type char.

When you dereference the char pointer the compiler will
extract a value of type char from that location. By poin-
ting a char pointer to an address you promise the compiler
that it can extract a char value from there when asked to.
That's not a big problem with chars - since they are the
smallest addressable unit you hardly can go wrong with that.

The other way round (assuming an int with 4 bytes)

char y[ ] = "abcd";
int * ip = ( int * ) &y;

you're already into deeper trouble. If you use 'ip' to get
at an int value stored in that location you get away with
that on a number of architectures all of the time, but on
others, if you're unlucky, your program will crash with a
bus error since the array of chars may not be properly
aligned for an int access.

And then, when you convert from one type to another, you
have to go to some effort, especially under C++. C is
somewhat more relaxed about that since it was intorduced
forprogramming near to the metal were most people had a
good idea what can be done and what to avoid. C++ tightens
the rules quite a bit to keep people from making mistakes
but still lets you do a lot of things that are against the
type system (making casts more ugly and harder to write
is another way to dicourage people to use them). So, yes,
you can work against the type system, but at your own peril
- and then, if you do, it's advantageous if you understand
what you're doing.

This is a pointer to an array type.

You need to acknowledge that an array-type is not the same as an array
entity.

I don't know exactly what an 'array entity' is supposed to mean.
If it means a "real array" I use in my program, then yes, of
course, it's something different. The same way a table isn't
the same as the word "table".

When we say a char* can point to an array we are speaking about an
array entity.

You are, again, disregarding 'type'. I never claimed that an
array has not the same address as its first element. But hol-
ding the same address does not make two pointers identical
if they have different types. If I have a laser shining at
my head at same time stand in the sun that doesn't make the
laser the same as the sun just because they both illuminate
my head. Two pointers of different types behave differently,
even if they point to the same memory location.

Or take an example that doesn't involve pointers at all:

usigned char c = 0;
unsigned long l = 0;

You're arguing that they are the same since they both have
the same value. But now let's do the exact same thing to
both variables:

c += 2263576;
l += 2263576;

And now it becomes (at least on "normal" machines, where
the range of a char is rather limited) that they are not
the same at all, you just have to compare their values.
So their different types make a lot of a difference, even
if both started of with the same value and the exact same
operation was applied to them.

When an array is converted to a pointer, the pointer-type is a
pointer to a (n-1) dimensional array.

I go into that at the end.

You can't say a statement such as "a char* can point to an array of chars"
is sloppy because you have interpreted it incorrectly. You are confusing the
obvious(IMO) context of an array entity, with array-type.

I have no problem saying that. It may be ok to say "a char *
points to an array" when everyone around understands that
this is just short for "points to the first element of an
array" and I don't want to sound pompous or like a buro-
crat but that doesn't make it a precise statement.

If you cannot access the array , then its not a pointer to the array.
A pointer to an array , when dereferenced must access the array.

Of course, you can access the array, I never said anything
else. You just can't directly access its individual elements
of the array. The same way you can't directly access the in-
dividiual members of a structure when you have a pointer to
a structure. The pointer to the structure points to the
structure as a whole (even when that is the same address as
the first member) and you need some extra syntax to get at
its members.

Actually, according to your line of arguments you also should
say that with

struct {
int x;
int y;
} z;

int * ix = ( int * ) &z;

'ix' is now a pointer to the structure. It's value is the
same as the address of 'z', so, according to your criteria,
it should be a pointer to the structure. But do you really
think so?

What you describe is an indirect pointer to an array, you must dereference
it twice to access the array.

No. There is a difference between accessing an array and
accessing an element of an array. An array is a structured
blob in memory the same way e.g. a structure is. And a
pointer to an array points to that blob. Getting at its
innards need a bit more work, as it is needed for getting
at the members of a structure. That you can't write an
element access like e.g. 'ap->[1]' (which would be 'sym-
metric to how one would deal with a structure pointer) is
just the "fault" of the language and you thus have to re-
sort to the more ugly '(*ap)[1]', in e.g. Perl that's quite
fine when you have a pointer (reference) to an array.

An array of chars is not a type, its an entity.

I never said that an array of chars "is" a type, I said
it "has" a type - beside its property of consisting of a
number of bytes. We're not discussing assembler here, the
language adds types to entities when we progrm in that
language and we need to consider that. What later happens
at the execution phase is something different. There is no
1-to-1 mappin between the language and what the processor
does when the program has been compiled. Otherwise using a
computer language would be useless.

A pointer of type char* can point to an array of chars, when dereferenced it
returns one element of the array.
You cannot get any pointer type that addresses a whole array simultaneously,
unless the array is sized one or something silly like that.
This depends on what you mean by being equal.
are the following two variables equal:
int x=0
char c=0;

No, they aren't, see above.

Yes there is obviously a difference in opinions on this. I think neither POV
can be said to be right or wrong.

I don't think so. I feel that you're missing an important
point, i.e. that a computer language is more than just
about bits and bytes. It adds completely new levels of mea-
ning that can't be understood in terms of what happpens at
the register and memory level. This allow you to get away
from thinking just in categories of bytes and what happens
to them and instead lets you concentrate on the problem do-
main. Like, when you write "car->turn( 30 );" in an OOP
program you aren't supposed to keep in mind what that does
in terms of what happens in the CPU, you should keep focused
on what the class 'car' is an instance of will do with that.

But having this acceptance for others' POV I feel its wrong to suggest one
POV is sloppy and somehow incorrect when it's a failure to understand the
other POV.

You're in a good mood tonight;-) But, sorry, I think your
POV is wrong, or at least misses an important aspect.

But sometimes you don't need the type info.
And often you have no option because you are using a function that takes a
pointer to an array , not a reference.

But regardles if I want the type or not it's there, given by the
language I'm using.

Perhaps it would be better if C++ pointers to array were of the type you
describe but this is not the case , I think we are stuck with the present
case which we inhereted from C

I'm not really religious about the way it's done in C or C++.
And passing a pointer to an array would require other changes
in the language. Since an array has a well-defined length you
would need a functions for each length of array. To avoid
that You would need to change C++ so that it would accept an
argument of 'pointer to array of unspecified length' but still
be able to get at the length - or you'd be back to square one,
i.e. you'd would have to pass a length with the pointer to the
array. And when we would need that then it would make no sense
at all, there would hardly any difference to what we have now.

char* p= new char[64];
The above is a pointer points to an array of 64 chars.

No, that's a pointer to a single char, the one at the
very start of the array. If you want a pointer to an
array of 64 chars you need

char (*p64)[64];

Ok so this is also wrong?
<quote ref=http://www2.research.att.com/~bs/glossary.html>
"char* - pointer to a char or an array of char."
</quote>

Again lingo, not wrong when meant in the right way, just a
bit sloppily expressed. It might have been better if he had
said "...or the first element of an array", but then this is
a glossary, not an in-depth explanation.

Again why would he say pointer the nth element, when the pointer can
point
to any element?

It's really simple: If you increment a pointer by 1 it
always points to the address directly behind the object
it pointed to (its value is increased by the size of the
type of object it points to). And if you incrememt 'p'
by 1 it points to the next char in the array, so it's a
pointer to a single char, not an array of so many chars.
That it points to the first element of the array doesn't
change anything about that. But if you increment 'p64' by
1 it points directly past the end of the array, so that's
a pointer to an array of 64 chars.

Perhaps you should read Chris Torek's nice article about
pointers and arrays

http://web.torek.net/torek/c/pa.html

and also

http://web.torek.net/torek/c/expr.html#therule

(which might address the reasons behind your confusion).
While it's about C C++ works the same way.

Thanks for your post but I think you should read the quotes I posted
above
from Bjarbne Stroustrup and Steve Summit.

I did but I don't think they really support your point of view.

\They clearly state exactly my POV.
That a char* can point to a single char or an array of chars.

Why then does incrementing pointers of different types re-
sult in different values? You seem to be avoiding that point.
Or you're using your private definition of "pointer", probably
one that turns a blind eye to pointers having a type beside a
value. That's nothing I'm going to have sleepness nights about,
but it makes discussions a bit difficult and, if you insist on
your definition, futile in the longer (or even shorter) run.

I don't see that I'm avoiding anything.
You ask why does incremeenting pointers of different types result in
different values.

I think you mean by different values , you probably mean different stepping
increments and not the value of the pointer.

The values of the two pointers 'p' and 'p64'

char x[ 64 ];
char *p = x;
char ( *p64 )[ 64 ] = &x;

are the same now but will definitely be different after you did

p++;
p64++;

The first one will point to the second element of the array 'x',
the other will point directly after the end of 'x'. So I would
call that a different value, wouldn't you? And that's one of
the differences in behaviour that's due to the different types
of the pointers.

The way I see it an array is converted to a pointer of type pointer to (n-1)
dimensional array. So with a 2dim array the pointer-type it's converted to
is:
T (*)[Dim2]

incrementing this pointer-type would result in stepping increments
sizeof(T)*Dim2, which effectively would step over a whole sub-array. This
allows the following 2d subscripting with 2d array pointers:
p[0][0];

Nice point you're giving me there;-) If you have e.g.

int a[ 3 ][ 5 ];

then you need

int ( *ap )[ 5 ] = a;

i.e. 'a' "decays" to a real 1D array pointer like the one I des-
cribed before. And are you now going to argue that '(*ap)[5]' is
a pointer to a two-dimensional array as it would seem logical to
me when you claim that 'char *' is also a pointer to an array?

To me it looks like a pointer to a 1-dimensional array as this
example program perhaps can illustrate

#include <iostream>
int main( )
{
int a[ 3 ] = { 1, 2, 3 };
int ( *ap )[ 3 ] = &a;
int b[ 3 ][ 2 ] = { { 7, 9,}, { -4, 5,}, { 8, -5 } };
int ( *bp )[ 2 ] = b;
std::cout << ( *ap )[ 1 ] << ' ' << ( *bp )[ 1 ] << '\n';
}

- both 'ap' and 'bp' seem to me to have the same type.

As you say, this conversion ("decaying" when an array is used
in a context where a value is expected) reduces the dimension
by 1. But that does not make the thing on the left and right
hand side the same - the equal sign is even more out of place
here then it is everywhere else (when you consider its mathe-
matical meaning). This is basically an overloding of the '='
operator to get any sense out of that expression since an
array (whatever it's dimension) simply has no value in C or
C++ and thus such an expression would be meaningless other-
wise. (Or arrays would have to be made "first-class" citi-
zens of C and C++, so that you could assign one array to
another with '=' and pass it by value to a function, as you
can do with structures or class instances.)

 

[Paul]

You're again thinking only in terms of the values of pointers,
i.e. memory addresses, and are disregarding that a pointer is
more than an address - it has another quality, it got 'type'.

This is what we are talking about when we say that a char* can point to an
array of chars, the context if an array is an entity , not a type.

I think what you say is incorrect and it is in fact it's actually you who
can only think in terms of an array as a type.

The object stored at the memory location is not defined by the pointer-type,
for example:
int x =0;
char* p = 0;
p= (char*)&x;
p[2] =1;

The pointer-type is char* , but its initialised to point to nothing,
then it is assgined the address of an int. At no time does this
pointer point to an object of type char.

When you dereference the char pointer the compiler will
extract a value of type char from that location. By poin-
ting a char pointer to an address you promise the compiler
that it can extract a char value from there when asked to.

No I dereferenced the char* and I did not extract anything.

But you seenm to be deviating from the original topic , which is what is
pointed to .
So what is pointed to , is it an int object, or a char object?

That's not a big problem with chars - since they are the
smallest addressable unit you hardly can go wrong with that.

The other way round (assuming an int with 4 bytes)

char y[ ] = "abcd";
int * ip = ( int * ) &y;

you're already into deeper trouble.

No you are in trouble , this is YOUR code not mine.

If you use 'ip' to get
at an int value stored in that location you get away with
that on a number of architectures all of the time, but on
others, if you're unlucky, your program will crash with a
bus error since the array of chars may not be properly
aligned for an int access.

Its YOUR error here , I don't know what you are talking about , some kinda
bad coding techniques.

And then, when you convert from one type to another, you
have to go to some effort, especially under C++. C is
somewhat more relaxed about that since it was intorduced
forprogramming near to the metal were most people had a
good idea what can be done and what to avoid.

Now you are on about converting types.

C++ tightens
the rules quite a bit to keep people from making mistakes
but still lets you do a lot of things that are against the
type system (making casts more ugly and harder to write
is another way to dicourage people to use them). So, yes,
you can work against the type system, but at your own peril
- and then, if you do, it's advantageous if you understand
what you're doing.

Its not working against the type system, its using the type system to your
benefit.

When you access an array you want to access one element only. So it only
makes sense to use a pointer-type that when dereferenced accesses one
element.
In fact this is the only technical possibilty on most , if not all ,
computer systems.
A computer system cannot have a pointer that can access a whole array
simultaneously.

I don't know exactly what an 'array entity' is supposed to mean.
If it means a "real array" I use in my program, then yes, of
course, it's something different. The same way a table isn't
the same as the word "table".

I mean a real array, not a type.

For example and integer is a whole number value , an integer-type is not.
An array-type is a type. An array is not a type , its a sequence of objects.

You are, again, disregarding 'type'. I never claimed that an
array has not the same address as its first element.

I am not disregarding type , I am explained what is meat when we say a char*
can point to an array.

You are only thinking of type, it is you who is disregarding the pointed to
object.

But hol-
ding the same address does not make two pointers identical
if they have different types. If I have a laser shining at
my head at same time stand in the sun that doesn't make the
laser the same as the sun just because they both illuminate
my head. Two pointers of different types behave differently,
even if they point to the same memory location.

Nobody is denying that two different pointer types can point to the same
location.
But your example does not change the fact that both pointers point to your
head. They don't necessarrily only point to your type of head. One of the
pointer-types could be made to point to , for example, an alien head type.

Or take an example that doesn't involve pointers at all:

usigned char c = 0;
unsigned long l = 0;

You're arguing that they are the same since they both have
the same value. But now let's do the exact same thing to
both variables:

c += 2263576;
l += 2263576;

And now it becomes (at least on "normal" machines, where
the range of a char is rather limited) that they are not
the same at all, you just have to compare their values.
So their different types make a lot of a difference, even
if both started of with the same value and the exact same
operation was applied to them.

Here we are talking about equality, the example I gave was two variables ,
of different-types, which hold the same value. Are they equal?

If you change the values to create two variables with different values, then
I don't think the same thing is being expressed.

I go into that at the end.


I have no problem saying that. It may be ok to say "a char *
points to an array" when everyone around understands that
this is just short for "points to the first element of an
array" and I don't want to sound pompous or like a buro-
crat but that doesn't make it a precise statement.

But what if it doesn't point to the first element of the array?
A pointer to an array doesn't have to point to the first element.

Of course, you can access the array, I never said anything
else. You just can't directly access its individual elements
of the array. The same way you can't directly access the in-
dividiual members of a structure when you have a pointer to
a structure. The pointer to the structure points to the
structure as a whole (even when that is the same address as
the first member) and you need some extra syntax to get at
its members.

It's not the same at all. A pointer to a structure accesses the structure
when dereferenced.
A structure is a type, an array is not a type it is a sequence of objects.
The type of an array is that of the objects it contains, for exmaple:

float arr[16];

The type is float, you just asked the compiler to make 16 of them in
sequnece. If you want to access one of them you need a float type pointer.
float* p = arr;

This is a pointer to the array, its type is float* because when we
derefernece this pointer we want to access a float object.

Actually, according to your line of arguments you also should
say that with

struct {
int x;
int y;
} z;

int * ix = ( int * ) &z;

'ix' is now a pointer to the structure. It's value is the
same as the address of 'z', so, according to your criteria,
it should be a pointer to the structure. But do you really
think so?

No I would disagree with this , because a structure has diffferent rules for
memory layout.
I wouldn't be surprised if dereferencing this pointer resulted in UB.

No. There is a difference between accessing an array and
accessing an element of an array. An array is a structured
blob in memory the same way e.g. a structure is.

I disagree , an array is not the same as a structure.

And a
pointer to an array points to that blob.

You cannot get a pointer that, when dereferenced, accessses the whole array.
You can with a structure.

Getting at its
innards need a bit more work, as it is needed for getting
at the members of a structure. That you can't write an
element access like e.g. 'ap->[1]' (which would be 'sym-
metric to how one would deal with a structure pointer) is
just the "fault" of the language and you thus have to re-
sort to the more ugly '(*ap)[1]', in e.g. Perl that's quite
fine when you have a pointer (reference) to an array.

I think you are way off on the wrong track here, arrays and structs are two
completely different things.
for example:

struct Foo{};
Foo* p_foo = new Foo;

The above pointer, when dereferenced, accesses a whole Foo object.
You cannot do this with an array. An array can be created in the following
ways:

Foo* p_arr = new Foo[64];
Foo arr[64];

There is no way to access either array, as a whole. The underlying
techincalities of a computer system do not allow us to directly access an
array , as a whole.

I never said that an array of chars "is" a type, I said
it "has" a type - beside its property of consisting of a
number of bytes.

An array of chars has the type char. Look at the declaration:

char arr[16];

The type is char.
You seem to think the type is some fancy array-type, its not.

We're not discussing assembler here, the
language adds types to entities when we progrm in that
language and we need to consider that. What later happens
at the execution phase is something different. There is no
1-to-1 mappin between the language and what the processor
does when the program has been compiled. Otherwise using a
computer language would be useless.


No, they aren't, see above.

As I said it depends on what you mean by equal,
Mathematically x and c both contain the value zero, they are equal in that
sense.

I don't think so. I feel that you're missing an important
point, i.e. that a computer language is more than just
about bits and bytes. It adds completely new levels of mea-
ning that can't be understood in terms of what happpens at
the register and memory level. This allow you to get away
from thinking just in categories of bytes and what happens
to them and instead lets you concentrate on the problem do-
main. Like, when you write "car->turn( 30 );" in an OOP
program you aren't supposed to keep in mind what that does
in terms of what happens in the CPU, you should keep focused
on what the class 'car' is an instance of will do with that.


You're in a good mood tonight;-) But, sorry, I think your
POV is wrong, or at least misses an important aspect.

Oh well I thought I was letting you of the hook by accepting you POV but
obviously this gesture of good will has backfired on me

But regardles if I want the type or not it's there, given by the
language I'm using.

Yes but you don't seem to think an array has some magical type, for example:

char arr1[12];
int arr2[12];

The above arrays have the types char and int respectively. There is no
magical type.

Perhaps it would be better if C++ pointers to array were of the type you
describe but this is not the case , I think we are stuck with the present
case which we inhereted from C

I'm not really religious about the way it's done in C or C++.
And passing a pointer to an array would require other changes
in the language. Since an array has a well-defined length you
would need a functions for each length of array. To avoid
that You would need to change C++ so that it would accept an
argument of 'pointer to array of unspecified length' but still
be able to get at the length - or you'd be back to square one,
i.e. you'd would have to pass a length with the pointer to the
array. And when we would need that then it would make no sense
at all, there would hardly any difference to what we have now.

char* p= new char[64];
The above is a pointer points to an array of 64 chars.

No, that's a pointer to a single char, the one at the
very start of the array. If you want a pointer to an
array of 64 chars you need

char (*p64)[64];

Ok so this is also wrong?
<quote ref=http://www2.research.att.com/~bs/glossary.html>
"char* - pointer to a char or an array of char."
</quote>

Again lingo, not wrong when meant in the right way, just a
bit sloppily expressed. It might have been better if he had
said "...or the first element of an array", but then this is
a glossary, not an in-depth explanation.

Again why would he say pointer the nth element, when the pointer can
point
to any element?

It's really simple: If you increment a pointer by 1 it
always points to the address directly behind the object
it pointed to (its value is increased by the size of the
type of object it points to). And if you incrememt 'p'
by 1 it points to the next char in the array, so it's a
pointer to a single char, not an array of so many chars.
That it points to the first element of the array doesn't
change anything about that. But if you increment 'p64' by
1 it points directly past the end of the array, so that's
a pointer to an array of 64 chars.

Perhaps you should read Chris Torek's nice article about
pointers and arrays

http://web.torek.net/torek/c/pa.html

and also

http://web.torek.net/torek/c/expr.html#therule

(which might address the reasons behind your confusion).
While it's about C C++ works the same way.

Thanks for your post but I think you should read the quotes I
posted
above
from Bjarbne Stroustrup and Steve Summit.

I did but I don't think they really support your point of view.

\They clearly state exactly my POV.
That a char* can point to a single char or an array of chars.

Why then does incrementing pointers of different types re-
sult in different values? You seem to be avoiding that point.
Or you're using your private definition of "pointer", probably
one that turns a blind eye to pointers having a type beside a
value. That's nothing I'm going to have sleepness nights about,
but it makes discussions a bit difficult and, if you insist on
your definition, futile in the longer (or even shorter) run.

I don't see that I'm avoiding anything.
You ask why does incremeenting pointers of different types result in
different values.

I think you mean by different values , you probably mean different
stepping
increments and not the value of the pointer.

The values of the two pointers 'p' and 'p64'

char x[ 64 ];
char *p = x;
char ( *p64 )[ 64 ] = &x;

are the same now but will definitely be different after you did

p++;
p64++;

The first one will point to the second element of the array 'x',
the other will point directly after the end of 'x'. So I would
call that a different value, wouldn't you? And that's one of
the differences in behaviour that's due to the different types
of the pointers.

p64 is the wrong type, it has an extra level of indirection.
The pointed to array is an array of chars, not a array of char[64].

The way I see it an array is converted to a pointer of type pointer to
(n-1)
dimensional array. So with a 2dim array the pointer-type it's converted
to
is:
T (*)[Dim2]

incrementing this pointer-type would result in stepping increments
sizeof(T)*Dim2, which effectively would step over a whole sub-array. This
allows the following 2d subscripting with 2d array pointers:
p[0][0];

Nice point you're giving me there;-) If you have e.g.

int a[ 3 ][ 5 ];

then you need

int ( *ap )[ 5 ] = a;

i.e. 'a' "decays" to a real 1D array pointer like the one I des-
cribed before. And are you now going to argue that '(*ap)[5]' is
a pointer to a two-dimensional array as it would seem logical to
me when you claim that 'char *' is also a pointer to an array?

To me it looks like a pointer to a 1-dimensional array as this
example program perhaps can illustrate

#include <iostream>
int main( )
{
int a[ 3 ] = { 1, 2, 3 };
int ( *ap )[ 3 ] = &a;

The above is a pointer derivation. You are creating another level of
indirection.
'a' is converted to a pointer and you take the address of it. 'ap' is
basically a pointer to a pointer.

int b[ 3 ][ 2 ] = { { 7, 9,}, { -4, 5,}, { 8, -5 } };
int ( *bp )[ 2 ] = b;
std::cout << ( *ap )[ 1 ] << ' ' << ( *bp )[ 1 ] << '\n';
}

- both 'ap' and 'bp' seem to me to have the same type.

no one is int(*)[3] and the other is int(*)[2].

 

[Jens Thoms Toerring]

The type of an array is that of the objects it contains, for exmaple:

float arr[16];

The type is float, you just asked the compiler to make 16 of them in
sequnece.

No, that's simply wrong. The newly created object 'arr' has
the type 'array-of-16-floats' and not 'float'. If we can't
even agree on something that simple and obvious we can stop
here since we will never get any further.