Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: pointers Date: Mon, 24 Oct 2016 13:16:42 -0700 Organization: None to speak of Lines: 118 Message-ID: References: <18d7b7b9-ea72-49d3-9535-df13d560473c@googlegroups.com> <726d78eb-47b3-1b92-0203-e2f63bb740ae@verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="dc97ebc10d9ee65592f107439c98c97d"; logging-data="18800"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX186B36/Rwy2FLA/oWuhVezP" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:8BQcpiH8tpItIZj6nMjamKDnhlA= sha1:dsl6gjpdgCn5vfRqoJIMkELfUeA= Xref: csiph.com comp.lang.c:95242 BartC writes: > On 24/10/2016 20:20, Keith Thompson wrote: >> BartC writes: >>> On 24/10/2016 17:52, Keith Thompson wrote: >>>> BartC 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. > > But &**pointer yields the address of the int value designated by **pointer. Yes. > That address is itself stored in an object and can also be written as > *pointer. No, it's not stored in an object. Why do you think it is? > So &**pointer and *pointer yield the same value, the same type, and the > same object. Same value, yes. Same type, yes. Same object, no. *pointer is an lvalue that designates the object pointed to by `pointer`. &**pointer is not an value; evaluating it yields the address of an object, but it is not an lvalue and does not designate an object. Similarly, given: int n = 25; the expressions `n` and `25` yield the same value and the same type, but only one of them designates an object. > Why then I can only put a & in front of *pointer, but not in front of > &**pointer which is the same thing? Because *pointer is an lvalue and &**pointer is not. Are you having difficulty understanding this, believing it, or accepting it? >> &**pointer is equivalent to *pointer, > > So you agree... > > except >> that the constraints on the operators still apply and the result is not >> an lvalue. > > ... then what IS the difference between the two? Is it just the C > standard decided there ought to be a difference just for the hell of it? > >> Both **pointer and *pointer are lvalues. Where did you get the idea >> that *pointer isn't an lvalue? > > What's &**pointer then? Oh, come on, you can figure that out. >> 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. > > The trouble is, that makes sense, and leads to consistency and > orthogonality. Doing anything else doesn't. "A foolish consistency is the hobgoblin of little minds" -- Ralph Waldo Emerson. > I wouldn't be bothered so much if C insisted that & can only be followed > by the name of an object. That's a reasonable simplification especially > for 1970. Again, the operand of & must be an lvalue, an expression that (potentially) desigates an object. Restricting it to the "name of an object" (do you mean a single identifier?) would be foolish. I have no clue how 1970 is relevant. > But since C appears to allow this: > > *&*&*&*&*&*&*&*&*&*&*&*&pointer=0; > > then why not more silliness! Why more silliness? If you don't like the fact that *&*&*&*&*&*&*&*&*&*&*&*&pointer=0; is valid, what restriction would you have the language impose to ban it? Should `- - - - - - - - - - - - - - - - 42` be illegal? The operand of unary & must be an lvalue (or a function designator). The answers to most your silly questions follow from that simple rule. Finally, I would seriously appreciate an answer to the following. Exactly what problem do you have with all this? Do you (a) not believe me when I tell you what the standard actually says, or (b) not accept that the standard *means* what it says, or (c) simply dislike what the standard says? -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"