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 3 of 20 — ← Prev page 1 2 [3] 4 5 … 20 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-12 22:12 +0100 |
| Message-ID | <nole3k$rrp$1@dont-email.me> |
| In reply to | #92211 |
On 12/08/2016 21:34, supercat@casperkitty.com wrote:
> On Friday, August 12, 2016 at 3:07:51 PM UTC-5, Bart wrote:
>> On 12/08/2016 20:37, Malcolm McLean wrote:
>>> for(i=0;i<N;i++)
>>> employee[ index[i] ] ;
>>
>> That's nested indexing. Double indexing might simply be a[i][j],
>> although interestingly, my transformation into j[i[a]] turns that
into a
>> nested indexing!
>
> Hmm... so index[i][employee] or i[index][employee] would be equivalent to
> the double-indexed form? That's interesting.
>
Apparently so:
int N=8;
int employee[]={0,10,20,30,40,50,60,70};
int index[]={3,0,1,6,2,7,5,4};
int main(void)
{int i;
for (i=0; i<N; ++i)
printf("%d %d\n",employee[index[i]], i[index][employee]);
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-08-12 23:24 +0200 |
| Message-ID | <20160812232438.7ff1d5f0@maxa-pc> |
| In reply to | #92215 |
On Fri, 12 Aug 2016 22:12:12 +0100
BartC <bc@freeuk.com> wrote:
> On 12/08/2016 21:34, supercat@casperkitty.com wrote:
> > On Friday, August 12, 2016 at 3:07:51 PM UTC-5, Bart wrote:
> >> On 12/08/2016 20:37, Malcolm McLean wrote:
> >>> for(i=0;i<N;i++)
> >>> employee[ index[i] ] ;
> >>
> >> That's nested indexing. Double indexing might simply be a[i][j],
> >> although interestingly, my transformation into j[i[a]] turns
> >> that
> into a
> >> nested indexing!
> >
> > Hmm... so index[i][employee] or i[index][employee] would be
> > equivalent to the double-indexed form? That's interesting.
> >
>
> Apparently so:
>
> int N=8;
> int employee[]={0,10,20,30,40,50,60,70};
> int index[]={3,0,1,6,2,7,5,4};
>
> int main(void)
> {int i;
>
> for (i=0; i<N; ++i)
> printf("%d %d\n",employee[index[i]], i[index][employee]);
> }
>
You invented this? I never saw anything like it before....
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-13 00:59 +0100 |
| Message-ID | <87y441a697.fsf@bsb.me.uk> |
| In reply to | #92182 |
BartC <bc@freeuk.com> writes: > On 12/08/2016 01:13, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> I didn't have to look far. Posted today in Float Vs Double thread: >>> >>> On 11/08/2016 15:08, Tim Rentsch wrote: >>> >>>> #define COUNTED_ARRAY_1_( it ) (sizeof it / sizeof 0[it]), it >>> >>> ^^^^^ >> >> That does not have an index called 'a' nor an array called 'i'. It's >> quite clear what the index is in this example. >> >> Like Stefan Ram, I don't object to using [] syntax for projection >> functions, though to go beyond using a constant, I'd want the names to >> help out (component_of[vector] or some such) and I'd probably only do it >> where I was mirroring some context where that notation was already used. > > So to clarify, you don't object to using index[array]. > > Just so we know ... No, that's not clarifying, that's re-wording. I don't object to the form if the context is one in which it makes sense and the names help out. "index" and "array" are terrible names, and there is no context to asses the value of using what it a very unusual form. > In real code of course you don't always have names as apt as 'array' > and 'index'! Then it can be helpful to know, for sure, that the thing > to the left of "[" is some sort of array. > > Out of interest, I wondered what would happen if I used 2 indices. So given: > > T2 arr1[M][N]; > > This would be the 'normal' way of accessing an element: > > arr1[i][j]; > > And this is what C also allows: > > i[arr1][j]; > > But it apparently also allows this: > > j[i[arr1]]; > > I don't know about you, but even with the self-explanatory variable > names, I have trouble getting my head around this. These are all simple consequences of the fact that indexing is commutative (but not associative). If C used a symmetric binary operator it might be less alarming to you. arr1[i][j] is (arr1[i])[j] swap i and arr1 to get (i[arr1])[j]. Remove the brackets to get the first re-write above or swap the operands of the other index operation to get j[(i[arr1])] and remove the brackets to get the second re-write. Please note that because I call these simple consequences, I am not saying we should all go an use these forms. I'm saying that they are not as mysterious as you would like everyone to think they are. They follow from a fact that every C good programmer should know. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-13 11:28 +0100 |
| Message-ID | <nomsnv$ifa$1@dont-email.me> |
| In reply to | #92218 |
On 13/08/2016 00:59, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> This would be the 'normal' way of accessing an element: >> >> But it apparently also allows this: >> >> j[i[arr1]]; >> >> I don't know about you, but even with the self-explanatory variable >> names, I have trouble getting my head around this. > Please note that because I call these simple consequences, I am not > saying we should all go an use these forms. I'm saying that they are > not as mysterious as you would like everyone to think they are. They > follow from a fact that every C good programmer should know. Two here seem to have expressed surprise that you can transform two sequential index operations into two nested ones. And vice versa. So I don't think it is as completely obvious as you're making out. If I can legally write a[i][j] in another language (usually as a[i,j] though), and try and type it as j[i[a]], then I get a type error (I think, trying to use an array type as index). That is /good/. And less unnecessary stuff for a programmer to /know/ or to have to encounter. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-13 03:56 -0700 |
| Message-ID | <93a3e166-4d28-440e-880c-ef3e1735ffab@googlegroups.com> |
| In reply to | #92220 |
On Saturday, August 13, 2016 at 11:28:27 AM UTC+1, Bart wrote: > Two here seem to have expressed surprise that you can transform two > sequential index operations into two nested ones. And vice versa. > Double indexing is array [index[i] ] if you use integers. If you use pointers it is OBJECT *ptr[N]; // first index OBJECT **ptr2[N2]; // second index OBJECT ***ptr3 = &ptr2[i]; // i th entry in second index ***ptr3; // deindexing operation so nested array indexing, multiple pointers, and multi-dimensional arrays are intimately connected to each other.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-13 12:52 +0100 |
| Message-ID | <non1mj$sf$1@dont-email.me> |
| In reply to | #92221 |
On 13/08/2016 11:56, Malcolm McLean wrote:
> On Saturday, August 13, 2016 at 11:28:27 AM UTC+1, Bart wrote:
>
>> Two here seem to have expressed surprise that you can transform two
>> sequential index operations into two nested ones. And vice versa.
>>
> Double indexing is
>
> array [index[i] ]
>
> if you use integers.
>
> If you use pointers it is
>
> OBJECT *ptr[N]; // first index
> OBJECT **ptr2[N2]; // second index
> OBJECT ***ptr3 = &ptr2[i]; // i th entry in second index
>
> ***ptr3; // deindexing operation
>
> so nested array indexing, multiple pointers, and multi-dimensional
> arrays are intimately connected to each other.
I can't quite follow your example. (ptr2 and ptr3 seem to be of rank 3
while ptr is of rank 2.)
In ***ptr3, you're doing three deref operations one after another. It is
equivalent to ptr[0][0][0], which is 3 sequential index operations.
So yes pointers and arrays, derefs and indexing, are intimately
connected (to the detriment of the language IMO because then pretty much
anything goes, and a lot of it will be wrong but the language can't tell
you).
But for nested operations to also be equivalent is a little harder to
swallow. In general, a[i][j] is a 2D array: i and j select rows and columns.
But b[c[i]] is a 1D array, indexed by elements of a separate 1D array c
that could be a different size. It's quite different. Yet a[i][j] can be
transformed into j[i[a]] and mean the same thing. It's magical.
Of course it looks extraordinary IF you take the thing just before "["
to always be an array. Then j and i would be arrays. But they're not.
There is one array and two indices i and j.
So while the equivalence of a[i] and i[a] is a fun quirk, beyond one
dimension the syntax can give a seriously misleading impression of what
a bit of code represents. Given:
X[Y[Z]]
Is this a 1D array X indexed by the elements of another 1D array Y
indexed by Z?
Or is it a 2D array Z indexed by two indices X and Y?
In a sane language, even without looking at the declarations, X and Y
would be arrays and Z would be an index.
In C, this is just CRAZY. And this is disregarding all those other
things (that anything called an array could also be a value array of T,
a pointer to a sequence of T, or a pointer to an individual T).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-13 17:34 +0100 |
| Message-ID | <87r39s8w6c.fsf@bsb.me.uk> |
| In reply to | #92220 |
BartC <bc@freeuk.com> writes: > On 13/08/2016 00:59, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> This would be the 'normal' way of accessing an element: >>> > >>> But it apparently also allows this: >>> >>> j[i[arr1]]; >>> >>> I don't know about you, but even with the self-explanatory variable >>> names, I have trouble getting my head around this. > >> Please note that because I call these simple consequences, I am not >> saying we should all go an use these forms. I'm saying that they are >> not as mysterious as you would like everyone to think they are. They >> follow from a fact that every C good programmer should know. > > Two here seem to have expressed surprise that you can transform two > sequential index operations into two nested ones. And vice versa. > > So I don't think it is as completely obvious as you're making out. This is turning into a discussion about words. I never said no one would be surprised, nor did I say that it is completely obvious. People can very easily be surprised by simple consequences of rules they know, precisely because the consequences are not always completely obvious. (Look at the Monty Hall problem for example.) But *my* focus is on explaining and demystifying C. Every competent C programmer knows that writing *(p + x) is just a fussy way to write p[x]. Every C programmer should know that p + x = x + p. All it takes is a nudge in the right direction (often simply seeing it for the first time) and most C programmers will go "ah, yes". They have not really learned much that's new, but their knowledge has got a bit deeper. > If I can legally write a[i][j] in another language (usually as a[i,j] > though), and try and type it as j[i[a]], then I get a type error (I > think, trying to use an array type as index). > > That is /good/. And less unnecessary stuff for a programmer to /know/ > or to have to encounter. That may well be true in those other languages, but C has the whole array/pointer thing going on and C's rules are very simple in the context. In fact you'd *add* more to learn if A[B] were not simply *(A + B) and every C programmer needs to know what *(A+B) means even if A[B] is given it's own definition using other terms. Obviously you wold advocate for changing it all -- the pointer arithmetic, the array to pointer conversion, the definition of indexing in terms of * and + and so on. The end result might indeed be simpler than C, but that's just saying that there are other languages whose array and pointer handling is simpler than C's. Does anyone doubt that? This is the trouble with the salad bar method of language design. It's not wise to pick and choose features arbitrarily. A design relies on many decisions fitting together together to make a coherent whole. C's arrays and pointers are, in my view, coherent, despite being very different to those in other languages. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-13 09:44 -0700 |
| Message-ID | <9a91abe3-2120-4769-baaf-8a789e51b541@googlegroups.com> |
| In reply to | #92229 |
On Saturday, August 13, 2016 at 11:34:44 AM UTC-5, Ben Bacarisse wrote: > That may well be true in those other languages, but C has the whole > array/pointer thing going on and C's rules are very simple in the > context. In fact you'd *add* more to learn if A[B] were not simply *(A > + B) and every C programmer needs to know what *(A+B) means even if A[B] > is given it's own definition using other terms. Suppose one has an array "int arr[10][15]" and one wishes to read out all 150 values in a single loop. The C Standard guarantees that all 150 elements will be laid out consecutively, even on implementations where it might be faster to insert padding between the rows, and it would be silly for it to forbid that optimization if it wasn't going to allow code to exploit the layout guarantee. It's abundantly clear that "arr[0][index]" cannot be used to read anything other than the first row. It's less clear what one must do to receive an "int*" that one is guaranteed to be able to use to read out the whole array without UB. If the Standard had specified that applying the "[]" operator to an array type would *not* cause it to decay into a pointer but would instead do the indexing in a way that was only defined for elements within the array to which the [] operator was applied, then "arr[0][i]" and "*(arr[0]+i) would have usefully-distinct meanings (the former being limited to addresses within arr[0] and the latter being usable for any address within the outermost enclosing object). As it is, I think that ((int*)&arr)[i] would yield defined behavior for all values of i from 0 to 149 but I'm not sure a compiler couldn't try to "optimize" it on the assumption that "i" cannot exceed 9.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-13 18:35 +0100 |
| Message-ID | <nonlon$9t$1@dont-email.me> |
| In reply to | #92229 |
On 13/08/2016 17:34, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> So I don't think it is as completely obvious as you're making out. > > This is turning into a discussion about words. I never said no one > would be surprised, nor did I say that it is completely obvious. People > can very easily be surprised by simple consequences of rules they know, > precisely because the consequences are not always completely obvious. > (Look at the Monty Hall problem for example.) > > But *my* focus is on explaining and demystifying C. Well I thought I had it sussed out years ago, but I keep discovering new things! They tend to be bad rather than good (but the good ones I wouldn't bring up here usually). Every competent C > programmer knows that writing *(p + x) is just a fussy way to write > p[x]. Every C programmer should know that p + x = x + p. All it takes > is a nudge in the right direction (often simply seeing it for the first > time) and most C programmers will go "ah, yes". They have not really > learned much that's new, but their knowledge has got a bit deeper. Perhaps I'm not a competent programmer other than being able to write any number of tens of thousands of lines of working C code if I have to. But I /was/ astonished a few weeks ago when I found a ptr to ptr to ptr to array could be accessed by the exact same code as used for an array of ptr to ptr to ptr. And more recently by being able to transform x[x][x] into x[x[x]] with the same meaning. > This is the trouble with the salad bar method of language design. It's > not wise to pick and choose features arbitrarily. A design relies on > many decisions fitting together together to make a coherent whole. C's > arrays and pointers are, in my view, coherent, despite being very > different to those in other languages. Coherent is not what I'd call it. There are enough inconsistencies that it would make a sizeable list. (Perhaps I might do that, although it won't be as many as 100 like the list of things that I also don't like; this would be more objective.) As an example, the concept of value-arrays as things that sometimes are in the language and sometimes they aren't. (So they appear in declarations outside of parameter lists, but not in parameters lists where the value-array syntax means something else. They appear in sizeof, but elsewhere they decay to pointers. That sort of thing.) But I think the Standard does a good job of trying to tie everything together. (A job I would't like!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-13 11:21 -0700 |
| Message-ID | <7718611a-499a-433c-a90a-26d745a317b2@googlegroups.com> |
| In reply to | #92233 |
On Saturday, August 13, 2016 at 12:35:27 PM UTC-5, Bart wrote:
> But I think the Standard does a good job of trying to tie everything
> together. (A job I would't like!)
C implementations were sufficiently varied prior to C89 that it would not
have been possible to write a single Standard which simultaneously mandated
everything a compiler would need to do to be usable for all the purposes C
was being used, and yet didn't mandate anything which wouldn't be practical
to support on all implementations.
What the world needed in 1989 was a set of guidelines for things quality
implementations should do when *practical*, along with a standard
conventions via which implementations could indicate what commonly-supported
features were deemed "impratical" and thus not supported. The authors of
the Standard may not have wanted its rules treated as "guidelines", but
many compiler writers in fact treated them that way, and the Standard was
actually made more useful as a result.
Unfortunately, the general refusal to make recommendations in cases where it
couldn't issue mandates has left the Standard much less useful than it could
be. For example, given the structure [assume char=8 bits, on a system that
requires 32-bit alignment]?
typedef struct { uint32_t x; uint16_t y; uint16_t z[]; } foo;
what should sizeof (foo) or offsetof(foo, z) be? Prior to C89, there could
well have been implementations which offered flexible array members as an
extension, and where the values of above expressions would either be 6 and 6,
8 and 6, or 8 and 8, based upon how an implementation values the following
principles:
1. Nothing in the Standard would allow a structure type whose size is
not a multiple of its alignment, though the reasons for that rule would
not be applicable here.
2. The offset of y[] shouldn't vary based upon its size, or whether it has
a fixed size.
3. If a structure contains a "foo" followed by a "uint16_t[]" (C99 didn't
end up allowing such, but the construct could have been useful) then
"foo->z" should alias the latter array.
Having specified guidelines for determining the size and layout of "foo"
would have been helpful even if some compilers might treat things
differently for compatibility with other code (ideally, such compilers
would have command-line options or directives to specify whether they used
old or new behavior); it might also be useful to have a guideline that would
allow a structure with a flexible array member to be used as part of another
structure only when the offset of the FAM was equal to the structure size
(since such nesting would be very useful in those cases, but would likely
lead to bogus code in others).
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-15 12:35 +0100 |
| Message-ID | <nos9er$fr$1@dont-email.me> |
| In reply to | #92233 |
On 13/08/2016 18:35, BartC wrote: > On 13/08/2016 17:34, Ben Bacarisse wrote: >> This is the trouble with the salad bar method of language design. It's >> not wise to pick and choose features arbitrarily. A design relies on >> many decisions fitting together together to make a coherent whole. C's >> arrays and pointers are, in my view, coherent, despite being very >> different to those in other languages. > > Coherent is not what I'd call it. There are enough inconsistencies that > it would make a sizeable list. (Perhaps I might do that, although it > won't be as many as 100 like the list of things that I also don't like; > this would be more objective.) I've put together my new collection of C quirks here: https://github.com/bartg/langs/blob/master/C%20Quirks.md (Also, how those quirks are handled in my own language: https://github.com/bartg/langs/blob/master/C%20Quirks%20in%20M.md As I believe that someone making such implied criticisms should be able to demonstrate a viable alternative.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-15 15:10 +0100 |
| Message-ID | <87vaz25dj2.fsf@bsb.me.uk> |
| In reply to | #92288 |
BartC <bc@freeuk.com> writes: <snip> > I've put together my new collection of C quirks here: > > https://github.com/bartg/langs/blob/master/C%20Quirks.md Great. Could you perhaps just cite this link every time you feel the urge to moan about C? With luck, people learning C won't follow the link and be confused by the mistakes, misleading language and propaganda. C has lots of quirks, but your focus is not to help readers understand the language. Your plan seems to be to keep it a mysterious as possible by never explaining any of C rules accurately enough to demystify any of it. (I say propaganda because the document makes emphatic claims that I am almost certain you know (from past discussions here) are wrong.) <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-15 17:07 +0100 |
| Message-ID | <nospbp$qaq$1@dont-email.me> |
| In reply to | #92292 |
On 15/08/2016 15:10, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > <snip> >> I've put together my new collection of C quirks here: >> >> https://github.com/bartg/langs/blob/master/C%20Quirks.md > > Great. Could you perhaps just cite this link every time you feel the > urge to moan about C? With luck, people learning C won't follow the > link and be confused by the mistakes, misleading language and > propaganda. Actual mistakes can be pointed at. (I've now added an email link as I don't know if feedback is possible with that site.) > C has lots of quirks, but your focus is not to help readers understand > the language. Your plan seems to be to keep it a mysterious as possible > by never explaining any of C rules accurately enough to demystify > any of it. Not in this document; it's mostly for fun. Yet the examples are real, even if some are unlikely. What /were/ the language designers thinking of? Is C's type system supposed to be taken seriously or not? Use a deref and index to access some element in a data structure, instead of an index and deref (which is utterly different), and the language has nothing to say about it. Yet pass a string of unsigned char* to a function expecting a char*, and it's on top of you like a ton of bricks! You can try and explain the former behaviour as much as you like; it is still undesirable. > (I say propaganda because the document makes emphatic claims that I am > almost certain you know (from past discussions here) are wrong.) As far as I know the gist of it is correct and the examples can be tried out. None of this affects C's usefulness, since it can be used for coding despite the inconsistencies and gotchas and the terrible type synyax. (And of course I use it as a code generation target where my own compiler isolates me from the syntax issues and can do some of the type-checking that is missing.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-15 10:03 -0700 |
| Message-ID | <lntwemnewg.fsf@kst-u.example.com> |
| In reply to | #92288 |
BartC <bc@freeuk.com> writes:
> On 13/08/2016 18:35, BartC wrote:
>> On 13/08/2016 17:34, Ben Bacarisse wrote:
>>> This is the trouble with the salad bar method of language design. It's
>>> not wise to pick and choose features arbitrarily. A design relies on
>>> many decisions fitting together together to make a coherent whole. C's
>>> arrays and pointers are, in my view, coherent, despite being very
>>> different to those in other languages.
>>
>> Coherent is not what I'd call it. There are enough inconsistencies that
>> it would make a sizeable list. (Perhaps I might do that, although it
>> won't be as many as 100 like the list of things that I also don't like;
>> this would be more objective.)
>
>
> I've put together my new collection of C quirks here:
>
> https://github.com/bartg/langs/blob/master/C%20Quirks.md
I reviewed a similar list of yours a while ago via e-mail.
It appears that I wasted my time.
I just took a quick look at this new list. Your decision to invent
new notation (like "ref" for pointers and "[10]int" for int[10])
is ... well, not a choice I would have made. If you want to avoid
C's admittedly confusing declaration syntax while discussing C's
semantics, I suggest using English ("pointer to int", "array of
10 int"). The cdecl program is very helpful for this kind of thing.
You have a section titled "Value arrays". Do you think there's a
distinction between "value arrays" and some other kind of arrays?
There isn't. Among other things, I suggest the discussion would
be a lot clearer if you'd use the word "array" as an adjective,
not as a noun, and distinguish clearly among array types, array
objects, array expressions, and array values.
Your discussion of the contexts in which an array expression does or
does not decay to a pointer is far less coherent than it needs to be.
Your description seems to be deliberately confusing, and in the last
paragraph you appear to *guess* about the actual rules -- which are
really fairly simple and have been explained to you multiple times.
(Your guess is wrong, by the way; there is no exception for the
LHS of an assignment. An array on the LHS of an assignment is a
constraint violation, so the conversion rules do not even apply.)
I haven't read the rest of it, except for the title of another
section:
Arrays and pointers are the same
No, they are not. This is one of the most common and harmful
misconceptions about C. *Please please* stop propagating it.
> (Also, how those quirks are handled in my own language:
>
> https://github.com/bartg/langs/blob/master/C%20Quirks%20in%20M.md
>
> As I believe that someone making such implied criticisms should be able
> to demonstrate a viable alternative.)
(I saw no *implied* criticisms; you were quite explicit.)
If you're going to criticize C (and there's plenty to criticize),
it's not *really* necessary to invent a new language as an
alternative, but I applaud you for doing so. But you must understand
C itself. Your list, or at least the initial part that I read,
indicates that you do not.
--
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-15 17:26 +0100 |
| Message-ID | <nosqgf$uu8$1@dont-email.me> |
| In reply to | #92297 |
On 15/08/2016 18:03, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> https://github.com/bartg/langs/blob/master/C%20Quirks.md
>
> I reviewed a similar list of yours a while ago via e-mail.
> It appears that I wasted my time.
>
> I just took a quick look at this new list. Your decision to invent
> new notation (like "ref" for pointers and "[10]int" for int[10])
> is ... well, not a choice I would have made. If you want to avoid
> C's admittedly confusing declaration syntax while discussing C's
> semantics, I suggest using English ("pointer to int", "array of
> 10 int").
The notation is short-hand for the English. It should be perfectly
obvious. I avoided the English because it was too long-winded.
>The cdecl program is very helpful for this kind of thing.
Cdecl is buggy. At least the online version at cdecl.org.
Give it 'void fn(int[10])' and see what it says about the parameter's
type. Then try 'void fn(int A[10])'.
> Arrays and pointers are the same
>
> No, they are not. This is one of the most common and harmful
> misconceptions about C. *Please please* stop propagating it.
Array names decay to pointers in expressions.
An array type in a parameter list is interpreted as a pointer.
An array can be dereferenced just like a pointer.
A pointer can indexed just like an array.
If there is a difference, then it's very subtle!
> If you're going to criticize C (and there's plenty to criticize),
> it's not *really* necessary to invent a new language as an
> alternative, but I applaud you for doing so.
That language (or a crude early version) was created around 1981, before
I knew C. I was going to drop it in favour of C, but when I looked in
detail at the latter, I decided not to.
But its creation was not because of an unfavourable opinion of C; I just
needed a handy tool.
> But you must understand
> C itself. Your list, or at least the initial part that I read,
> indicates that you do not.
I understand the semantics of what I want such a low-level language to
be capable of in order to do certain things. The job of the language is
to allow that without getting in the way too much and without my having
to waste time dealing with its idiosyncrasies.
In that regard, I find mine less annoying than C.
(BTW your local time zone still seems to be ahead of everyone else's.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-15 11:42 -0700 |
| Message-ID | <lnmvkdoovn.fsf@kst-u.example.com> |
| In reply to | #92299 |
BartC <bc@freeuk.com> writes:
> On 15/08/2016 18:03, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> https://github.com/bartg/langs/blob/master/C%20Quirks.md
>>
>> I reviewed a similar list of yours a while ago via e-mail.
>> It appears that I wasted my time.
>>
>> I just took a quick look at this new list. Your decision to invent
>> new notation (like "ref" for pointers and "[10]int" for int[10])
>> is ... well, not a choice I would have made. If you want to avoid
>> C's admittedly confusing declaration syntax while discussing C's
>> semantics, I suggest using English ("pointer to int", "array of
>> 10 int").
>
> The notation is short-hand for the English. It should be perfectly
> obvious. I avoided the English because it was too long-winded.
>
>>The cdecl program is very helpful for this kind of thing.
>
> Cdecl is buggy. At least the online version at cdecl.org.
Ok, cdecl is buggy. You need to combine it with some knowledge of C
declaration syntax. I find it quite useful.
> Give it 'void fn(int[10])' and see what it says about the parameter's
> type. Then try 'void fn(int A[10])'.
>
>> Arrays and pointers are the same
>>
>> No, they are not. This is one of the most common and harmful
>> misconceptions about C. *Please please* stop propagating it.
>
> Array names decay to pointers in expressions.
>
> An array type in a parameter list is interpreted as a pointer.
>
> An array can be dereferenced just like a pointer.
>
> A pointer can indexed just like an array.
>
> If there is a difference, then it's very subtle!
No, it's not subtle at all. A pointer object contains the address of
some object or function. An array object contains a contiguous sequence
of elements, each of which is also an object.
The rules for the way array types and array expressions are treated are
moderately complicated. Your attempted description misses the point and
adds to the confusion.
>> If you're going to criticize C (and there's plenty to criticize),
>> it's not *really* necessary to invent a new language as an
>> alternative, but I applaud you for doing so.
>
> That language (or a crude early version) was created around 1981, before
> I knew C. I was going to drop it in favour of C, but when I looked in
> detail at the latter, I decided not to.
>
> But its creation was not because of an unfavourable opinion of C; I just
> needed a handy tool.
>
>> But you must understand
>> C itself. Your list, or at least the initial part that I read,
>> indicates that you do not.
>
> I understand the semantics of what I want such a low-level language to
> be capable of in order to do certain things. The job of the language is
> to allow that without getting in the way too much and without my having
> to waste time dealing with its idiosyncrasies.
>
> In that regard, I find mine less annoying than C.
Fine. But based on your attempt to describe the relationship between
C arrays and C pointers, I conclude that you do not understand C,
even after the actual rules have been carefully explained to you
multiple times. I suggest that gaining such an understanding (or
perhaps ceasing to pretend that you don't understand it) should be
a prerequisite to criticizing it.
> (BTW your local time zone still seems to be ahead of everyone else's.)
Thanks, I'll look into 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-15 19:04 +0100 |
| Message-ID | <not07u$k7g$1@dont-email.me> |
| In reply to | #92306 |
On 15/08/2016 19:42, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >>> Arrays and pointers are the same >>> >>> No, they are not. This is one of the most common and harmful >>> misconceptions about C. *Please please* stop propagating it. >> >> Array names decay to pointers in expressions. >> >> An array type in a parameter list is interpreted as a pointer. >> >> An array can be dereferenced just like a pointer. >> >> A pointer can indexed just like an array. >> >> If there is a difference, then it's very subtle! > > No, it's not subtle at all. A pointer object contains the address of > some object or function. Someone suggested in another group some time back that C didn't have arrays at all. At the time I disagreed. Now I'm wondering whether he was right all along! After all, you don't really get to see much of arrays at work. So do they even exist? The 'int a[]' syntax might just be a convenient way of defining a constant pointer to a block of storage, and to help defining tables of data (although assembly manages that without arrays). But even if they technically exist, they seem to be very lightweight and are mainly there for certain purposes, such as being able to use sizeof on, or to work out the layout of a 2D block of storage. In other words, in order to deal with dimensions of blocks. > An array object contains a contiguous sequence > of elements, each of which is also an object. What can you do with an array object, once created, that you can't do exclusively with pointers? > Fine. But based on your attempt to describe the relationship between > C arrays and C pointers, I conclude that you do not understand C, > even after the actual rules have been carefully explained to you > multiple times. I suggest that I suggest that C's treatment is more complicated than it needed to be. Anyone can understand the difference between Array and Pointer in Pascal for instance, because it's genuinely simple. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-15 12:27 -0700 |
| Message-ID | <lna8gdomrv.fsf@kst-u.example.com> |
| In reply to | #92311 |
BartC <bc@freeuk.com> writes:
> On 15/08/2016 19:42, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>>> Arrays and pointers are the same
>>>>
>>>> No, they are not. This is one of the most common and harmful
>>>> misconceptions about C. *Please please* stop propagating it.
>>>
>>> Array names decay to pointers in expressions.
>>>
>>> An array type in a parameter list is interpreted as a pointer.
>>>
>>> An array can be dereferenced just like a pointer.
>>>
>>> A pointer can indexed just like an array.
>>>
>>> If there is a difference, then it's very subtle!
>>
>> No, it's not subtle at all. A pointer object contains the address of
>> some object or function.
>
> Someone suggested in another group some time back that C didn't have
> arrays at all. At the time I disagreed. Now I'm wondering whether he was
> right all along!
That's a common misconception, but it's wrong.
> After all, you don't really get to see much of arrays at work. So do
> they even exist?
Yes.
> The 'int a[]' syntax might just be a convenient way of defining a
> constant pointer to a block of storage, and to help defining tables of
> data (although assembly manages that without arrays).
This definition:
int a[10];
when it appears at file or block scope, specifies the creation of an
array object (an object of array type), consisting of 10 elements, each
of which is an int object. It does not create a pointer object.
Come on, Bart, you should know this stuff by now.
> But even if they technically exist, they seem to be very lightweight and
> are mainly there for certain purposes, such as being able to use sizeof
> on, or to work out the layout of a 2D block of storage. In other words,
> in order to deal with dimensions of blocks.
An array object is an object. An object is a "region of data storage in
the execution environment, the contents of which can represent
values".
Similarly, an int object is an object.
The language defines a set of operations that can be performed on int
objects and values, and a different set of operations that can be
performed on array objects and values.
If you insist on describing arrays in the most confusing way possible,
then of course they're going to be confusing.
> > An array object contains a contiguous sequence
> > of elements, each of which is also an object.
>
> What can you do with an array object, once created, that you can't do
> exclusively with pointers?
You can compute its size. You can copy its contents to another object.
You can take its address (the address of an array object is distinct
from the address of one of its elements; it has a different type).
>> Fine. But based on your attempt to describe the relationship between
>> C arrays and C pointers, I conclude that you do not understand C,
>> even after the actual rules have been carefully explained to you
>> multiple times. I suggest that
>
> I suggest that C's treatment is more complicated than it needed to be.
> Anyone can understand the difference between Array and Pointer in Pascal
> for instance, because it's genuinely simple.
You don't merely suggest it, you (seemingly deliberately) overstate its
complexity and understate its consistency. And you seem to be immune to
any attempt to tell you how C *really* treats arrays and pointers.
I've answered several of your questions. I await, without much hope,
evidence that you either accept my answers and will learn from them, or
that you are able to refute them. My lack of hope is based in part on
your continuing to insist that arrays and pointers are the same, in
spite of the difference being explained to you repeatedly.
--
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-15 20:04 +0100 |
| Message-ID | <not3oh$nk$1@dont-email.me> |
| In reply to | #92312 |
On 15/08/2016 20:27, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> What can you do with an array object, once created, that you can't do >> exclusively with pointers? > > You can compute its size. You can copy its contents to another object. With memcpy? That uses pointers. > You can take its address (the address of an array object is distinct > from the address of one of its elements; it has a different type). But no one ever does. >> I suggest that C's treatment is more complicated than it needed to be. >> Anyone can understand the difference between Array and Pointer in Pascal >> for instance, because it's genuinely simple. > > You don't merely suggest it, you (seemingly deliberately) overstate its > complexity and understate its consistency. Well, I wouldn't be able to explain it in detail to anyone else. There are too many holes. There are too many things that magically happen to array names and array times. There is a huge crossover between arrays and pointers. There is no language help to stop you abusing a bare pointer as an array, or an array as pointer. Even something as universal as a[i] syntax, C can't resist meddling with by allowing i[a]. Instead of pointers to arrays of T, people almost exclusively use pointers to T, allowing more opportunities for errors. In short, it's a mess. The best I could do would be to take a conventional array/pointer type model WHERE THE TWO ARE DISTINCT, and suggest how it could be emulated in C to best of the language's ability. With the proviso that C has limited means to warn of any errors if the user gets some things mixed up. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-15 13:32 -0700 |
| Message-ID | <ln60r1ojs3.fsf@kst-u.example.com> |
| In reply to | #92316 |
BartC <bc@freeuk.com> writes:
> On 15/08/2016 20:27, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> What can you do with an array object, once created, that you can't do
>>> exclusively with pointers?
>>
>> You can compute its size. You can copy its contents to another object.
>
> With memcpy? That uses pointers.
Yes. You said "exclusively with pointers". You can't validly call
memcpy unless there's something to copy.
>> You can take its address (the address of an array object is distinct
>> from the address of one of its elements; it has a different type).
>
> But no one ever does.
Incorrect. Indexing a 2-dimensional array involves taking the address
of a row, which is an array.
>>> I suggest that C's treatment is more complicated than it needed to be.
>>> Anyone can understand the difference between Array and Pointer in Pascal
>>> for instance, because it's genuinely simple.
>>
>> You don't merely suggest it, you (seemingly deliberately) overstate its
>> complexity and understate its consistency.
>
> Well, I wouldn't be able to explain it in detail to anyone else.
I'm not convinced of that, but you certainly haven't tried.
> There
> are too many holes. There are too many things that magically happen to
> array names and array times. There is a huge crossover between arrays
> and pointers. There is no language help to stop you abusing a bare
> pointer as an array, or an array as pointer. Even something as universal
> as a[i] syntax, C can't resist meddling with by allowing i[a]. Instead
> of pointers to arrays of T, people almost exclusively use pointers to T,
> allowing more opportunities for errors.
>
> In short, it's a mess.
It is entirely consistent, though admittedly odd and sometimes
counterintuitive. Your attempts to "explain" it to others hide
that fact.
What is your goal, to make sure that everyone else is as confused as you
are? Please just stop.
> The best I could do would be to take a conventional array/pointer type
> model WHERE THE TWO ARE DISTINCT,
Arrays and pointer types are distinct.
> and suggest how it could be emulated
> in C to best of the language's ability.
No emulation is needed. That's what C does.
> With the proviso that C has
> limited means to warn of any errors if the user gets some things mixed up.
A lot of people are confused by the relationship between arrays and
pointers in C. Every time you claim that arrays and pointers are the
same thing, **you make it worse**.
--
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]
Page 3 of 20 — ← Prev page 1 2 [3] 4 5 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web