Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: pointers |
| Date | 2016-10-24 21:36 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <87y41d32o2.fsf@bsb.me.uk> (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? And how does it work with &**pointer? &**pointer is like *pointer _except that it's not a lvalue_. This is exactly what Keith said but for some reason you split his remark into two so I need to repeat the point here. > Because **pointer would do a double dereference to get to the > operand. Are you saying now that the & operator effectively cancels > that second dereference? In &**pointer there is only one dereference operation. Neither the & nor the left-most * are evaluated. > 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.) You can't explain & and * in those broad terms and get all the corner cases right. The devil is in the detail. > Then there is no reason why & & can't remove both dereferences. Well no, there isn't -- it's a constraint violation so it could do anything at all. I'm not just being facetious -- I don't really know what you are asking here. Are you asking why the result of & is not an lvalue, or just why the "& cancels */[]" rule was not defined to apply to further levels. >> The resulting >> expression is not an lvalue, so another unary & cannot be applied to it. > > Why is **pointer an lvalue but not *pointer? As written, they are both lvalues, but the rules of C mean that &**pointer is not identical to *pointer -- the latter is an lvalue and the former isn't. There are other ways in which &*E is not identical to E. For example, if E has array type, &*E will have pointer type. > **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'. Yup. Could have been defined otherwise. One option that might have satisfied you is simply to extend the "& cancels * or []" rules to more levels. That makes the rule fussy for very little gain since the need for expressions of the form & &**p must be insignificant. The second option would have been to say that the result of & is an lvalue. The trouble with that is what object will it designate? In the case of & &**p there is an obvious choice, but not in & &i where i is declared int, say. -- Ben.
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