Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| Path | csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail |
|---|---|
| From | Keith Thompson <kst-u@mib.org> |
| Newsgroups | comp.lang.c |
| Subject | Re: pointers |
| Date | Tue, 25 Oct 2016 15:39:19 -0700 |
| Organization | None to speak of |
| Lines | 81 |
| Message-ID | <lnd1io8354.fsf@kst-u.example.com> (permalink) |
| References | <eddd93ef-a47b-4400-9b0b-d936ffffe329@googlegroups.com> <nuikqj$sja$2@dont-email.me> <18d7b7b9-ea72-49d3-9535-df13d560473c@googlegroups.com> <726d78eb-47b3-1b92-0203-e2f63bb740ae@verizon.net> <nujilm$4tg$1@dont-email.me> <ln7f8yd20j.fsf@kst-u.example.com> <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> <ln60ohblkv.fsf@kst-u.example.com> <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> |
| Mime-Version | 1.0 |
| Content-Type | text/plain; charset=us-ascii |
| Injection-Info | mx02.eternal-september.org; posting-host="2e7171af2bda6d09a7fcdc04643cbc45"; logging-data="10775"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX190e9STxJBuW96yhanGLq5c" |
| User-Agent | Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
| Cancel-Lock | sha1:hgwn+OiV4OwYJ5tWLBBwsjU1kv0= sha1:NWLD+pbA8wsGVJjHAx8Goxc2bew= |
| Xref | csiph.com comp.lang.c:95313 |
Show key headers only | View raw
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