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-25 15:39 -0700 |
| Organization | None to speak of |
| Message-ID | <lnd1io8354.fsf@kst-u.example.com> (permalink) |
| References | (12 earlier) <nulp42$nqg$1@dont-email.me> <lnshrla4et.fsf@kst-u.example.com> <num3c9$jso$1@dont-email.me> <lnlgxc88q0.fsf@kst-u.example.com> <nuol16$idr$1@dont-email.me> |
BartC <bc@freeuk.com> writes:
> On 25/10/2016 21:38, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> No problem. I'm just intrigued. The language implementations I've done
>>> work differently, that's all. Here's some of the examples in my
>>> language (^ means dereference):
>> [snip]
>>
>> Um, I think your answer is (c), but it's hard to tell. Of course other
>> languages are different; that's what makes them other languages.
>
> The language I gave examples in isn't that different; it's at the same
> level as C and has to solve many of the same problems.
Can you please give a direct answer the question I asked upthread?
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?
> With the alternative approach to mixing & and *, the result is more
> expressiveness, fewer problems and more useful diagnostics (so you get a
> genuine error when the number of & or * is wrong for the type, not when
> you hit some arbitrary restriction in the language).
I see nothing arbitrary about the restrictions. & must be applied to an
lvalue, and does not yield an lvalue. * may be applied either to a
non-lvalue or to an lvalue, and yields an lvalue. (Again, ignoring
function designators.) Both of those make perfectly good sense to me,
to the extent that I didn't have to refer to the standard to write this
paragraph (though I did check it to make sure).
I see no way that relaxing those rules would improve expressiveness. I
can think of no *meaningful* expression that could be expressed with
looser rules that can't already be expressed (unless you want to add the
ability to implicitly create objects from expressions, thus allowing
things like &25).
> That C doesn't allow that expressiveness isn't a big deal as the terms
> involved can usually be rewritten into something that's legal.
Not only legal, but clearer. Given `int **ptr;`, you can't legally
write `& &*ptr`, but you can write `&ptr`.
> But it does seem rather unsatisfactory given that in other places C
> /does/ allow any number of chained * ops which do not match the type of
> the term they operate on. Example:
>
> f is a function with no associated pointers, but *f, **f, ***f are all
> legal. As is &**f. But not & &**f which ought to be equivalent of f.)
Because a function designator is implicitly converted to the address
of the function in most contexts. `& &**f` doesn't make sense,
because `&**f` is not an lvalue, so it doesn't designate anything
that has an address. My solution is simple: it would never occur
to me to write `& &**f`, so I don't have to care what it might mean.
The special-case rule that allows collapsing `&*foo` to `foo` in some
restricted circumstances is intended to cover a quite narrow use case.
You're trying to extend it to use cases that don't really mean anything.
Shall I cite Emerson again?
>>> So there do appear to be advantages to doing things the way I've suggested.
>>
>> There's no point in discussing any advantages until we understand what
>> the standard currently says.
>
> The advantage is obvious. You don't need to explain why &*p is allowed
> but not & &**p or *&p!
You're the only person I've had to explain that to. And I'm still not
sure whether you don't understand the explanation or just don't like it.
--
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