Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: pointers |
| Date | 2016-10-24 12:20 -0700 |
| Organization | None to speak of |
| Message-ID | <ln60ohblkv.fsf@kst-u.example.com> (permalink) |
| References | (6 earlier) <nukp62$tfg$1@dont-email.me> <lnpompbvcj.fsf@kst-u.example.com> <nulcl7$sr1$1@dont-email.me> <lneg35bsfq.fsf@kst-u.example.com> <nulfjf$qgb$1@dont-email.me> |
BartC <bc@freeuk.com> writes:
> On 24/10/2016 17:52, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> And yes I can see this being used, even if it's just to illustrate an
>>> example like this (you'll need to imagine the spaces between &s):
>>>
>>> int **pointer;
>>>
>>> **pointer; // 3 net derefs (one is always implicit with
>>> // variables in HLLs); result: int
>>> &**pointer; // 2 net derefs; int* ( *pointer)
>>> &&**pointer; // 1 net deref; int** ( pointer)
>>> &&&**pointer; // 0 net derefs; int*** ( &pointer)
>>> &&&&**pointer; // -1 net derefs: error (&&pointer)
>>
>> So the only reason you can think of to use those constructs is to
>> illustrate them? That's hardly a good reason to add them to the
>> language.
>>
>> The unary & operator yields the address of its operand.
>
> What does that mean?
The operand must be an lvalue, which means it's an expression that
designates an object. It yields the address of that object. (Or the
operand can be a function designator, but that's not the case we're
discussing.)
> And how does it work with &**pointer?
Exactly the same way it works for any other operand, except that the
special case rule in 6.5.3.2p3 kicks in. What's the point of these
questions?
> Because **pointer would do a double dereference to get to the operand.
> Are you saying now that the & operator effectively cancels that second
> dereference?
Does the word "now" imply that I'm saying something inconsistent with
what I've said before? &**pointer is equivalent to *pointer, except
that the constraints on the operators still apply and the result is not
an lvalue.
> If so, then & is behaving just as I suggested: removing a dereference,
> while * adds one. (Rather than only giving the address of a named
> operand with no intervening * ops.)
>
> Then there is no reason why & & can't remove both dereferences.
Yes there is. The unary & operator doesn't just "remove a dereference".
It yields the address of its operand, which must be an lvalue.
> The resulting
>> expression is not an lvalue, so another unary & cannot be applied to it.
>
> Why is **pointer an lvalue but not *pointer?
Both **pointer and *pointer are lvalues. Where did you get the idea
that *pointer isn't an lvalue?
> **pointer is an an rvalue that can have & in front to yield the
> equivalent of *pointer.
>
> *pointer is an rvalue that can have & in front to yield the equivalent
> of pointer.
>
> But you can't have **pointer as an rvalue that can have & & in front to
> yield the equivalent of pointer? That is, with the first & yielding
> *pointer, and the second 'pointer'.
I don't know what you mean by "rvalue". The standard doesn't use the
term, but defines it in a footnote as the "value of an expression".
*pointer and **pointer are both lvalues (assuming they're valid).
The unary & operator requires an lvalue (or function designator, but
we'll ignore that for now) as its operand. The resulting expression is
not an lvalue. Therefore `& & pointer` is not valid; it's a constraint
violation. The special case described in N1570 6.5.3.2p3 does not
change that.
If you don't believe that, then you're wrong. If you merely don't
*like* it, then you're certainly entitled to that preference, but I have
yet to see a valid basis for it.
You seem to be inventing a principle that the unary * and & operators
should cancel each other out when combined in arbitrary ways. There is
no such principle in C.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
pointers asetofsymbols@gmail.com - 2016-10-23 08:11 -0700
Re: pointers Richard Heathfield <rjh@cpax.org.uk> - 2016-10-23 16:26 +0100
Re: pointers asetofsymbols@gmail.com - 2016-10-23 10:35 -0700
Re: pointers Ike Naar <ike@iceland.freeshell.org> - 2016-10-23 17:47 +0000
Re: pointers asetofsymbols@gmail.com - 2016-10-25 12:55 -0700
Re: pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-23 13:58 -0400
Re: pointers BartC <bc@freeuk.com> - 2016-10-24 00:55 +0100
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-23 17:27 -0700
Re: pointers BartC <bc@freeuk.com> - 2016-10-24 11:53 +0100
Re: pointers supercat@casperkitty.com - 2016-10-24 07:29 -0700
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 08:55 -0700
Re: pointers Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-24 14:02 -0700
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 14:42 -0700
Re: pointers Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-25 08:56 -0700
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 12:17 -0700
Re: pointers Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-26 06:37 -0700
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 08:49 -0700
Re: pointers BartC <bc@freeuk.com> - 2016-10-24 17:25 +0100
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 09:52 -0700
Re: pointers BartC <bc@freeuk.com> - 2016-10-24 18:15 +0100
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 12:20 -0700
Re: pointers BartC <bc@freeuk.com> - 2016-10-24 20:58 +0100
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 13:16 -0700
Re: pointers BartC <bc@freeuk.com> - 2016-10-24 23:53 +0100
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 13:38 -0700
Re: pointers BartC <bc@freeuk.com> - 2016-10-25 23:06 +0100
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 15:39 -0700
Re: pointers BartC <bc@freeuk.com> - 2016-10-26 00:26 +0100
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 16:44 -0700
Re: pointers BartC <bc@freeuk.com> - 2016-10-26 01:02 +0100
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 17:35 -0700
Re: pointers Ike Naar <ike@iceland.freeshell.org> - 2016-10-26 06:27 +0000
Re: pointers BartC <bc@freeuk.com> - 2016-10-26 12:47 +0100
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-26 09:05 -0700
Re: pointers BartC <bc@freeuk.com> - 2016-10-26 18:46 +0100
Re: pointers supercat@casperkitty.com - 2016-10-26 11:44 -0700
Re: pointers BartC <bc@freeuk.com> - 2016-10-26 20:12 +0100
Re: pointers BartC <bc@freeuk.com> - 2016-10-26 20:30 +0100
Re: pointers supercat@casperkitty.com - 2016-10-26 13:02 -0700
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-26 11:52 -0700
Re: pointers Ike Naar <ike@iceland.freeshell.org> - 2016-10-26 19:11 +0000
Re: pointers BartC <bc@freeuk.com> - 2016-10-26 21:25 +0100
Re: pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-25 18:56 -0400
Re: pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-25 19:12 -0400
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 16:31 -0700
Re: pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-24 21:36 +0100
Re: pointers BartC <bc@freeuk.com> - 2016-10-25 16:54 +0100
Re: pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-25 19:09 +0100
Re: pointers supercat@casperkitty.com - 2016-10-24 11:33 -0700
Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 12:22 -0700
Re: pointers James Kuyper <jameskuyper@verizon.net> - 2016-10-24 10:23 -0400
Re: pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-23 12:31 -0400
Re: pointers Richard Heathfield <rjh@cpax.org.uk> - 2016-10-23 17:38 +0100
Re: pointers Lorinczy Zsigmond <zsiga@nospam.for.me> - 2016-10-24 14:02 +0200
Re: pointers John Bode <jfbode1029@gmail.com> - 2016-10-24 13:34 -0700
csiph-web