Pointers...once again

[mdh]

Starting Chapter 5 in K&R, and it does not get easier..but it is worth
it...I am repeatedly told!

K&R say that in the statement
p=&c;

"p is said to "point to c".

I know this will sound dumb, but no where does it say how the statement
is read...

Do you say "P equals alpha c" or do you read it just the way K&R say?

By the same token, how does one read this declaration?

int *ip;

K&R simply says /*** ip is a pointer to int **/

On a slightly more deeper note ( I hope)

Quote " the unary operators * and & bind more tightly then the
arithmetic operators" so the assignment

y = *ip + 10 etc etc


Does this mean that in the above expression, using

*ip or ip* would make no difference?

Lastly, K&R state "unary operators like ++ and * associate right to
left.

The example they use is (*ip)++. I do not quite understand how without
the parentheses, ip would be incremented. Could anyone throw some light
on this.

Again, as usual, thanks in advance for any enlightenment.

 

[Richard Tobin]

K&R say that in the statement
p=&c;

"p is said to "point to c".

I know this will sound dumb, but no where does it say how the statement
is read...

Do you say "P equals alpha c" or do you read it just the way K&R say?

I would say "p equals ampersand c" (it's not an alpha).

By the same token, how does one read this declaration?

int *ip;

"int star p"

Quote " the unary operators * and & bind more tightly then the
arithmetic operators" so the assignment

y = *ip + 10 etc etc


Does this mean that in the above expression, using

*ip or ip* would make no difference?

No, because * is a prefix operator.

Lastly, K&R state "unary operators like ++ and * associate right to
left.

The example they use is (*ip)++. I do not quite understand how without
the parentheses, ip would be incremented. Could anyone throw some light
on this.

Based on recent discussions here, I would recommend reading the
grammar in the standard instead of trying to understand it in terms of
associativity.

-- Richard

 

[Rg]

Lot's of questions, uh?

First things first. The = operator means "takes", not "equals". Hence

p = &c

is not p equals c. It means p takes the address of c or, in other
words, points to c. p equals c would be

p == c

As to your second question, there is an analysis in K&R that helps
understand the meaning of int*, int**, int(*) and so forth. Also,
there's a big difference from *p and p*. Read the book more careful, it
will be clarifying.

Now, concerning the expressions:

(*p)++
*p++
++*p

You should think of operator precedence. Both unary operators ++ and *
have equal precedence, so what determines the order in which they
operate is their placement among the operands. So the expression

*p++

first increments the pointer p and then derreferences it (the first
operator evaluated is ++). On the other hand, the expression

++*p

first derreferences the pointer and then increments its value (in other
word, it increments the object pointed by p).

You could rewrite those expressions and get the following equivalence:

*p++ --> (p++, *p)
++*p --> *p += 1

Is that morer clear?


mdh escreveu:

 

[Richard]

Starting Chapter 5 in K&R, and it does not get easier..but it is worth
it...I am repeatedly told!

K&R say that in the statement
p=&c;

"p is said to "point to c".

I know this will sound dumb, but no where does it say how the statement
is read...

Do you say "P equals alpha c" or do you read it just the way K&R say?

You say "p is a pointer to c". Or "p is the address of c". More
generally, "p is a pointer to a char". After it is given the address of
c then "it is a pointer to c".

By the same token, how does one read this declaration?

int *ip;

K&R simply says /*** ip is a pointer to int **/

ip is a pointer to an integer.

On a slightly more deeper note ( I hope)

Quote " the unary operators * and & bind more tightly then the
arithmetic operators" so the assignment

y = *ip + 10 etc etc


Does this mean that in the above expression, using

*ip or ip* would make no difference?

No. They are different things.

Lastly, K&R state "unary operators like ++ and * associate right to
left.

The example they use is (*ip)++. I do not quite understand how without
the parentheses, ip would be incremented. Could anyone throw some light
on this.

*ip++ returns the value pointed to by the pointer ip. ip is then
post-incremented. Stick some printfs in or play around at a debugger
command line. You'll get it!

best of luck.

Again, as usual, thanks in advance for any enlightenment.

--

 

[mdh]

Lot's of questions, uh?

yes...sometimes the only real way to clarify issues. One does run the
risk of showing ones' ignorance...but OTOH, the risk of staying dumb
forever is greater

It means p takes the address of c

Point well taken, thanks.

As to your second question, there is an analysis in K&R that helps
understand the meaning of int*, int**, int(*) and so forth.

OK...will wait to get there...I don't think I have seen that yet.

>Now, concerning the expressions:

... Both unary operators ++ and *
have equal precedence, so what determines the order in which they
operate is their placement among the operands. So the expression

*p++

first increments the pointer p and then derreferences it .......(the first
operator evaluated is ++).
............
++*p

Is that morer clear?

yes...a little...but it all helps.

thanks

 

[mdh]

Stick some printfs in or play around at a debugger
command line. You'll get it!

best of luck.

Thank you...however, your input is very helpful and appreciated.

 

[santosh]

Starting Chapter 5 in K&R, and it does not get easier..but it is worth
it...I am repeatedly told!

K&R say that in the statement
p=&c;

"p is said to "point to c".

I know this will sound dumb, but no where does it say how the statement
is read...

Do you say "P equals alpha c" or do you read it just the way K&R say?

By the same token, how does one read this declaration?

int *ip;

K&R simply says /*** ip is a pointer to int **/

By and large code is "read" mentally where you can often "say" words
which would be far too long to be actually pronounced. Most often you
look at a statement and rapidly get it's meaning without actually
spelling it out, either in your mind or outside.

In the rare case that you do need to spell out the code, being correct
and concise will be sufficient. For example you could say, (for the
second declaration above): "Pointer to int, ip". Saying: "int pointer
ip" would probably be misleading to the listeners.

On a slightly more deeper note ( I hope)

Quote " the unary operators * and & bind more tightly then the
arithmetic operators" so the assignment

y = *ip + 10 etc etc


Does this mean that in the above expression, using

*ip or ip* would make no difference?

No. The former is the prefix form while the latter is the postfix form.
The former deferences ip while the latter references ip to multiply
it's value with 10.

Lastly, K&R state "unary operators like ++ and * associate right to
left.

The example they use is (*ip)++. I do not quite understand how without
the parentheses, ip would be incremented. Could anyone throw some light
on this.

Both * and ++ operators have the same precedence level but the
associate from right to left in an expression. This means that in the
expression:

*ip++

since the ++ operator is the right-most one it's applied to ip before
the * operator is. Hence the value contained in, (not pointed to), ip
is incremented, then ip is deferenced with the value it had before the
increment since the ++ operator is in it's postfix form.

*++ip

In the above, ip is incremented and the modified value is used to
perform the deferencing.

~*--ip[x] * 10

Here, indexing is performed on ip with x then the resulting value is
decremented, the decremented value is deferenced, a bitwise complement
is done on the deferenced value and the result is multiplied with 10.

 

[mdh]

santosh wrote:
...........

Santosh...thank you for that nice explanation.

 

[CBFalconer]

.... snip ...

I would say "p equals ampersand c" (it's not an alpha).

No no no. Djikstra (sp?) would have a fit. p gets ... or ... is
assigned to p. In C we spell equals ==.

 

[Keith Thompson]

Starting Chapter 5 in K&R, and it does not get easier..but it is worth
it...I am repeatedly told!

K&R say that in the statement
p=&c;

"p is said to "point to c".

I know this will sound dumb, but no where does it say how the statement
is read...

Do you say "P equals alpha c" or do you read it just the way K&R say?

By the same token, how does one read this declaration?

int *ip;

K&R simply says /*** ip is a pointer to int **/

In both cases, I usually "pronounce" them just the way they're
spelled. I read and write about C a lot more than I speak about it; I
rarely think about how to pronounce "=" out loud.

But when I do, it's important to distinguish between "=" (assignment)
and "==" (equality). It's tempting to pronounce "=" as "equals", but
it's misleading.

(IMHO, K&R shouldn't have chosen those symbols. I think they picked
"=" for assignment because it's short, which is far less important now
than it was in the days of ASR 33 (?) teletypes. "=" for comparison
and ":=" for assignment would have been better. But we're stuck with
it -- forever.)

I suggest pronouncing "=" as "assign" or "is assigned", and "==" as
"is equal to", but it's up to you.

I'd probably read "p=&c;" (or, preferably, "p = &c;") as "p assign
address of c" or "p is assigned the address of c", or perhaps even
"p assign ampersand c". I *might* say "p equals ampersand c" if I'm
feeling lazy, but see above.

I read "int *ip;" as "int star eye pee" (assuming "ip" isn't an
abbreviation of "ipecac").

[snip]

 

[mdh]

(IMHO, K&R shouldn't have chosen those symbols. I think they picked
"=" for assignment because it's short, which is far less important now
than it was in the days of ASR 33 (?) teletypes. "=" for comparison
and ":=" for assignment would have been better. But we're stuck with
it -- forever.)

I suggest pronouncing "=" as "assign" or "is assigned", and "==" as
"is equal to", but it's up to you.

You must be telepathic!! I was just going to raise that very issue.
Arriving at page 95 or K&R and realizing I had been calling assigns
"equals" all along, even though understanding the difference,
nonetheless does obfuscate the meaning somewhat. I like your approach,
thanks.

I'd probably read "p=&c;" (or, preferably, "p = &c;") as "p assign
address of c" or "p is assigned the address of c", .........

I read "int *ip;" as "int star eye pee"

Thank you for that.

 

[Richard Tobin]

I would say "p equals ampersand c" (it's not an alpha).

[/QUOTE]

No no no. Djikstra (sp?) would have a fit. p gets ... or ... is
assigned to p.

Dijkstra (imagine the i-j as a ligature forming a y) might have a fit,
but the fact remains that I (and many others), when reading programs
out loud, generally use words very close to the text rather than
translating them into something arguably more correct.

In C we spell equals ==.

So, for example, I might well read that as "equals equals". Or just
as "equals". Not being a C compiler, I can tolerate inconsistency and
ambiguity.

Of course, Basic got it right: LET A = 1.

-- Richard

 

[Andrew Poelstra]

No no no. Djikstra (sp?) would have a fit. p gets ... or ... is
assigned to p.

Dijkstra (imagine the i-j as a ligature forming a y) might have a fit,
but the fact remains that I (and many others), when reading programs
out loud, generally use words very close to the text rather than
translating them into something arguably more correct.

In C we spell equals ==.

So, for example, I might well read that as "equals equals". Or just
as "equals". Not being a C compiler, I can tolerate inconsistency and
ambiguity.

Of course, Basic got it right: LET A = 1.
[/QUOTE]

That is in fact how I read C code out loud:

#include <stdio.h>
int main(void) {
char *s = "My string.";
int i = 5;

printf("%s%d", s, i);
return 0;
}

"Include STDIO dot H. Int main. Let char star s equals My String, let i
equals 5. printf percent s percent d, s i. Return zero."

And I'd usually have my finger pointing at what I'm reading on the
screen.

 

[Ben Bacarisse]

I suggest pronouncing "="

My personal preference is "gets". Short and reasonably accurate. As a
(now an ex-) CS lecturer, this cropped up all the time in various
languages.

 

[Richard]

My personal preference is "gets". Short and reasonably accurate. As a
(now an ex-) CS lecturer, this cropped up all the time in various
languages.

gets implies action on its part - almost a function call.

What is wrong with the obvious "assign 2 to x"? or "x equals 2"

"gets" is all wrong in my book.

The "=" and "==" complication that people insist in muddying up is easy.

x=2; "x equals 2"

if (x==2) ... ; "if x is equal to 2".

Note the subtle difference. And besides, 99% of people with half a clue
can differentiate between "if x equals 2" and "x equals 2".

Still, all to their own ....

 

[Joe Wright]

Lot's of questions, uh?

First things first. The = operator means "takes", not "equals". Hence

p = &c

is not p equals c. It means p takes the address of c or, in other
words, points to c. p equals c would be

p == c

As to your second question, there is an analysis in K&R that helps
understand the meaning of int*, int**, int(*) and so forth. Also,
there's a big difference from *p and p*. Read the book more careful, it
will be clarifying.

Now, concerning the expressions:

(*p)++
*p++
++*p

You should think of operator precedence. Both unary operators ++ and *
have equal precedence, so what determines the order in which they
operate is their placement among the operands. So the expression

*p++

first increments the pointer p and then derreferences it (the first
operator evaluated is ++). On the other hand, the expression

Nonsense. *p++ yields what p points to and then increments p.

++*p

first derreferences the pointer and then increments its value (in other
word, it increments the object pointed by p).

You could rewrite those expressions and get the following equivalence:

*p++ --> (p++, *p)
++*p --> *p += 1

Is that morer clear?


mdh escreveu:

Caveat Emptor.

 

[Peter Shaggy Haywood]

Groovy hepcat mdh was jivin' on 16 Oct 2006 09:10:53 -0700 in
comp.lang.c.
Pointers...once again's a cool scene! Dig it!

Starting Chapter 5 in K&R, and it does not get easier..but it is worth
it...I am repeatedly told!

K&R say that in the statement
p=&c;

"p is said to "point to c".

I know this will sound dumb, but no where does it say how the statement
is read...

Do you say "P equals alpha c" or do you read it just the way K&R say?

I usually read it in my head as, "p equals the address of c." I know
what I mean. But it's more correct to say, "let p equal the address of
c," or, "assign p the address of c." When talking to others I would
use such terms.

By the same token, how does one read this declaration?

int *ip;

I usually read it as, "int pointer ip," or, "declare int pointer
ip."

K&R simply says /*** ip is a pointer to int **/

On a slightly more deeper note ( I hope)

Quote " the unary operators * and & bind more tightly then the
arithmetic operators" so the assignment

y = *ip + 10 etc etc

Does this mean that in the above expression, using

*ip or ip* would make no difference?

Of course not. It has a completely different meaning. The + is
interpreted as a unary operator, yeilding y = ip * +10 or just y = ip
* 10.

Lastly, K&R state "unary operators like ++ and * associate right to
left.

The example they use is (*ip)++. I do not quite understand how without
the parentheses, ip would be incremented. Could anyone throw some light
on this.

++ binds more tightly than *. So *ip++ is equivalent to *(ip++).

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?

 

[Dave Thompson]

<snip> I rarely think about how to pronounce

 out loud.
But when I do, it's important to distinguish between "=" (assignment)
and "==" (equality).  It's tempting to pronounce "=" as "equals", but
it's misleading.

(IMHO, K&R shouldn't have chosen those symbols.  I think they picked
"=" for assignment because it's short, which is far less important now
than it was in the days of ASR 33 (?) teletypes.  "=" for comparison
and ":=" for assignment would have been better.  But we're stuck with
it -- forever.)
[/QUOTE]
Although 33's were still pretty common workhorses and along with other
uppercase-only (ASCII 64 IIRC) terminals were supported by a kludge, C
and Unix basically assume and expect dualcase equipment, and for years
were pretty much the only important language and OS casesensitive. If
R&T (not then K) HAD assumed 33, they might have used = for equals and
5/15 leftarrow for assignment -- which got reassigned to underscore,
and then we'd be in a pickle that would make trigraphs look good.

FWIW, APL did use single glyphs leftarrow and equals, but not in
ASCII. Most other 3GLs of the time used = for both comparison (in a
'Boolean' context like IF) and assignment (as a statement ony). As I
believe was already noted, BASIC used LET v = exp but on many if not
most implementations that keyword (only) could be omitted.
[QUOTE]
I suggest pronouncing "=" as "assign" or "is assigned", and "==" as
"is equal to", but it's up to you.
[/QUOTE]
I agree with those but I also like "gets" or "becomes".


- David.Thompson1 at worldnet.att.net