late night confusion with -> and .

[Ark Khasin]

I heard a few times, and may have repeated thoughtlessly, that p->m is
in a way a shorthand for (*p).m
The standard doesn't seem to have a notion of this; this also sounds
downright wrong if p is a pointer to a volatile type.
How common is this misconception?
--
Thanks,
Ark

[Ben Pfaff]

Ark Khasin <ak*****@macroexpressions.comwrites:

I heard a few times, and may have repeated thoughtlessly, that p->m is
in a way a shorthand for (*p).m
The standard doesn't seem to have a notion of this; this also sounds
downright wrong if p is a pointer to a volatile type.
How common is this misconception?

I certainly have this misconception.

I don't immediately see the distinction you're making. Can you
explain further?
--
Ben Pfaff
http://benpfaff.org

[Ark Khasin]

Ben Pfaff wrote:

Ark Khasin <ak*****@macroexpressions.comwrites:

>I heard a few times, and may have repeated thoughtlessly, that p->m is
in a way a shorthand for (*p).m
The standard doesn't seem to have a notion of this; this also sounds
downright wrong if p is a pointer to a volatile type.
How common is this misconception?

I certainly have this misconception.

I don't immediately see the distinction you're making. Can you
explain further?

volatile T *p;
(*p) - as in (*p).m - requires actually reading *p, which in turn may
affect the content of *p. p->m only affects the member m.
--
Ark

[Ark Khasin]

Ark Khasin wrote:

Ben Pfaff wrote:

>Ark Khasin <ak*****@macroexpressions.comwrites:

>>I heard a few times, and may have repeated thoughtlessly, that p->m is
in a way a shorthand for (*p).m
The standard doesn't seem to have a notion of this; this also sounds
downright wrong if p is a pointer to a volatile type.
How common is this misconception?

I certainly have this misconception.

I don't immediately see the distinction you're making. Can you
explain further?

volatile T *p;
(*p) - as in (*p).m - requires actually reading *p, which in turn may
affect the content of *p. p->m only affects the member m.

And now I am confused even more.
volatile struct T s;
"Natural" s.m requires evaluation (read) of s, doesn't it?
Should I write (&s)->m so as to leave other members unaffected?
--
Ark

[Peter Nilsson]

Ark Khasin <[e-mail]:

I heard a few times, and may have repeated thoughtlessly,
that p->m is in a way a shorthand for (*p).m

They are potentially distinct in C++ since one can overload
operators. But that does not apply in C.

The standard doesn't seem to have a notion of this;

The definitions of these operators seem to, at face value,
imply that relationship. There's even a non-normative
footnote that says (&E)->m is E->m if &E is valid.

this also sounds downright wrong if p is a pointer to a
volatile type.

What difference would that make?

How common is this misconception?

You've yet to demonstrate that it actually is a misconception.

--
Peter

[Ark Khasin]

Peter Nilsson wrote:

Ark Khasin <[e-mail]:

>I heard a few times, and may have repeated thoughtlessly,
that p->m is in a way a shorthand for (*p).m

They are potentially distinct in C++ since one can overload
operators. But that does not apply in C.

>The standard doesn't seem to have a notion of this;

The definitions of these operators seem to, at face value,
imply that relationship. There's even a non-normative
footnote that says (&E)->m is E->m if &E is valid.

>this also sounds downright wrong if p is a pointer to a
volatile type.

What difference would that make?

>How common is this misconception?

You've yet to demonstrate that it actually is a misconception.

--
Peter

Indeed, thank you for pointing out the Footnote 79) If &E is a valid
pointer expression (where & is the ‘‘address-of ’’ operator, which
generates a pointer to its operand), the expression (&E)->MOS is the
same as E.MOS.
I honestly don't know how to read it: an expression has a value and side
effects. No-one argues with the values part. It's the side effects that
bother me...
--
Ark

[user923005]

On Jan 21, 8:47*pm, Ark Khasin <[e-mail]:

I heard a few times, and may have repeated thoughtlessly, that p->m is
in a way a shorthand for (*p).m
The standard doesn't seem to have a notion of this; this also sounds
downright wrong if p is a pointer to a volatile type.

If you have an object, and you want to change a member, then it is:
p.m = foo;

If you have a pointer to an object, and you want to change a member,
then it is either:
p->m = foo;
Or:
(*p).m = foo;

Nobody uses the second form. Everyone uses the first form. I don't
know why it came out that way, but if you write (*p).m you will get
raised eyebrows, even though they are totally equivalent expressions.

How common is this misconception?

Really, really rare.

[Bart C]

"Ark Khasin" <ak*****@macroexpressions.comwrote in message
news:17flj.6261$YH6.4468@trndny03...

Ben Pfaff wrote:

>Ark Khasin <ak*****@macroexpressions.comwrites:

>>I heard a few times, and may have repeated thoughtlessly, that p->m is
in a way a shorthand for (*p).m
The standard doesn't seem to have a notion of this; this also sounds
downright wrong if p is a pointer to a volatile type.
How common is this misconception?

I certainly have this misconception.

I don't immediately see the distinction you're making. Can you
explain further?

volatile T *p;
(*p) - as in (*p).m - requires actually reading *p, which in turn may
affect the content of *p. p->m only affects the member m.

*p by itself may well involve reading *p, but it is followed by .m and is
also an lvalue and you may find that the internal workings of the compiler
will insert an implicit & in there which will cancel the *.

Similarly, when writing:

a=b

It clearly does not fetch the value of a. The compiler may (I'm guessing)
treat it as:

*(&a) = b

so no loading of a's value occurs, only it's address.

Bart

[Ben Pfaff]

Jack Klein <ja*******@spamcop.netwrites:

On Tue, 22 Jan 2008 04:06:36 -0800 (PST), "christian.bau"
<ch***********@cbau.wanadoo.co.ukwrote in comp.lang.c:

>In one language, an lvalue-to-rvalue conversion takes place, which
accesses *uart_receive. In the other language, no such conversion
takes place, and there is no access.

You are just plain wrong about this. In both languages the lvalue to
rvalue conversion is performed.

C does not have a conversion called an lvalue-to-rvalue
conversion. C++ does (ISO 14882:1998 clause 4.2
"Lvalue-to-rvalue conversion"). This is probably the distinction
that Christian is making.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}