Your view of FAQ section.

[Richard]

One of the most repeatedly given pointers is to

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

which discusses pointers and arrays and the subtle differences between

char a[] = "hello";
char *p = "world";

Now, my question is this - how do you feel about the way the FAQ
describes the compiler working. We already now that pointers and arrays
may or may not compile differently and may or may not be more efficient
than each other depending on target HW.

But should the FAQ really go into detail about how the compiler
calculates element addresses?

e.g

,----
| It is useful to realize that a reference like x[3] generates different code depending on whether x is an array or a pointer. Given the declarations above, when the compiler
| sees the expression a[3], it emits code to start at the location ``a'', move three past it, and fetch the character there. When it sees the expression p[3], it emits code to
| start at the location ``p'', fetch the pointer value there, add three to the pointer, and finally fetch the character pointed to. In other words, a[3] is three places past
| (the start of) the object named a, while p[3] is three places past the object pointed to by p. In the example above, both a[3] and p[3] happen to be the character 'l', but
| the compiler gets there differently. (The essential difference is that the values of an array like a and a pointer like p are computed differently whenever they appear in
| expressions, whether or not they are being subscripted, as explained further in question 6.3.) See also question 1.32.
`----

 

[Keith Thompson]

One of the most repeatedly given pointers is to

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

which discusses pointers and arrays and the subtle differences between

char a[] = "hello";
char *p = "world";

Now, my question is this - how do you feel about the way the FAQ
describes the compiler working. We already now that pointers and arrays
may or may not compile differently and may or may not be more efficient
than each other depending on target HW.

But should the FAQ really go into detail about how the compiler
calculates element addresses?

Yes.

 

[Richard]

One of the most repeatedly given pointers is to

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

which discusses pointers and arrays and the subtle differences between

char a[] = "hello";
char *p = "world";

Now, my question is this - how do you feel about the way the FAQ
describes the compiler working. We already now that pointers and arrays
may or may not compile differently and may or may not be more efficient
than each other depending on target HW.

But should the FAQ really go into detail about how the compiler
calculates element addresses?

Yes.

Can you explain why?

Does the standard stipulate how the compiler must generate the addresses?

 

[Keith Thompson]

One of the most repeatedly given pointers is to

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

which discusses pointers and arrays and the subtle differences between

char a[] = "hello";
char *p = "world";

Now, my question is this - how do you feel about the way the FAQ
describes the compiler working. We already now that pointers and arrays
may or may not compile differently and may or may not be more efficient
than each other depending on target HW.

But should the FAQ really go into detail about how the compiler
calculates element addresses?

Yes.

Can you explain why?

Does the standard stipulate how the compiler must generate the addresses?

Ok, that was overly terse. But the FAQ doesn't really talk about
generated code; it's more of a description of what happens in the
abstract machine, which is important to an understanding of what the
code actually means.

Do you have a better way to describe the difference between a[3] and
p[3] (where a is an array object and p is a pointer object)?

 

[Malcolm McLean]

One of the most repeatedly given pointers is to

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

which discusses pointers and arrays and the subtle differences between

char a[] = "hello";
char *p = "world";

Now, my question is this - how do you feel about the way the FAQ
describes the compiler working. We already now that pointers and arrays
may or may not compile differently and may or may not be more efficient
than each other depending on target HW.

But should the FAQ really go into detail about how the compiler
calculates element addresses?

Yes.

Can you explain why?

Does the standard stipulate how the compiler must generate the addresses?

Ok, that was overly terse. But the FAQ doesn't really talk about
generated code; it's more of a description of what happens in the
abstract machine, which is important to an understanding of what the
code actually means.

Do you have a better way to describe the difference between a[3] and
p[3] (where a is an array object and p is a pointer object)?

Exactly. People are looking for an explanation, not a definition. Sometimes
it is better to say something which is slightly inaccurate, or only
represents the general case, but is concrete, rather than give the latter of
the law.

Array - pointer equivalance is a classic case. Unless you go through a
stage of thinking that arrays and pointers are equivalent, you will never
understand why they are not equivalent.

 

[Richard]

One of the most repeatedly given pointers is to

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

which discusses pointers and arrays and the subtle differences between

char a[] = "hello";
char *p = "world";

Now, my question is this - how do you feel about the way the FAQ
describes the compiler working. We already now that pointers and arrays
may or may not compile differently and may or may not be more efficient
than each other depending on target HW.

But should the FAQ really go into detail about how the compiler
calculates element addresses?

Yes.

Can you explain why?

Does the standard stipulate how the compiler must generate the addresses?

Ok, that was overly terse. But the FAQ doesn't really talk about
generated code; it's more of a description of what happens in the
abstract machine, which is important to an understanding of what the
code actually means.

Do you have a better way to describe the difference between a[3] and
p[3] (where a is an array object and p is a pointer object)?

No. But telling us how the compiler may or may not do it is overly
presumptuous IMO.

Only a while ago I was sure (as stated in K&R2 too btw) that using
pointers and not arrays generated faster code as a general rule. Some
work I have done since has pretty much made me change my mind.

 

[Eric Sosman]

Do you have a better way to describe the difference between a[3] and
p[3] (where a is an array object and p is a pointer object)?

No. But telling us how the compiler may or may not do it is overly
presumptuous IMO.

The goal of the FAQ is explanation, not specification.
As such, it quite frequently ventures outside the territory
marked off by the Standard -- for example, it talks not only
about "undefined behavior" but also about "segmentation
violation" and "general protection fault." I see nothing
amiss with the FAQ speaking about generated code (which itself
is beyond the scope of the Standard) to highlight a point and
bring the reader closer to the "Aha!" moment.

 

[Flash Gordon]

Malcolm McLean wrote, On 03/06/07 10:17:

Do you have a better way to describe the difference between a[3] and
p[3] (where a is an array object and p is a pointer object)?

Exactly. People are looking for an explanation, not a definition.
Sometimes it is better to say something which is slightly inaccurate, or
only represents the general case, but is concrete, rather than give the
latter of the law.

To an extent, yes.

Array - pointer equivalance is a classic case. Unless you go through a
stage of thinking that arrays and pointers are equivalent, you will
never understand why they are not equivalent.

However here I completely disagree.

I can't remember ever thinking that arrays and pointers were equivalent,
and I can see no reason why someone would need to believe that
particular fallacy before understanding why it is false. Explain one
concept in one lesson, make sure it is understood, explain the other
concept in another lesson and make sure it is understood, and then
explain that because of the way C implements arrays you don't pass
arrays and when you can treat one as the other.

 

[Keith Thompson]

Array - pointer equivalance is a classic case. Unless you go through a
stage of thinking that arrays and pointers are equivalent, you will
never understand why they are not equivalent.

Either I don't understand that statement, or I completely disagree
with it; I'm not sure which.

Surely it's possible for someone learning C to understand from the
beginning that arrays and pointers are very different things, if the
concepts are just explained correctly on the first exposure.

 

[Chris Dollin]

Array - pointer equivalance is a classic case. Unless you go through a
stage of thinking that arrays and pointers are equivalent, you will never
understand why they are not equivalent.

I don't think I ever went through the stage of believing that they
were equivalent, but I claim I understand why they are not.

Of course, C wasn't my first language -- it wasn't even my fourth --
and I hacked BCPL before I ever met C in real life.

 

[Malcolm McLean]

Either I don't understand that statement, or I completely disagree
with it; I'm not sure which.

Surely it's possible for someone learning C to understand from the
beginning that arrays and pointers are very different things, if the
concepts are just explained correctly on the first exposure.

You've got an unusual mind. Which is probably a strength, as a programmer.
However most people think and learn in far less abstract way.

 

[Keith Thompson]

You've got an unusual mind. Which is probably a strength, as a
programmer. However most people think and learn in far less abstract
way.

I still disagree. I think most people are perfectly capable of
understanding C pointers and arrays without *ever* having the delusion
that they're the same thing. And anyone who's not capable of that
likely will never really understand either arrays or pointers.

(I'm not saying that anyone who has thought arrays and pointers are
the same thing can never understand them. The misconception is
unnecessary, not fatal.)

 

[Flash Gordon]

Keith Thompson wrote, On 07/06/07 08:02:

[...]
Array - pointer equivalance is a classic case. Unless you go through a
stage of thinking that arrays and pointers are equivalent, you will
never understand why they are not equivalent.
Either I don't understand that statement, or I completely disagree
with it; I'm not sure which.

Surely it's possible for someone learning C to understand from the
beginning that arrays and pointers are very different things, if the
concepts are just explained correctly on the first exposure.

You've got an unusual mind. Which is probably a strength, as a
programmer. However most people think and learn in far less abstract
way.

I still disagree. I think most people are perfectly capable of
understanding C pointers and arrays without *ever* having the delusion
that they're the same thing. And anyone who's not capable of that
likely will never really understand either arrays or pointers.

I agree. I've managed to explain the concepts of arrays and pointer to
people who have NO programming experience. It is really very easy to
explain in a classroom.

Desks are arranged in a traditional way in the classroom. OK, here is a
2 dimensional array of desks. We will number the rows from 0, and the
columns from 0, so John is in desk[3][5].

Now for pointers. My finger is pointing to desk[3][5], now I'm going to
increment it, it is now pointing at desk[3][6] where Jenny is.

Simple. Then, once they understand the general concepts of arrays and
pointers you can go on to explain the wrinkles of array in C.

As I say, I know that this type of explanation works (possibly with a
bit more discussion) since I've used it with non-computer people and
managed to go on to explain why things are not working in buggy programs.

(I'm not saying that anyone who has thought arrays and pointers are
the same thing can never understand them. The misconception is
unnecessary, not fatal.)

Agreed.