Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #92033 > unrolled thread
| Started by | eva galois <eva.galois@yandex.ru> |
|---|---|
| First post | 2016-08-09 19:37 -0400 |
| Last post | 2016-08-10 08:19 -0700 |
| Articles | 20 on this page of 387 — 27 participants |
Back to article view | Back to comp.lang.c
Difference between these pointer syntaxes eva galois <eva.galois@yandex.ru> - 2016-08-09 19:37 -0400
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-10 01:12 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-09 23:57 -0700
Re: Difference between these pointer syntaxes mark.bluemel@gmail.com - 2016-08-10 00:29 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-10 20:50 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-10 15:54 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 01:20 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-10 18:01 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 07:40 -0700
Re: Difference between these pointer syntaxes Ike Naar <ike@iceland.freeshell.org> - 2016-08-11 22:43 +0000
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 11:51 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-10 08:11 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 17:13 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-10 20:57 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 21:21 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-10 14:38 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 23:16 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-10 20:19 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 01:36 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 10:49 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 11:46 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 13:09 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 15:45 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 16:46 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 19:44 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 18:58 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-12 01:13 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-12 11:18 +0100
Re: Difference between these pointer syntaxes Ike Naar <ike@iceland.freeshell.org> - 2016-08-12 16:28 +0000
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-12 18:51 +0100
Re: Difference between these pointer syntaxes Ike Naar <ike@iceland.freeshell.org> - 2016-08-12 18:18 +0000
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-12 11:31 -0700
Re: Difference between these pointer syntaxes Ike Naar <ike@iceland.freeshell.org> - 2016-08-12 19:30 +0000
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-12 20:44 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-12 14:32 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-12 23:03 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-12 22:46 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-12 12:37 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-12 21:07 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-12 13:34 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-12 22:12 +0100
Re: Difference between these pointer syntaxes Melzzzzz <mel@zzzzz.com> - 2016-08-12 23:24 +0200
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-13 00:59 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-13 11:28 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-13 03:56 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-13 12:52 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-13 17:34 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-13 09:44 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-13 18:35 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-13 11:21 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 12:35 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-15 15:10 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 17:07 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 10:03 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 17:26 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 11:42 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 19:04 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 12:27 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 20:04 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 13:32 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 21:32 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 14:50 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 22:38 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 16:03 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 00:32 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 17:57 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 01:28 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 19:13 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 11:01 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 08:35 -0700
Re: Difference between these pointer syntaxes fir <profesor.fir@gmail.com> - 2016-08-16 07:29 -0700
Re: Difference between these pointer syntaxes already5chosen@yahoo.com - 2016-08-16 10:40 -0700
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-16 10:48 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 12:21 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-16 12:19 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 14:03 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-16 13:14 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 21:48 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-16 14:14 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 15:22 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-16 14:46 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 16:41 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 08:44 -0500
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-17 10:12 -0400
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 10:38 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 10:45 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 17:06 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 17:06 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 09:58 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 16:54 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 09:59 -0700
Re: Difference between these pointer syntaxes Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-17 19:41 +0200
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 13:03 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 11:45 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 13:10 -0700
Re: Difference between these pointer syntaxes Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-17 23:01 +0200
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-17 21:09 +0100
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 17:16 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 17:20 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 00:04 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 18:01 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 01:03 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 19:10 -0700
Re: Difference between these pointer syntaxes Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-18 11:11 +0200
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-18 09:40 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 11:25 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-18 12:51 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 13:22 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-19 00:20 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-19 17:41 -0500
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-20 00:17 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-20 13:43 -0500
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-20 21:00 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-20 16:00 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-21 00:52 +0100
Re: Difference between these pointer syntaxes fir <profesor.fir@gmail.com> - 2016-08-21 13:04 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-25 18:06 -0700
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-26 07:31 -0400
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-26 14:25 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 06:36 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-26 15:37 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 07:59 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-26 09:07 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 09:22 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-26 11:22 -0700
Re: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 11:21 -0400
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 08:37 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-26 09:46 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 09:23 -0700
Re: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 12:52 -0400
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 10:50 -0700
Re: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-26 17:46 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 10:38 -0700
Re: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 14:05 -0400
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 12:01 -0700
Re: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 15:12 -0400
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 12:48 -0700
Re: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 15:55 -0400
Re: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-26 21:02 +0100
otRe: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 16:27 -0400
Re: otRe: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-26 22:20 +0100
Re: otRe: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 15:15 -0700
Re: otRe: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-26 17:01 -0700
Re: otRe: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 16:45 -0700
Re: otRe: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 20:32 -0400
Re: otRe: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-27 03:09 +0100
Re: otRe: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 22:32 -0400
Re: otRe: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-27 04:07 +0100
Re: otRe: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-27 00:24 -0400
Re: otRe: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-27 07:03 +0100
Re: otRe: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-27 12:34 -0400
Re: otRe: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 11:46 -0700
Re: otRe: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 20:04 -0700
Re: otRe: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-27 20:25 -0700
Re: otRe: Difference between these pointer syntaxes Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-08-27 21:32 -0600
Re: otRe: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-27 20:42 -0700
Re: otRe: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 20:54 -0700
Re: otRe: Difference between these pointer syntaxes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-08-27 23:58 -0400
Re: otRe: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 22:53 -0700
Re: otRe: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 23:29 -0700
Re: otRe: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 08:21 -0700
Re: otRe: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-27 19:27 +0100
Re: otRe: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-27 14:46 -0400
Re: otRe: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-27 11:45 +0100
Re: otRe: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 04:47 -0700
Re: otRe: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-27 12:26 -0700
Re: otRe: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-27 13:06 +0100
Re: otRe: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-27 13:59 -0400
Re: otRe: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 11:52 -0700
Re: otRe: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-27 19:31 +0100
Re: otRe: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-27 13:47 -0700
Re: otRe: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-27 22:49 +0100
Re: otRe: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-27 15:07 -0700
Re: otRe: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-29 11:11 -0700
Re: otRe: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 15:57 -0700
Re: otRe: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 20:50 -0400
Re: otRe: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 20:45 -0400
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 21:18 +0100
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-27 00:20 -0400
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-27 00:27 -0400
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 17:01 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-26 19:50 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 21:30 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-26 22:11 +0100
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-26 23:42 -0400
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 21:15 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-27 11:37 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-27 10:47 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 12:20 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 12:07 -0700
Re: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-27 14:52 -0400
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-27 21:20 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 14:18 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-27 23:14 +0100
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-27 20:06 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 23:37 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-30 08:51 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 20:36 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 14:10 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-19 00:59 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-19 17:53 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-19 18:25 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-19 20:14 -0500
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 14:37 +0100
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-20 13:27 -0500
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 20:30 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-20 15:30 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-20 15:48 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 17:12 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-20 22:20 +0100
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-20 13:31 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-20 15:02 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-19 17:26 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-19 19:47 -0500
Re: Difference between these pointer syntaxes fir <profesor.fir@gmail.com> - 2016-08-16 15:09 -0700
Re: Difference between these pointer syntaxes fir <profesor.fir@gmail.com> - 2016-08-16 15:22 -0700
Re: Difference between these pointer syntaxes Ian Collins <ian-news@hotmail.com> - 2016-08-17 10:45 +1200
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 00:11 +0100
Re: Difference between these pointer syntaxes Ian Collins <ian-news@hotmail.com> - 2016-08-17 11:25 +1200
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-16 16:12 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 00:37 -0700
Re: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-16 19:12 -0400
Re: Difference between these pointer syntaxes Ian Collins <ian-news@hotmail.com> - 2016-08-17 11:22 +1200
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 01:23 +0100
Re: Difference between these pointer syntaxes Gareth Owen <gwowen@gmail.com> - 2016-08-17 20:55 +0100
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 17:20 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 17:41 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 16:43 -0700
Re: Difference between these pointer syntaxes Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-18 11:59 +0200
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 13:20 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 07:35 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 16:16 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 08:43 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 16:52 +0100
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-19 00:35 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 11:22 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-15 13:52 -0700
Re: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-16 16:39 -0400
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 22:33 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-16 15:32 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 00:00 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-16 17:45 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 10:53 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 07:44 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 08:28 -0700
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 10:16 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 15:23 -0700
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 15:33 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 17:29 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 10:52 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 20:18 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 13:16 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 21:34 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 14:45 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 23:19 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 16:03 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 16:19 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 14:09 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-17 19:51 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 20:44 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 13:33 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 21:45 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 15:37 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 23:48 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 16:25 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 18:07 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 17:07 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 17:22 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 19:14 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 19:03 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 08:23 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-01 09:55 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-09-01 12:39 -0700
Re: Difference between these pointer syntaxes Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2016-09-09 12:48 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-09-09 15:18 -0700
Re: Difference between these pointer syntaxes Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2016-09-11 09:34 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 14:55 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-05 00:05 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-09-05 01:37 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 06:31 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-05 10:51 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-09-05 14:13 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-05 16:57 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-09-06 01:21 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-05 17:31 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-06 02:12 +0100
Re: Difference between these pointer syntaxes Ike Naar <ike@iceland.freeshell.org> - 2016-09-06 06:42 +0000
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-06 01:47 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-09-06 08:28 -0700
Re: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-09-06 13:54 +0100
Re: Difference between these pointer syntaxes Gareth Owen <gwowen@gmail.com> - 2016-09-06 18:06 +0100
Re: Difference between these pointer syntaxes John Bode <jfbode1029@gmail.com> - 2016-09-08 07:09 -0700
Re: Difference between these pointer syntaxes David Brown <david.brown@hesbynett.no> - 2016-09-06 09:29 +0200
Re: Difference between these pointer syntaxes Geoff <geoff@invalid.invalid> - 2016-09-06 09:06 -0700
Re: Difference between these pointer syntaxes Gareth Owen <gwowen@gmail.com> - 2016-09-05 18:21 +0100
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 06:47 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 13:00 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 16:48 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-18 12:05 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-18 05:26 -0700
Re: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-18 13:43 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 14:05 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 00:27 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 02:59 -0700
Re: Difference between these pointer syntaxes David Brown <david.brown@hesbynett.no> - 2016-08-19 14:28 +0200
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 14:25 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 06:50 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 15:45 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 08:02 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-19 08:19 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 17:35 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-19 10:02 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 10:24 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 22:47 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 16:08 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 00:32 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 17:17 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 11:59 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-21 04:55 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-22 07:59 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 17:14 +0100
O(n log n) in place median algorithm (was: Difference between these pointer syntaxes) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 23:38 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-19 08:09 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 07:27 -0700
Re: Difference between these pointer syntaxes David Brown <david.brown@hesbynett.no> - 2016-08-18 17:40 +0200
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 10:34 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 09:49 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 13:04 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 12:05 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 13:52 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 12:51 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 14:58 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 15:36 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-18 09:14 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 09:37 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 17:58 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 16:46 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 19:03 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-18 01:55 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 11:04 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-18 23:04 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 00:10 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 01:08 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 11:04 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 12:32 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 13:45 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 14:40 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 15:30 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 15:54 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 16:24 +0100
Re: Difference between these pointer syntaxes John Bode <jfbode1029@gmail.com> - 2016-08-17 16:04 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 00:41 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 16:59 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 01:24 +0100
Re: Difference between these pointer syntaxes John Bode <jfbode1029@gmail.com> - 2016-08-18 08:30 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 10:49 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 19:20 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-18 01:39 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 10:47 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 11:03 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 11:32 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 00:28 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 12:23 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 21:19 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 03:10 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 09:47 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 08:33 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 10:12 -0700
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 10:04 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-13 09:34 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-18 08:04 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 07:51 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 15:57 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 09:04 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-11 09:17 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 19:15 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 11:41 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 20:06 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 13:42 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-11 12:38 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 20:15 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 13:37 -0700
Re: Difference between these pointer syntaxes Gareth Owen <gwowen@gmail.com> - 2016-08-11 19:54 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 12:04 +0100
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-10 11:12 -0400
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 17:27 +0100
Re: Difference between these pointer syntaxes John Bode <jfbode1029@gmail.com> - 2016-08-10 08:19 -0700
Page 6 of 20 — ← Prev page 1 … 4 5 [6] 7 8 … 20 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-17 18:01 -0700 |
| Message-ID | <lnk2feki0f.fsf@kst-u.example.com> |
| In reply to | #92421 |
BartC <bc@freeuk.com> writes:
> On 18/08/2016 01:20, Keith Thompson wrote:
>> Can you explain what
>>
>> int arr[10];
>>
>> does in terms of pointers, without references to arrays? Can you
>> explain the result of `sizeof arr`?
>
> Can you explain why C /didn't/ simply allow arrays to be evaluated? (As
> Ian suggested.)
>
> What is actually the big deal about dealing with value arrays?
>
> It seems it would have made everything much simpler all round.
I posted some thoughts on that just recently (you may not have seen the
article yet).
But since you refuse to understand how C arrays actually work, I won't
bother discussing with you how they *could* work in some C-like
language.
--
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"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-18 01:03 +0100 |
| Message-ID | <np2u0v$kv6$1@dont-email.me> |
| In reply to | #92426 |
On 18/08/2016 02:01, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 18/08/2016 01:20, Keith Thompson wrote: >>> Can you explain what >>> >>> int arr[10]; >>> >>> does in terms of pointers, without references to arrays? Can you >>> explain the result of `sizeof arr`? >> >> Can you explain why C /didn't/ simply allow arrays to be evaluated? (As >> Ian suggested.) >> >> What is actually the big deal about dealing with value arrays? >> >> It seems it would have made everything much simpler all round. > > I posted some thoughts on that just recently (you may not have seen the > article yet). > > But since you refuse to understand how C arrays actually work, I won't > bother discussing with you how they *could* work in some C-like > language. > Can you please stop treating me like a cretin. (BTW I've been designing and implementing C-like languages for 35 years.) I get how C arrays work. What I hadn't appreciated until now was the degree by which they have adversely affected the language. (I thought it was bad; it's actually worse.) Partly that was my fault for assuming that the language design was more sensible that it actually is: I implement, in C, some pointer/array structure similar to thousands I've dealt with in the past, and it works. But apparently by chance a lot of the time! Because the C has many more possibilities that are at first apparent (see my reply to John Bode). Most of those possibilities will be wrong. If they're not wrong, then they're confusing. I think what knows C better than anyone here, is my compiler than can take a problem expressed in simple, obvious terms, and write out equivalent C code for it. And using all the proper data structures for arrays too (unlike the experts!). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-17 19:10 -0700 |
| Message-ID | <ln4m6ikesj.fsf@kst-u.example.com> |
| In reply to | #92433 |
BartC <bc@freeuk.com> writes:
> On 18/08/2016 02:01, Keith Thompson wrote:
[...]
>> But since you refuse to understand how C arrays actually work, I won't
>> bother discussing with you how they *could* work in some C-like
>> language.
>
> Can you please stop treating me like a cretin. (BTW I've been designing
> and implementing C-like languages for 35 years.)
>
> I get how C arrays work. What I hadn't appreciated until now was the
> degree by which they have adversely affected the language. (I thought it
> was bad; it's actually worse.)
If you still believe that C arrays are really pointers, you don't
understand C arrays.
[...]
--
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"
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2016-08-18 11:11 +0200 |
| Message-ID | <87h9aiv3v0.fsf@news.bourguet.org> |
| In reply to | #92421 |
BartC <bc@freeuk.com> writes: > On 18/08/2016 01:20, Keith Thompson wrote: > >> Can you explain what >> >> int arr[10]; >> >> does in terms of pointers, without references to arrays? Can you >> explain the result of `sizeof arr`? > > Can you explain why C /didn't/ simply allow arrays to be evaluated? (As Ian > suggested.) Not breaking too much compatibility with previous state. C is a typed language strongly targetting byte addressable machines which evolved from an untyped one designed for word addressable machines. During that evolution, there was a time when int iarray[10]; char carray[10]; created cells dynamically initialized with a value pointing to the first of a sequence of 10 integers and characters respectively and when pointers were declared as int ipointer[]; char cpointer[]; (which is still usable for function parameters). See https://www.bell-labs.com/usr/dmr/www/chist.html for more details. Yours, -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-18 09:40 -0500 |
| Message-ID | <np4h1p$lq$1@dont-email.me> |
| In reply to | #92418 |
Keith: As usual, I've managed to crossthread c.l.c. I'll
try to mop up here and go back to lurking.
I know it's not intentional, and I mean nothing ... untoward by
it, but fairly simple concepts are being made much more complex
than they need be by this sort of discussion.
Keith Thompson wrote:
> Les Cargill <lcargill99@comcast.com> writes:
<snip>
>> because it's a perfectly workable abstraction.
>
> No, it isn't. It's an abstraction that leaves many things unexplained.
>
But that's largely the point of abstraction, really. It's not to
*withhold* information, it is to organize it a certain way, to
prioritize the ... invocation of it.
> *Maybe* you could create a set of special-case rules that could give a
> consistent model, but you'd end up with something much more complicated
> that the way the language is described in the standard. It might be
> possible to construct a consistent description of C that asserts that
> "arrays are really pointers", but I've never seen such a description.
>
there's a small set of operations in 'C' with implicit conversion
between array semantics and pointer semantics. That's really
all this is.
> Can you explain the behavior of `sizeof` while pretending that there's
> no such thing as an array? (Array type, array object, array whatever.)
>
> Can you explain what
>
> int arr[10];
>
> does in terms of pointers, without references to arrays? Can you
> explain the result of `sizeof arr`?
>
Assume an operator in the 'C' toolchain "static_allocate" such that:
// 8 bit char
char const u[] = static_allocate(168,"This happened"); // 32 bit ints
-- or --
// 32 bit ints
static const int *u = static_allocate(42,{0,1,2,3,4...});
and such that:
sizeof(u) = 168 and sizeof(&u[0]) = 4 and sizeof(*u) or sizeof(u[0]) are
1 & 4, respectively.
The usual const and static rules would control visibility and
mutability.
Then you'd never need a distinction between an array and a pointer,
excepting that when declared u[], u as-itself can never be changed
regardless - subsequent "u= ..." would be an diagnostic.
I hope ( against hope ) that this clarifies things. I'm not proposing
this as an actual extension or change; it's just one way to describe a
mental model that works.
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-18 11:25 -0700 |
| Message-ID | <lnd1l6hr2z.fsf@kst-u.example.com> |
| In reply to | #92456 |
Les Cargill <lcargill99@comcast.com> writes:
> Keith: As usual, I've managed to crossthread c.l.c. I'll
> try to mop up here and go back to lurking.
>
> I know it's not intentional, and I mean nothing ... untoward by
> it, but fairly simple concepts are being made much more complex
> than they need be by this sort of discussion.
>
> Keith Thompson wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
> <snip>
>>> because it's a perfectly workable abstraction.
>>
>> No, it isn't. It's an abstraction that leaves many things unexplained.
>>
>
> But that's largely the point of abstraction, really. It's not to
> *withhold* information, it is to organize it a certain way, to
> prioritize the ... invocation of it.
But the "arrays are really pointers" misconception is a *bad*
abstraction.
Perhaps the worst problem with it (and I blame the design of C for this)
is that you can do a lot of stuff based on the assumption that arrays
and pointers are interchangeable. But sooner or later you'll run into
things that can't be explained under that model. `sizeof array_object`
yields the size of *something*, but what exactly, if there's no such
thing as an array? If `ptr = array;` is valid, then `ptr = &array;`
is a compile-time error -- but why?
The C standard describes arrays and pointers as distinct things,
and gives a very small handful of special-case rules for when
array expressions become pointer expressions, array parameters
become pointer parameters, and the indexing operator is defined
in terms of pointer arithmetic. Everything else (array objects,
array parameters, multidimensional arrays, the weird commutativity
of the indexing operator, sizeof applied to an array object vs. an
array parameter) follows from that small set of rules.
I do not believe it is possible *or desirable* to describe the
semantics while asserting that "arrays are really just pointers".
I can imagine a set of special-case rules that would let you describe
things that way, but I believe any such set of rules would be either
inconsistent, inaccurate, or unwieldy.
[...]
> there's a small set of operations in 'C' with implicit conversion
> between array semantics and pointer semantics. That's really
> all this is.
Ah, so there's a *difference* between array semantics and pointer
semantics. So arrays and pointers aren't the same thing.
>> Can you explain the behavior of `sizeof` while pretending that there's
>> no such thing as an array? (Array type, array object, array whatever.)
>>
>> Can you explain what
>>
>> int arr[10];
>>
>> does in terms of pointers, without references to arrays? Can you
>> explain the result of `sizeof arr`?
>>
>
> Assume an operator in the 'C' toolchain "static_allocate" such that:
>
> // 8 bit char
> char const u[] = static_allocate(168,"This happened"); // 32 bit ints
>
> -- or --
>
> // 32 bit ints
> static const int *u = static_allocate(42,{0,1,2,3,4...});
>
> and such that:
>
> sizeof(u) = 168 and sizeof(&u[0]) = 4 and sizeof(*u) or sizeof(u[0]) are
> 1 & 4, respectively.
You have two different things called `u`, defined with different
types. Are they meant to be equivalent? I don't know what actual
C construct your hypothetical example is suppposed to represent
or explain.
> The usual const and static rules would control visibility and
> mutability.
>
> Then you'd never need a distinction between an array and a pointer,
> excepting that when declared u[], u as-itself can never be changed
> regardless - subsequent "u= ..." would be an diagnostic.
>
> I hope ( against hope ) that this clarifies things. I'm not proposing
> this as an actual extension or change; it's just one way to describe a
> mental model that works.
Sorry, that didn't help at all. Can you explain it in terms of the
specific example I used?
int arr[10];
If you like, assume `sizeof (int*) == 8` and `sizeof (int) == 4` to
avoid confusing element sizes and pointer sizes.
--
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"
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-18 12:51 -0500 |
| Message-ID | <np4s8n$fho$1@dont-email.me> |
| In reply to | #92472 |
Keith Thompson wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> Keith: As usual, I've managed to crossthread c.l.c. I'll
>> try to mop up here and go back to lurking.
>>
>> I know it's not intentional, and I mean nothing ... untoward by
>> it, but fairly simple concepts are being made much more complex
>> than they need be by this sort of discussion.
>>
>> Keith Thompson wrote:
>>> Les Cargill <lcargill99@comcast.com> writes:
>> <snip>
>>>> because it's a perfectly workable abstraction.
>>>
>>> No, it isn't. It's an abstraction that leaves many things unexplained.
>>>
>>
>> But that's largely the point of abstraction, really. It's not to
>> *withhold* information, it is to organize it a certain way, to
>> prioritize the ... invocation of it.
>
> But the "arrays are really pointers" misconception is a *bad*
> abstraction.
>
> Perhaps the worst problem with it (and I blame the design of C for this)
> is that you can do a lot of stuff based on the assumption that arrays
> and pointers are interchangeable. But sooner or later you'll run into
> things that can't be explained under that model. `sizeof array_object`
> yields the size of *something*, but what exactly, if there's no such
> thing as an array? If `ptr = array;` is valid, then `ptr = &array;`
> is a compile-time error -- but why?
>
But we all understand ( after a learning period ) that "sizeof()"
information is lost.
> The C standard describes arrays and pointers as distinct things,
> and gives a very small handful of special-case rules for when
> array expressions become pointer expressions, array parameters
> become pointer parameters, and the indexing operator is defined
> in terms of pointer arithmetic. Everything else (array objects,
> array parameters, multidimensional arrays, the weird commutativity
> of the indexing operator, sizeof applied to an array object vs. an
> array parameter) follows from that small set of rules.
>
> I do not believe it is possible *or desirable* to describe the
> semantics while asserting that "arrays are really just pointers".
> I can imagine a set of special-case rules that would let you describe
> things that way, but I believe any such set of rules would be either
> inconsistent, inaccurate, or unwieldy.
>
That's interesting, and I'll give it a mull.
> [...]
>
>> there's a small set of operations in 'C' with implicit conversion
>> between array semantics and pointer semantics. That's really
>> all this is.
>
> Ah, so there's a *difference* between array semantics and pointer
> semantics. So arrays and pointers aren't the same thing.
>
>>> Can you explain the behavior of `sizeof` while pretending that there's
>>> no such thing as an array? (Array type, array object, array whatever.)
>>>
>>> Can you explain what
>>>
>>> int arr[10];
>>>
>>> does in terms of pointers, without references to arrays? Can you
>>> explain the result of `sizeof arr`?
>>>
>>
>> Assume an operator in the 'C' toolchain "static_allocate" such that:
>>
>> // 8 bit char
>> char const u[] = static_allocate(168,"This happened"); // 32 bit ints
>>
>> -- or --
>>
>> // 32 bit ints
>> static const int *u = static_allocate(42,{0,1,2,3,4...});
>>
>> and such that:
>>
>> sizeof(u) = 168 and sizeof(&u[0]) = 4 and sizeof(*u) or sizeof(u[0]) are
>> 1 & 4, respectively.
>
> You have two different things called `u`, defined with different
> types. Are they meant to be equivalent? I don't know what actual
> C construct your hypothetical example is suppposed to represent
> or explain.
>
The "--- or --" divides two different scenarios - the "same" program
with two different declarations.
>> The usual const and static rules would control visibility and
>> mutability.
>>
>> Then you'd never need a distinction between an array and a pointer,
>> excepting that when declared u[], u as-itself can never be changed
>> regardless - subsequent "u= ..." would be an diagnostic.
>>
>> I hope ( against hope ) that this clarifies things. I'm not proposing
>> this as an actual extension or change; it's just one way to describe a
>> mental model that works.
>
> Sorry, that didn't help at all. Can you explain it in terms of the
> specific example I used?
>
> int arr[10];
>
Sure!
alternate declaration 1:
int arr[] = static_allocate(10,); // no initial values.
alternate declaration 2:
int *arr = static_allocate(10,); // no initial values.
The only difference then between them is that
"arr = <anything>" is a diagnostic.
> If you like, assume `sizeof (int*) == 8` and `sizeof (int) == 4` to
> avoid confusing element sizes and pointer sizes.
>
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-18 13:22 -0700 |
| Message-ID | <lnzio9hlnn.fsf@kst-u.example.com> |
| In reply to | #92475 |
Les Cargill <lcargill99@comcast.com> writes:
> Keith Thompson wrote:
[...]
>> But the "arrays are really pointers" misconception is a *bad*
>> abstraction.
>>
>> Perhaps the worst problem with it (and I blame the design of C for this)
>> is that you can do a lot of stuff based on the assumption that arrays
>> and pointers are interchangeable. But sooner or later you'll run into
>> things that can't be explained under that model. `sizeof array_object`
>> yields the size of *something*, but what exactly, if there's no such
>> thing as an array? If `ptr = array;` is valid, then `ptr = &array;`
>> is a compile-time error -- but why?
>>
>
> But we all understand ( after a learning period ) that "sizeof()"
> information is lost.
And I understand *when and why* it's lost -- but only because I
clearly distinguish between arrays and pointers.
[...]
>>>> Can you explain the behavior of `sizeof` while pretending that there's
>>>> no such thing as an array? (Array type, array object, array whatever.)
>>>>
>>>> Can you explain what
>>>>
>>>> int arr[10];
>>>>
>>>> does in terms of pointers, without references to arrays? Can you
>>>> explain the result of `sizeof arr`?
[SNIP]
>> Sorry, that didn't help at all. Can you explain it in terms of the
>> specific example I used?
>>
>> int arr[10];
>>
>
> Sure!
>
> alternate declaration 1:
>
> int arr[] = static_allocate(10,); // no initial values.
>
> alternate declaration 2:
>
> int *arr = static_allocate(10,); // no initial values.
>
> The only difference then between them is that
> "arr = <anything>" is a diagnostic.
I asked you to explain the result of `sizeof arr`. I don't see how your
static_allocate() thingie (not sure what it is) helps with that.
[...]
--
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"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-19 00:20 -0700 |
| Message-ID | <kfn4m6hfcnf.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92456 |
Les Cargill <lcargill99@comcast.com> writes:
>> [.. can arrays be dispensed with in favor of pointers ..]
>
> Assume an operator in the 'C' toolchain "static_allocate" such that:
>
> // 8 bit char
> char const u[] = static_allocate(168,"This happened"); // 32 bit ints
>
> -- or --
>
> // 32 bit ints
> static const int *u = static_allocate(42,{0,1,2,3,4...});
>
> and such that:
>
> sizeof(u) = 168 and sizeof(&u[0]) = 4 and sizeof(*u) or sizeof(u[0])
> are 1 & 4, respectively.
>
> The usual const and static rules would control visibility and
> mutability.
>
> Then you'd never need a distinction between an array and a pointer,
> excepting that when declared u[], u as-itself can never be changed
> regardless - subsequent "u= ..." would be an diagnostic.
>
> I hope ( against hope ) that this clarifies things. I'm not proposing
> this as an actual extension or change; it's just one way to describe a
> mental model that works.
The scheme described doesn't accommodate arrays as members of
structs or unions. The distinction between arrays and pointers
is fundamental and cannot be gotten rid of. Sometimes the
distinction can be ignored or glossed over, but it cannot be
gotten rid of.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-19 17:41 -0500 |
| Message-ID | <np81js$jgs$1@dont-email.me> |
| In reply to | #92489 |
Tim Rentsch wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>
>>> [.. can arrays be dispensed with in favor of pointers ..]
>>
>> Assume an operator in the 'C' toolchain "static_allocate" such that:
>>
>> // 8 bit char
>> char const u[] = static_allocate(168,"This happened"); // 32 bit ints
>>
>> -- or --
>>
>> // 32 bit ints
>> static const int *u = static_allocate(42,{0,1,2,3,4...});
>>
>> and such that:
>>
>> sizeof(u) = 168 and sizeof(&u[0]) = 4 and sizeof(*u) or sizeof(u[0])
>> are 1 & 4, respectively.
>>
>> The usual const and static rules would control visibility and
>> mutability.
>>
>> Then you'd never need a distinction between an array and a pointer,
>> excepting that when declared u[], u as-itself can never be changed
>> regardless - subsequent "u= ..." would be an diagnostic.
>>
>> I hope ( against hope ) that this clarifies things. I'm not proposing
>> this as an actual extension or change; it's just one way to describe a
>> mental model that works.
>
> The scheme described doesn't accommodate arrays as members of
> structs or unions.
That's fine - my intent was to only use it in a simplistic gedanken
about the distinctions between pointers and arrays; to try to boil all
the difference down to the use of a static_alloc() operator and the
mutability of pointers v.s the mutability of arrays.
I'm pretty sure that the mechanism breaks down for arrays within structs
and unions - you'd need some other mechanism for specifying extent, and
we'd be back to "[n]". The result would be worse than what we now have.
> The distinction between arrays and pointers
> is fundamental and cannot be gotten rid of.
Of course. I'm trying to find a (more) elegant way to describe it
than to resort to the Standard. And probably failing :)
> Sometimes the
> distinction can be ignored or glossed over, but it cannot be
> gotten rid of.
>
Nor should it be.
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-20 00:17 -0700 |
| Message-ID | <kfnmvk7ewnu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92519 |
Les Cargill <lcargill99@comcast.com> writes:
> Tim Rentsch wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>>
>>>> [.. can arrays be dispensed with in favor of pointers ..]
>>>
>>> Assume an operator in the 'C' toolchain "static_allocate" such that:
>>>
>>> // 8 bit char
>>> char const u[] = static_allocate(168,"This happened"); // 32 bit ints
>>>
>>> -- or --
>>>
>>> // 32 bit ints
>>> static const int *u = static_allocate(42,{0,1,2,3,4...});
>>>
>>> and such that:
>>>
>>> sizeof(u) = 168 and sizeof(&u[0]) = 4 and sizeof(*u) or sizeof(u[0])
>>> are 1 & 4, respectively.
>>>
>>> The usual const and static rules would control visibility and
>>> mutability.
>>>
>>> Then you'd never need a distinction between an array and a pointer,
>>> excepting that when declared u[], u as-itself can never be changed
>>> regardless - subsequent "u= ..." would be an diagnostic.
>>>
>>> I hope ( against hope ) that this clarifies things. I'm not proposing
>>> this as an actual extension or change; it's just one way to describe a
>>> mental model that works.
>>
>> The scheme described doesn't accommodate arrays as members of
>> structs or unions.
>
> That's fine - my intent was to only use it in a simplistic gedanken
> about the distinctions between pointers and arrays; to try to boil all
> the difference down to the use of a static_alloc() operator and the
> mutability of pointers v.s the mutability of arrays.
>
> I'm pretty sure that the mechanism breaks down for arrays within
> structs and unions - you'd need some other mechanism for specifying
> extent, and we'd be back to "[n]". The result would be worse than what
> we now have.
>
>> The distinction between arrays and pointers
>> is fundamental and cannot be gotten rid of.
>
> Of course. I'm trying to find a (more) elegant way to describe it
> than to resort to the Standard. [...]
Let me offer a suggestion. To discover a way of explaining
pointers and arrays that is more easily comprehensible, start
with a restricted version of C (restrictions explained below).
Explain how pointers and arrays work in the restricted subset.
After you have that explanation "working" to your satisfaction
(and also other commentators), remove the restrictions one by
one while augmenting the explanation. Repeat until there are
no restrictions and you have a full explanation.
The idea is, by introducing restrictions, you make the problem
easier to solve. Surely if you hope to explain everything
about how pointers and arrays work, it ought to be easier to
explain only some aspects and not others.
Now here are the restrictions.
1. Pointer types and array types are never allowed to stand by
themselves. A pointer or array is allowed only inside a struct,
as that struct type's only member.
2. Arrays always have exactly 1 element (ie, declarator has [1]
or equivalent).
3. Pointer types and array types are not allowed for a pointed-to
type or element type.
4. There is no indexing. Any dereferencing is done with *.
5. The 'sizeof' operator may not be performed on pointer types or
array types. (It's okay to use 'sizeof' with other types, in
particular structs.)
6. The address operator '&' is not allowed on pointer types or
array types.
7. Pointer members and array members may not be assigned. They
may be given a value as part of a declaration initializer. Or,
the containing struct may be assigned as a whole, using the
normal rules for struct assignment.
8. As usual, referring to a pointer member gives the stored value
of the pointer member, and referring to an array member gives a
(constructed) pointer value that points to the first (and only)
element of the array.
Can you concoct a simple explanation of pointers and arrays for
this highly restricted version of C (but still C, just with some
restrictions)? The description should explain both how pointers
and arrays are similar, and how they differ. I'm interested to
see what you come up with.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-20 13:43 -0500 |
| Message-ID | <npa81p$iq2$1@dont-email.me> |
| In reply to | #92533 |
Tim Rentsch wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>
>> Tim Rentsch wrote:
>>> Les Cargill <lcargill99@comcast.com> writes:
>>>
>>>>> [.. can arrays be dispensed with in favor of pointers ..]
>>>>
>>>> Assume an operator in the 'C' toolchain "static_allocate" such that:
>>>>
>>>> // 8 bit char
>>>> char const u[] = static_allocate(168,"This happened"); // 32 bit ints
>>>>
>>>> -- or --
>>>>
>>>> // 32 bit ints
>>>> static const int *u = static_allocate(42,{0,1,2,3,4...});
>>>>
>>>> and such that:
>>>>
>>>> sizeof(u) = 168 and sizeof(&u[0]) = 4 and sizeof(*u) or sizeof(u[0])
>>>> are 1 & 4, respectively.
>>>>
>>>> The usual const and static rules would control visibility and
>>>> mutability.
>>>>
>>>> Then you'd never need a distinction between an array and a pointer,
>>>> excepting that when declared u[], u as-itself can never be changed
>>>> regardless - subsequent "u= ..." would be an diagnostic.
>>>>
>>>> I hope ( against hope ) that this clarifies things. I'm not proposing
>>>> this as an actual extension or change; it's just one way to describe a
>>>> mental model that works.
>>>
>>> The scheme described doesn't accommodate arrays as members of
>>> structs or unions.
>>
>> That's fine - my intent was to only use it in a simplistic gedanken
>> about the distinctions between pointers and arrays; to try to boil all
>> the difference down to the use of a static_alloc() operator and the
>> mutability of pointers v.s the mutability of arrays.
>>
>> I'm pretty sure that the mechanism breaks down for arrays within
>> structs and unions - you'd need some other mechanism for specifying
>> extent, and we'd be back to "[n]". The result would be worse than what
>> we now have.
>>
>>> The distinction between arrays and pointers
>>> is fundamental and cannot be gotten rid of.
>>
>> Of course. I'm trying to find a (more) elegant way to describe it
>> than to resort to the Standard. [...]
>
> Let me offer a suggestion. To discover a way of explaining
> pointers and arrays that is more easily comprehensible, start
> with a restricted version of C (restrictions explained below).
> Explain how pointers and arrays work in the restricted subset.
> After you have that explanation "working" to your satisfaction
> (and also other commentators), remove the restrictions one by
> one while augmenting the explanation. Repeat until there are
> no restrictions and you have a full explanation.
>
> The idea is, by introducing restrictions, you make the problem
> easier to solve. Surely if you hope to explain everything
> about how pointers and arrays work, it ought to be easier to
> explain only some aspects and not others.
>
> Now here are the restrictions.
>
> 1. Pointer types and array types are never allowed to stand by
> themselves. A pointer or array is allowed only inside a struct,
> as that struct type's only member.
>
> 2. Arrays always have exactly 1 element (ie, declarator has [1]
> or equivalent).
>
> 3. Pointer types and array types are not allowed for a pointed-to
> type or element type.
>
> 4. There is no indexing. Any dereferencing is done with *.
>
> 5. The 'sizeof' operator may not be performed on pointer types or
> array types. (It's okay to use 'sizeof' with other types, in
> particular structs.)
>
> 6. The address operator '&' is not allowed on pointer types or
> array types.
>
> 7. Pointer members and array members may not be assigned. They
> may be given a value as part of a declaration initializer. Or,
> the containing struct may be assigned as a whole, using the
> normal rules for struct assignment.
>
> 8. As usual, referring to a pointer member gives the stored value
> of the pointer member, and referring to an array member gives a
> (constructed) pointer value that points to the first (and only)
> element of the array.
>
> Can you concoct a simple explanation of pointers and arrays for
> this highly restricted version of C (but still C, just with some
> restrictions)? The description should explain both how pointers
> and arrays are similar, and how they differ. I'm interested to
> see what you come up with.
>
I'm not sure what is gained from this set of constraints. Conceptually,
a struct in particular is sort of a "different chapter". Having multiple
elements of an array allows us to expose arrays as a vector quantity,
as opposed to a scalar.
All I am trying to do is construct a minimal explanation for the
differences between arrays and pointers, enough for people to move
forward and gain a more complete understanding later. The idea is
to cause the minimum number of "WTF?" moments later on, once ...
I dunno, mastery? , of this rule-set has been gained.
And beyond simply being instructional, it might be a construct
people can use later to debug any confusion after other concepts -
like structs - are introduced.
For a *complete* understanding, all in one chunk, the Standard's
probably just fine. The only problem with the Standard really is
having to jump around in it to glean rules.
Maybe I'm reinventing Pascal.
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-20 21:00 +0100 |
| Message-ID | <npactk$2r1$1@dont-email.me> |
| In reply to | #92546 |
On 20/08/2016 19:43, Les Cargill wrote: > Tim Rentsch wrote: > I'm not sure what is gained from this set of constraints. Conceptually, > a struct in particular is sort of a "different chapter". Having multiple > elements of an array allows us to expose arrays as a vector quantity, > as opposed to a scalar. > > All I am trying to do is construct a minimal explanation for the > differences between arrays and pointers, enough for people to move > forward and gain a more complete understanding later. You mentioned structs. Perhaps they might serve as an easier comparison with arrays as there are several points of similarity: - Arrays have N elements of the same type; so can a struct /when all members share the same type/ - Declaring a top-level array allocates space for N elements in both cases - 'sizeof' applied to an array or struct type returns the total bytes it occupies - & applied to an array or struct returns a pointer of a type that encompasses the entire array or struct Now we come to the differences: - An array name in an expression (outside the exceptions) yields a pointer to the first element: A becomes &A[0]. A struct S yields the entire struct - An array as a function parameter is interpreted as a pointer to its element type. A struct as a function parameter remains a struct - To allocate a struct of type S, the result of malloc() is assigned to a pointer-to-S, or a S* type; to allocate an array A of type T, the common idiom is to assign to a pointer-to-T type, not a pointer-to-A type. (The latter is also possible, but apparently causes confusion as it is assumed to be of the pointer-to-T pattern, so with pointer-to-A, the language, and many C experts, expect that to be part of a larger array with extra dimension. Ie. a dynamic array of A, or an array of array of T. This is unfortunate.) Interestingly, a bounded array can be wrapped up in a struct so that its behaviour changes, but it becomes more fiddly to access the elements and is generally more hassle. > For a *complete* understanding, all in one chunk, the Standard's > probably just fine. The only problem with the Standard really is > having to jump around in it to glean rules. > > Maybe I'm reinventing Pascal. I for one wouldn't object! There would certainly be a lot fewer 'WTF' moments as you put it. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-20 16:00 -0700 |
| Message-ID | <ln4m6fgi53.fsf@kst-u.example.com> |
| In reply to | #92550 |
BartC <bc@freeuk.com> writes:
[...]
> You mentioned structs. Perhaps they might serve as an easier comparison
> with arrays as there are several points of similarity:
>
> - Arrays have N elements of the same type; so can a struct /when all
> members share the same type/
>
> - Declaring a top-level array allocates space for N elements in both
> cases
>
> - 'sizeof' applied to an array or struct type returns the total bytes
> it occupies
>
> - & applied to an array or struct returns a pointer of a type that
> encompasses the entire array or struct
>
> Now we come to the differences:
>
> - An array name in an expression (outside the exceptions) yields a
> pointer to the first element: A becomes &A[0]. A struct S yields
> the entire struct
A small quibble: the same rule applies to any expression of array type,
not just an array name.
> - An array as a function parameter is interpreted as a pointer to
> its element type. A struct as a function parameter remains a struct
>
> - To allocate a struct of type S, the result of malloc() is assigned to
> a pointer-to-S, or a S* type; to allocate an array A of type T, the
> common idiom is to assign to a pointer-to-T type, not a pointer-to-A
> type.
>
> (The latter is also possible, but apparently causes confusion as it
> is assumed to be of the pointer-to-T pattern, so with pointer-to-A,
> the language, and many C experts, expect that to be part of a larger
> array with extra dimension. Ie. a dynamic array of A, or an array of
> array of T. This is unfortunate.)
>
> Interestingly, a bounded array can be wrapped up in a struct so that its
> behaviour changes, but it becomes more fiddly to access the elements and
> is generally more hassle.
Even more interestingly, that's a reasonably good summary of how
arrays and pointers actually behave in C.
So why the *hell* have you been pretending that you're so confused
by it? It seems that you've been deliberately trolling us, and I've
been trying to help someone who was only pretending to need 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"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-21 00:52 +0100 |
| Message-ID | <npaqgb$e4r$1@dont-email.me> |
| In reply to | #92553 |
On 21/08/2016 00:00, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> (The latter is also possible, but apparently causes confusion as it >> is assumed to be of the pointer-to-T pattern, so with pointer-to-A, >> the language, and many C experts, expect that to be part of a larger >> array with extra dimension. Ie. a dynamic array of A, or an array of >> array of T. This is unfortunate.) > Even more interestingly, that's a reasonably good summary of how > arrays and pointers actually behave in C. > > So why the *hell* have you been pretending that you're so confused > by it? It seems that you've been deliberately trolling us, and I've > been trying to help someone who was only pretending to need it. I think it's mainly other people who've been telling me I don't understand it, or if I did learn it all, it would magically becomes clear. My gripe is with C's array-handling scheme making things much harder than they need be, and more ambiguous. Understanding doesn't prepare you for unexpected surprises. It's usable in simple cases: one allocated array of scalars, but rapidly becomes unwieldy with more elaborate types. The stuff above I've only recently discovered: you think you've declared a pointer to X, but everything else thinks that means you want an array of X; one extra dimension! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-08-21 13:04 -0700 |
| Message-ID | <ca286be9-bb15-4a87-a387-0ec8a574589a@googlegroups.com> |
| In reply to | #92553 |
W dniu sobota, 20 sierpnia 2016 23:10:19 UTC+2 użytkownik Keith Thompson napisał: > BartC <bc@freeuk.com> writes: > [...] > > You mentioned structs. Perhaps they might serve as an easier comparison > > with arrays as there are several points of similarity: > > > > - Arrays have N elements of the same type; so can a struct /when all > > members share the same type/ > > > > - Declaring a top-level array allocates space for N elements in both > > cases > > > > - 'sizeof' applied to an array or struct type returns the total bytes > > it occupies > > > > - & applied to an array or struct returns a pointer of a type that > > encompasses the entire array or struct > > > > Now we come to the differences: > > > > - An array name in an expression (outside the exceptions) yields a > > pointer to the first element: A becomes &A[0]. A struct S yields > > the entire struct > > A small quibble: the same rule applies to any expression of array type, > not just an array name. > > > - An array as a function parameter is interpreted as a pointer to > > its element type. A struct as a function parameter remains a struct > > > > - To allocate a struct of type S, the result of malloc() is assigned to > > a pointer-to-S, or a S* type; to allocate an array A of type T, the > > common idiom is to assign to a pointer-to-T type, not a pointer-to-A > > type. > > > > (The latter is also possible, but apparently causes confusion as it > > is assumed to be of the pointer-to-T pattern, so with pointer-to-A, > > the language, and many C experts, expect that to be part of a larger > > array with extra dimension. Ie. a dynamic array of A, or an array of > > array of T. This is unfortunate.) > > > > Interestingly, a bounded array can be wrapped up in a struct so that its > > behaviour changes, but it becomes more fiddly to access the elements and > > is generally more hassle. > > Even more interestingly, that's a reasonably good summary of how > arrays and pointers actually behave in C. > > So why the *hell* have you been pretending that you're so confused > by it? It seems that you've been deliberately trolling us, and I've > been trying to help someone who was only pretending to need it. > our primitive keith in full view
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-25 18:06 -0700 |
| Message-ID | <kfnwpj4tk30.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92546 |
Les Cargill <lcargill99@comcast.com> writes:
> Tim Rentsch wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>>
>>> Tim Rentsch wrote:
>>>> Les Cargill <lcargill99@comcast.com> writes:
>>>>
>>>>>> [.. can arrays be dispensed with in favor of pointers ..]
>>>>>
>>>>> Assume an operator in the 'C' toolchain "static_allocate" such that:
>>>>>
>>>>> // 8 bit char
>>>>> char const u[] = static_allocate(168,"This happened"); // 32 bit ints
>>>>>
>>>>> -- or --
>>>>>
>>>>> // 32 bit ints
>>>>> static const int *u = static_allocate(42,{0,1,2,3,4...});
>>>>>
>>>>> and such that:
>>>>>
>>>>> sizeof(u) = 168 and sizeof(&u[0]) = 4 and sizeof(*u) or sizeof(u[0])
>>>>> are 1 & 4, respectively.
>>>>>
>>>>> The usual const and static rules would control visibility and
>>>>> mutability.
>>>>>
>>>>> Then you'd never need a distinction between an array and a pointer,
>>>>> excepting that when declared u[], u as-itself can never be changed
>>>>> regardless - subsequent "u= ..." would be an diagnostic.
>>>>>
>>>>> I hope ( against hope ) that this clarifies things. I'm not proposing
>>>>> this as an actual extension or change; it's just one way to describe a
>>>>> mental model that works.
>>>>
>>>> The scheme described doesn't accommodate arrays as members of
>>>> structs or unions.
>>>
>>> That's fine - my intent was to only use it in a simplistic gedanken
>>> about the distinctions between pointers and arrays; to try to boil all
>>> the difference down to the use of a static_alloc() operator and the
>>> mutability of pointers v.s the mutability of arrays.
>>>
>>> I'm pretty sure that the mechanism breaks down for arrays within
>>> structs and unions - you'd need some other mechanism for specifying
>>> extent, and we'd be back to "[n]". The result would be worse than what
>>> we now have.
>>>
>>>> The distinction between arrays and pointers
>>>> is fundamental and cannot be gotten rid of.
>>>
>>> Of course. I'm trying to find a (more) elegant way to describe it
>>> than to resort to the Standard. [...]
>>
>> Let me offer a suggestion. To discover a way of explaining
>> pointers and arrays that is more easily comprehensible, start
>> with a restricted version of C (restrictions explained below).
>> Explain how pointers and arrays work in the restricted subset.
>> After you have that explanation "working" to your satisfaction
>> (and also other commentators), remove the restrictions one by
>> one while augmenting the explanation. Repeat until there are
>> no restrictions and you have a full explanation.
>>
>> The idea is, by introducing restrictions, you make the problem
>> easier to solve. Surely if you hope to explain everything
>> about how pointers and arrays work, it ought to be easier to
>> explain only some aspects and not others.
>>
>> Now here are the restrictions.
>>
>> 1. Pointer types and array types are never allowed to stand by
>> themselves. A pointer or array is allowed only inside a struct,
>> as that struct type's only member.
>>
>> 2. Arrays always have exactly 1 element (ie, declarator has [1]
>> or equivalent).
>>
>> 3. Pointer types and array types are not allowed for a pointed-to
>> type or element type.
>>
>> 4. There is no indexing. Any dereferencing is done with *.
>>
>> 5. The 'sizeof' operator may not be performed on pointer types or
>> array types. (It's okay to use 'sizeof' with other types, in
>> particular structs.)
>>
>> 6. The address operator '&' is not allowed on pointer types or
>> array types.
>>
>> 7. Pointer members and array members may not be assigned. They
>> may be given a value as part of a declaration initializer. Or,
>> the containing struct may be assigned as a whole, using the
>> normal rules for struct assignment.
>>
>> 8. As usual, referring to a pointer member gives the stored value
>> of the pointer member, and referring to an array member gives a
>> (constructed) pointer value that points to the first (and only)
>> element of the array.
>>
>> Can you concoct a simple explanation of pointers and arrays for
>> this highly restricted version of C (but still C, just with some
>> restrictions)? The description should explain both how pointers
>> and arrays are similar, and how they differ. I'm interested to
>> see what you come up with.
>
> I'm not sure what is gained from this set of constraints. [...]
>
> All I am trying to do is construct a minimal explanation for the
> differences between arrays and pointers, enough for people to move
> forward and gain a more complete understanding later. [...]
What I am trying to do is help you with that construction. The
point of the restrictions is to simplify the model of what is to
be (first) explained. By analogy, it's easier to work in 2-D
than 3-D. The restrictions listed are not arbitrary: they were
chosen to remove minor semantic weirdnesses, while retaining the
essential distinguishing characteristics. For this restricted
universe of possibilities, it should be possible to give a short
_yet complete_ explanation, without having to go into any awkward
special cases (eg, sizeof, parameter types). For purposes of
education, I believe it is more helpful to have a complete
description of a /limited/ universe than an approximate, fuzzy,
or incomplete description of the /entire/ universe. By examining
a succession of limited universes, and giving in turn a complete
description for each one, we hope to bestow total confidence for
larger and larger subsets of the language, until finally there is
confidence for the whole language. The other way isn't as good.
If we give a series of partial explanations for the entire
universe (ie, language), then as time goes on the learner is less
and less sure about how things work, because a new rule may
change something they thought they knew into something different.
To say this another way, the point of limiting the universe of
discourse is to exactly define the domain in which what has been
described applies _without exception_. That is a very useful
attribute.
Of course, you may have a different take on the matter, and that
is entirely up to you. I mean only to offer a perspective, not
to try to persuade someone what they should do or want.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-26 07:31 -0400 |
| Message-ID | <npp9ao$dno$1@dont-email.me> |
| In reply to | #92546 |
On 08/20/2016 02:43 PM, Les Cargill wrote: ... > All I am trying to do is construct a minimal explanation for the > differences between arrays and pointers, enough for people to move > forward and gain a more complete understanding later. The idea is > to cause the minimum number of "WTF?" moments later on, once ... > I dunno, mastery? , of this rule-set has been gained. > > And beyond simply being instructional, it might be a construct > people can use later to debug any confusion after other concepts - > like structs - are introduced. > > For a *complete* understanding, all in one chunk, the Standard's > probably just fine. The only problem with the Standard really is > having to jump around in it to glean rules. There's one simple rule, with three simple exceptions, that is almost 100% responsible for the misconception that arrays are pointers. When that rule applies, the result of the conversion is a pointer value, NOT a pointer object. That fact, and the three exceptions, are extremely hard to make sense of if you start by pretending that arrays ARE pointers. Learning the correct rule from the beginning seems to me to be a much simpler way of understanding this.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-26 14:25 +0100 |
| Message-ID | <nppg0i$4qj$1@dont-email.me> |
| In reply to | #92717 |
On 26/08/2016 12:31, James Kuyper wrote: > On 08/20/2016 02:43 PM, Les Cargill wrote: > There's one simple rule, with three simple exceptions, that is almost > 100% responsible for the misconception that arrays are pointers. When > that rule applies, the result of the conversion is a pointer value, NOT > a pointer object. Why is that significant? > That fact, and the three exceptions, are extremely > hard to make sense of if you start by pretending that arrays ARE > pointers. Arrays aren't pointers but given A and B, one of which is an array and the other a pointer, it seems you can't tell which is which simply by looking at some code: A[i] = B[i]; Furthermore, and this is more significant, given A, B and C, one of which is an array, another a pointer to a requisite number of a objects, and the other a pointer to only one object, then you can't tell which is which here either: A[i] = B[i] = C[i]; But here, assuming i is not zero, this code will be wrong. So arrays aren't technically pointers or vice versa, but C (the language) seems to be remarkably laid back about the differences when it comes to writing executable code! As far as C is concerned, all of A, B, C could be arrays; all could be pointers to blocks; or all could be pointers to standalone objects; or they could be all mixed up. It really doesn't seem to matter. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-26 06:36 -0700 |
| Message-ID | <86fe4ec0-6dcd-4aa0-8a21-f8e57038c3bb@googlegroups.com> |
| In reply to | #92721 |
On Friday, August 26, 2016 at 2:25:47 PM UTC+1, Bart wrote: > > Furthermore, and this is more significant, given A, B and C, one of > which is an array, another a pointer to a requisite number of a objects, > and the other a pointer to only one object, then you can't tell which is > which here either: > > A[i] = B[i] = C[i]; > > But here, assuming i is not zero, this code will be wrong. > > So arrays aren't technically pointers or vice versa, but C (the > language) seems to be remarkably laid back about the differences when it > comes to writing executable code! > Arrays aren't technically arrays either. the code double B[100]; double A[100]; B[0] = 42.0; for(i=0;i<sizeof B/sizeof *B; i++) A[i] = B[i]; is wrong. it is undefined behaviour. A and B are buffers of 100 doubles, not arrays of 100 doubles. B is an array of 1 double. So we generally need to maintain N, we can't rely on sizeof() to tell us how many elements an array contains. With pointers, this is made explicit and always holds. arrays (C standard's incorrect terminology for buffers not created in dynamic memory) are often the same size as the number of elements they contain, but not always.
[toc] | [prev] | [next] | [standalone]
Page 6 of 20 — ← Prev page 1 … 4 5 [6] 7 8 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web