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 12 of 20 — ← Prev page 1 … 10 11 [12] 13 14 … 20 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-17 00:37 -0700 |
| Message-ID | <1a9d9db0-d79c-485a-9cb4-ab1225eed73b@googlegroups.com> |
| In reply to | #92359 |
On Wednesday, August 17, 2016 at 12:12:11 AM UTC+1, supe...@casperkitty.com wrote:
> On Tuesday, August 16, 2016 at 5:46:04 PM UTC-5, Ian Collins wrote:
> > An interesting thought exercise is to image C where arrays were first
> > class objects and did not 'decay" to pointers. Would that make for a
> > better C? Maybe. Would it be a safer C? Probably.
>
> My biggest gripe is with the way that array types
> are handled as arguments. Given something like
>
> void foo(bar x);
>
> it's impossible to tell, without knowing the type of
> "bar", whether "foo" will be able to modify the "bar"
> that it receives.
>
In C++ I rarely allow a non-const reference. If a function
modifies its argument, it's passed as a pointer.
The exception is functions like
bezier.forwardsdifferencing(int N, std::vector<Point> &ret)
which tend to be called like this
std::vector<Point> pts;
for(i=0;i<N;i++)
{
path.getSegment(i).forwardsdifferencing(100, pts);
}
basically you collect a list of points in the output vector.
I find it's awkward to pass by pointer. So array arguments
don't distinguish between output and input on visual inspection,
scalar or object arguments do. Just as in C.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-16 19:12 -0400 |
| Message-ID | <b22431c5-9d47-92b1-9a06-9a4d18766fbf@verizon.net> |
| In reply to | #92356 |
On 08/16/2016 06:45 PM, Ian Collins wrote: > On 08/16/16 11:03 AM, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: ... >> You've said you find this very confusing. > > Confusing probably isn't the right word, unfortunate would be a better > choice! > > An interesting thought exercise is to image C where arrays were first > class objects and did not 'decay" to pointers. Would that make for a > better C? Maybe. Would it be a safer C? Probably. I think it would make C a slightly easier language to explain and to understand, but I think it would make it a marginally harder one to write. Making arrays first class objects would mean that passing them to a function would involve passing a copy of the array, something that's generally undesirable, at least when the array is large. Therefore, you'll generally want to pass around pointers to arrays rather than arrays themselves, and with this change, you'd have to create those pointers explicitly. The convenience of not having to write &array_name[0] is relatively minor, but as far as I can see, so are the confusions resulting from the rule that allows us to avoid doing so. BartC is very confused by that rule, but that seems to be primarily due to him deliberately avoiding learning how it works. Most programmers that are at least minimally competent that I've talked with about such issues with have generally needed only to be occasionally reminded what the rule is - it's not a big obstacle to their understanding of C.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-17 11:22 +1200 |
| Message-ID | <e1hlh0Fjbs4U2@mid.individual.net> |
| In reply to | #92360 |
On 08/17/16 11:12 AM, James R. Kuyper wrote: > On 08/16/2016 06:45 PM, Ian Collins wrote: >> On 08/16/16 11:03 AM, Keith Thompson wrote: >>> BartC <bc@freeuk.com> writes: > .... >>> You've said you find this very confusing. >> >> Confusing probably isn't the right word, unfortunate would be a better >> choice! >> >> An interesting thought exercise is to image C where arrays were first >> class objects and did not 'decay" to pointers. Would that make for a >> better C? Maybe. Would it be a safer C? Probably. > > I think it would make C a slightly easier language to explain and to > understand, but I think it would make it a marginally harder one to > write. Making arrays first class objects would mean that passing them to > a function would involve passing a copy of the array, something that's > generally undesirable, at least when the array is large. Therefore, > you'll generally want to pass around pointers to arrays rather than > arrays themselves, and with this change, you'd have to create those > pointers explicitly. I guess the thought exercise would nee to be extend to include passing by reference.... Being able to pass by reference is one of the significant differences between C and C++ although I've seldom seen it used for arrays except for function templates used to determine the size of an array. > The convenience of not having to write &array_name[0] is relatively > minor, but as far as I can see, so are the confusions resulting from the > rule that allows us to avoid doing so. BartC is very confused by that > rule, but that seems to be primarily due to him deliberately avoiding > learning how it works. Most programmers that are at least minimally > competent that I've talked with about such issues with have generally > needed only to be occasionally reminded what the rule is - it's not a > big obstacle to their understanding of C. True enough. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-17 01:23 +0100 |
| Message-ID | <np0apt$r0j$1@dont-email.me> |
| In reply to | #92360 |
On 17/08/2016 00:12, James R. Kuyper wrote:
> On 08/16/2016 06:45 PM, Ian Collins wrote:
>> On 08/16/16 11:03 AM, Keith Thompson wrote:
>>> BartC <bc@freeuk.com> writes:
> ...
>>> You've said you find this very confusing.
>>
>> Confusing probably isn't the right word, unfortunate would be a better
>> choice!
>>
>> An interesting thought exercise is to image C where arrays were first
>> class objects and did not 'decay" to pointers. Would that make for a
>> better C? Maybe. Would it be a safer C? Probably.
>
> I think it would make C a slightly easier language to explain and to
> understand, but I think it would make it a marginally harder one to
> write. Making arrays first class objects would mean that passing them to
> a function would involve passing a copy of the array, something that's
> generally undesirable,
That's hardly ever done.
at least when the array is large. Therefore,
> you'll generally want to pass around pointers to arrays rather than
> arrays themselves, and with this change, you'd have to create those
> pointers explicitly.
Often, the array pointer A has already been created. So you just pass A.
> The convenience of not having to write &array_name[0] is relatively
> minor, but as far as I can see, so are the confusions resulting from the
> rule that allows us to avoid doing so.
I put together some examples of a simple task - a function to sum the
elements of an array. There are 3 examples in C:
sum1() How it is traditionally done, passing int* for the array,
but accessing it with indexing
sum2() Passing a pointer to an array
sum3() Like sum1(), but accessing it with pointer ops.
Then I have the same 3 functions as they might appear in a language with
first-class arrays and without C's array-pointer relationship. (This is
from a real language and the syntax is rather different.)
It can't do sum1 like C, but it uses references to get a close
emulation. I don't think writing code like this is particularly onerous.
--- Examples in C ---
int sum1(int *a, int n){
int sum=0, i;
for (i=0; i<n; ++i)
sum += a[i];
return sum;
}
int sum2(int (*a)[], int n){
int sum=0, i;
for (i=0; i<n; ++i)
sum += (*a)[i];
return sum;
}
int sum3(int *a, int n){
int sum=0, i;
while (n--)
sum += *a++;
return sum;
}
int main(void)
{
int a[]={10,20,30,40,50,60,70,80,90,100};
int n=sizeof(a)/sizeof(a[0]);
printf("%d\n", sum1(a,n));
printf("%d\n", sum2(&a,n));
printf("%d\n", sum3(a,n));
}
-- Examples not in C, where pointers and arrays are distinct ---
function sum1([]int &a, int n)int= # &a means reference param
int sum:=0, i
for i to n do
sum +:= a[i]
od
return sum
end
function sum2(ref[]int a, int n)int=
int sum:=0, i
for i to n do
sum +:= a^[i]
od
return sum
end
function sum3(ref int a, int n)int=
int sum:=0, i
to n do
sum +:= a++^
od
return sum
end
proc start=
[]int a=(10,20,30,40,50,60,70,80,90,100)
println sum1(a, a.len)
println sum2(&a, a.len)
println sum3(&a[1], a.len) # &a will do as well
end
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-08-17 20:55 +0100 |
| Message-ID | <878tvvcgr5.fsf@gmail.com> |
| In reply to | #92356 |
Ian Collins <ian-news@hotmail.com> writes: > An interesting thought exercise is to image C where arrays were first > class objects and did not 'decay" to pointers. Would that make for a > better C? Maybe. Would it be a safer C? Probably. Absolutely unquestionably.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-17 17:20 -0500 |
| Message-ID | <np2nl7$47j$1@dont-email.me> |
| In reply to | #92356 |
Ian Collins wrote: > On 08/16/16 11:03 AM, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: >>> On 15/08/2016 22:50, Keith Thompson wrote: >>>> BartC <bc@freeuk.com> writes: >>>>> On 15/08/2016 21:32, Keith Thompson wrote: >>>>>> BartC <bc@freeuk.com> writes: >>>>> >>>>>>> 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. >>>>> >>>>> This is where any argument becomes futile. >>>> >>>> Ok, let's try this. Do you understand the difference between an >>>> *array object* and a *pointer object*? Leave aside for now what >>>> operations you can perform on them, and the semantics of those >>>> operations. >>>> >>>> To make it concrete, consider these two definitions. Let's say >>>> they're at file scope. >>>> >>>> int arr[10]; >>>> int *ptr; >>>> >>>> Considering them *only as objects* (regions of storage able to hold >>>> values), do you understand what they are and how they're different? >>> >>> Yes. But >> [SNIP] >> >> You've said you find this very confusing. > > Confusing probably isn't the right word, unfortunate would be a better > choice! > > An interesting thought exercise is to image C where arrays were first > class objects and did not 'decay" to pointers. Would that make for a > better C? Maybe. Would it be a safer C? Probably. > That's a really interesting idea. It'd take considerable furniture to implement. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-17 17:41 -0700 |
| Message-ID | <lnshu2kiwr.fsf@kst-u.example.com> |
| In reply to | #92356 |
Ian Collins <ian-news@hotmail.com> writes:
[...]
> An interesting thought exercise is to image C where arrays were first
> class objects and did not 'decay" to pointers. Would that make for a
> better C? Maybe. Would it be a safer C? Probably.
Arrays are difficult.
In early versions of Pascal, for example, an array of 10 integers
and an array of 20 integers were of distinct and incompatible types.
There was no way to write a function that could take an argument
of either type. I think "conformant arra parameters" were a later
addition that would let you do something like that, but as I recall
there were a bit ugly. (As you can see I'm fuzzy on the details.)
In Ada, arrays with different bounds might be of the same *type*
but of different *subtypes*. You can assign an array object to
another object, but if the bounds don't match you get a run-time
exception. A procedure or function can have a parameter of an
*unconstrained array type*, so it can accept an argument of any
bounds -- but then the bounds have to be passed implicitly by some
unspecified mechanism. (They can be accessed by using attributes,
such as Array_Name'Last.) That kind of thing has traditionally
been considered "not in the spirit of C".
If you changed C by *just* removing the array-to-pointer conversion
rule, you'd only make some operations more inconvenient without
changing much else. If you additionally permit array expressions
to be modifiable lvalues, then you can do array assignments --
but only if the LHS and RHS have the same bounds.
For arrays to be first-class objects, I'd at least want to do something
like:
int obj[10] = { ... };
some_func(obj);
and let the body of some_func be able to know the bounds of the
parameter.
I can't think of a way to add *useful* first-class arrays to C
without creating some more or less abstract type, perhaps something
similar to C++'s std::vector -- with all that that implies for
memory management. (Garbage collection is fine, but I don't think
we want to *require* GC as a prerequisite for using arrays.)
And of course all the existing mechanisms would have to remain;
otherwise we might as well be creating a new 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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-17 16:43 -0700 |
| Message-ID | <32ad9000-30af-4c01-947d-47f7ab3b9594@googlegroups.com> |
| In reply to | #92422 |
On Wednesday, August 17, 2016 at 6:15:50 PM UTC-5, Keith Thompson wrote:
> I can't think of a way to add *useful* first-class arrays to C
> without creating some more or less abstract type, perhaps something
> similar to C++'s std::vector -- with all that that implies for
> memory management. (Garbage collection is fine, but I don't think
> we want to *require* GC as a prerequisite for using arrays.)
What problems would you see with adding a syntax:
void foo(int (*)arr[int size]);
int someArray[10];
int *somePtr;
foo(someArray);
foo( [somePtr, 5] );
As for Pascal, compilers on the PC and Macintosh, and likely other
platforms as well, had ways of requesting arbitrary-sized allocations
and casting pointers to array types, or to a structure type which
contains a header plus a maximum-size array. Further, both the PC and
Macintosh allowed an object to accept an untyped "Var" parameter which
could accept the address of any object; the called function would have
to cast address to some other pointer type before use, and the caller
wouldn't get to benefit from type checking, but a caller could pass
structures with different trailing-array sizes without caller-side casts.
I'd consider that superior to the present C language; the vast majority of
implementations used to make it possible to have a function reliably accept
a pointer to any structure of the form:
struct thingie { unsigned size; THING dat[someNumber]; }
and have that function use a similar structure to work with it. While some
implementations might have had the offset of "dat" vary with its size,
most implementations had documented rules for struct layout which did not
include such wrinkles, and treated "dat[whatver]" as part of the Common
Initial Sequence even though the Standard didn't mandate it. Unfortunately,
today's compiler vendors don't feel like supporting such code even though
it was both practical and useful.
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2016-08-18 11:59 +0200 |
| Message-ID | <878tvuv1m8.fsf@news.bourguet.org> |
| In reply to | #92422 |
Keith Thompson <kst-u@mib.org> writes: > I can't think of a way to add *useful* first-class arrays to C > without creating some more or less abstract type, perhaps something > similar to C++'s std::vector -- with all that that implies for > memory management. Raw idea: - remove decay, when we'd want that, use &a[0] - allow pointers to array of unspecified dimension, obviously no pointer arithmetic on them and not usable as value, only to be dereferenced and then indexed - you could add syntaxic sugar saying that (*p)[n] can be written as p[n], p->[n] or p->n - you could remove the equivalence between p[i] and *(p+i) (you should if you have made pa[n] equivalent to (*pa)[n] as it would be confusing) - obviously passing an array by pointer would use &a - assignment and passing an array by value would demand the equality of size (just as with the current work around of making an struct whose only member is the array). You'd have mostly C with somewhat cleaner and less limited arrays and it would probably have been acceptable when C made its struct first class at the end of the 70's if compatibility had been a less important factor. Yours, -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-18 13:20 +0100 |
| Message-ID | <np4975$5oq$1@dont-email.me> |
| In reply to | #92447 |
On 18/08/2016 10:59, Jean-Marc Bourguet wrote: > Keith Thompson <kst-u@mib.org> writes: > >> I can't think of a way to add *useful* first-class arrays to C >> without creating some more or less abstract type, perhaps something >> similar to C++'s std::vector -- with all that that implies for >> memory management. > > Raw idea: > - remove decay, when we'd want that, use &a[0] > - allow pointers to array of unspecified dimension, obviously no pointer > arithmetic on them and not usable as value, only to be dereferenced and > then indexed > - you could add syntaxic sugar saying that (*p)[n] can be written as p[n], > p->[n] or p->n > - you could remove the equivalence between p[i] and *(p+i) (you should if > you have made pa[n] equivalent to (*pa)[n] as it would be confusing) > - obviously passing an array by pointer would use &a > - assignment and passing an array by value would demand the equality of > size (just as with the current work around of making an struct whose only > member is the array). > > You'd have mostly C with somewhat cleaner and less limited arrays and it > would probably have been acceptable when C made its struct first class at > the end of the 70's if compatibility had been a less important factor. Here's my similar list, although it would result in a very different language: - Array names never decay to a pointer - Arrays can be manipulated by value (but usually by pointer to the whole array), just like structs - For the address of an array, &A is needed (and &A[0] for its first element), just as is used with structs - There is no equivalence between p[i] and *(p+i) - Pointer types can't be indexed, only offset to (now it doesn't matter so much if pointer addition is commutative) - Dynamic arrays are implemented as pointers to an array type - Necessary dereference operations are always explicit - * dereference becomes a postfix op (although that makes it harder to keep '*' for this) to make dereferencing less cluttered - Then there is no longer a need for the "->" op - A simple reference attribute for function parameters can remove the need for explicit & and * ops when passing arrays One concession could be to make explicit dereferences optional, for example (using old syntax) with (*A)[i] in order to transform a pointer-to-array to array, to allow it to be indexed. (That is, pointer-to-array only; nothing else!) So A[i] would be allowed. But arrays are still value-arrays everywhere. [End of fantasy] -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-18 07:35 -0700 |
| Message-ID | <af5ce80a-1363-465e-bf71-d729edcc8ddb@googlegroups.com> |
| In reply to | #92451 |
On Thursday, August 18, 2016 at 7:21:00 AM UTC-5, Bart wrote:
> - Array names never decay to a pointer
There should be a means via which an a function can be declared as accepting
an array of indefinite size, and callers to such functions should not be
required to index an element to call such a function. C accomplishes that by
having implicit decay, but if the language had used postfix notation for
pointer dereferencing it might have been better accomplished by allowing
pointers to incomplete array types. If @ were used as address-of and ^ for
dereferencing (using something else for xor), the syntax could then be
something like:
int myFunc(int arr^[], int index)
{
return arr^[index];
}
...
int myArray[10];
...
printf("%d", myFunc(@myArray,5));
Unfortunately, C lacks any means of declaring "pointer to indeterminate
size array", and on the caller side the use of prefix rather than postfix
for dereferencing would mean that the dereferencing would either have to
be written as (*arr)[index] or index[*arr], neither of which is very
appealing.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-18 16:16 +0100 |
| Message-ID | <np4jge$9ig$1@dont-email.me> |
| In reply to | #92457 |
On 18/08/2016 15:35, supercat@casperkitty.com wrote:
> On Thursday, August 18, 2016 at 7:21:00 AM UTC-5, Bart wrote:
>> - Array names never decay to a pointer
>
> There should be a means via which an a function can be declared as accepting
> an array of indefinite size, and callers to such functions should not be
> required to index an element to call such a function. C accomplishes that by
> having implicit decay, but if the language had used postfix notation for
> pointer dereferencing it might have been better accomplished by allowing
> pointers to incomplete array types. If @ were used as address-of and ^ for
> dereferencing (using something else for xor), the syntax could then be
> something like:
>
> int myFunc(int arr^[], int index)
> {
> return arr^[index];
> }
> ...
> int myArray[10];
> ...
> printf("%d", myFunc(@myArray,5));
>
> Unfortunately, C lacks any means of declaring "pointer to indeterminate
> size array",
What's wrong with 'int(*)[]' ?
That is, 'pointer to array of int', leaving out the bounds.
> and on the caller side the use of prefix rather than postfix
> for dereferencing would mean that the dereferencing would either have to
> be written as (*arr)[index] or index[*arr], neither of which is very
> appealing.
There's not much that can be done about that. Except, some have
suggested being able to write 'P.m' instead of 'P->m' or '(*P).m'.
So maybe (*A)[i] could be written as A[i] in the same circumstances.
Except A[i] already has a handful of meanings.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-18 08:43 -0700 |
| Message-ID | <12f4178d-b6d9-4643-82ac-cb88e4315af6@googlegroups.com> |
| In reply to | #92460 |
On Thursday, August 18, 2016 at 10:16:37 AM UTC-5, Bart wrote: > On 18/08/2016 15:35, supercat wrote: > > Unfortunately, C lacks any means of declaring "pointer to indeterminate > > size array", > > What's wrong with 'int(*)[]' ? > > That is, 'pointer to array of int', leaving out the bounds. Is that acceptable outside the context of function arguments? I lose track of which things are special-cased where, in which versions of the the Standard, and which things are accepted by compilers as common extensions. Also, what does the Standard have to say about aliasing compatibility between int(*)[] and int(*)[5]? If the Standard doesn't address the subject is there any reason to believe that no "modern" compiler is going to start ignoring aliasing between such types? As for the practical usefulness of such types in C, I think the syntactical horribleness of code using such pointers is a big factor in their non-use; having a better syntax available would help. For C to complete with FORTRAN in terms of performance, it needs to add better aliasing rules for arrays (and in general, for that matter) with explicit (and preferably well-focused) means of "overriding" them when necessary.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-18 16:52 +0100 |
| Message-ID | <np4lkv$h8t$1@dont-email.me> |
| In reply to | #92464 |
On 18/08/2016 16:43, supercat@casperkitty.com wrote: > On Thursday, August 18, 2016 at 10:16:37 AM UTC-5, Bart wrote: >> On 18/08/2016 15:35, supercat wrote: >>> Unfortunately, C lacks any means of declaring "pointer to indeterminate >>> size array", >> >> What's wrong with 'int(*)[]' ? >> >> That is, 'pointer to array of int', leaving out the bounds. > > Is that acceptable outside the context of function arguments? I use that all the time with generated code, and I haven't seen a compiler complain. What you /can't/ do with a type such as: int (*A)[]; are things such as ++A or A[i]. Because it needs to know the span of the array being pointed to, and that hasn't been defined. Perhaps this can help solve the problem where, although you intend a pointer to array, the language assumes you want an array of array but just happened to define a pointer to the first element of that extraneous array using the common C idiom. But that would be impossible when the array pointed to is unbounded! So it can only be a pointer to single object. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-19 00:35 -0700 |
| Message-ID | <kfnzio9dxd5.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92324 |
Keith Thompson <kst-u@mib.org> writes: > BartC <bc@freeuk.com> writes: >> On 15/08/2016 22:50, Keith Thompson wrote: >>> BartC <bc@freeuk.com> writes: >>>> On 15/08/2016 21:32, Keith Thompson wrote: >>>>> BartC <bc@freeuk.com> writes: >>>>> >>>>>> 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. >>>> >>>> This is where any argument becomes futile. >>> >>> Ok, let's try this. Do you understand the difference between an >>> *array object* and a *pointer object*? Leave aside for now what >>> operations you can perform on them, and the semantics of those >>> operations. >>> >>> To make it concrete, consider these two definitions. Let's say >>> they're at file scope. >>> >>> int arr[10]; >>> int *ptr; >>> >>> Considering them *only as objects* (regions of storage able to hold >>> values), do you understand what they are and how they're different? >> >> Yes. But > > [SNIP] > > You've said you find this very confusing. Taking you at your word, > I'm beginning an attempt to explain it, starting with a simple and > straightforward example. If you're going to immediately, after just > one word of acknowledgement, into examples designed to confuse the > issue, examples we've all seen before, this isn't going to work. > > Are you interested in learning how arrays work in C or not? If you > are, we can continue (and I'll ask you to answer the questions I > asked with more than just "Yes"). [...] By now it should be obvious that Bart is being deliberately obtuse. It isn't that he doesn't understand or can't understand, or even that he doesn't want to understand, but he goes out of his way to actively avoid understanding. If Bart put in even one tenth as much effort at understanding C as he does looking for ways to misunderstand it he would be quite expert by now. But don't take my word for it - if anyone has the slightest doubt please take a look at his postings over the last several years and draw your own conclusions.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-19 11:22 +0100 |
| Message-ID | <np6mmf$s2r$1@dont-email.me> |
| In reply to | #92490 |
On 19/08/2016 08:35, Tim Rentsch wrote: >If Bart put in even > one tenth as much effort at understanding C as he does looking > for ways to misunderstand it C doesn't need any help in that regard. I have wondered if it was deliberately left obscure so that its practitioners could feel themselves superior to everyone else. And perhaps get paid a bit more. But then, it was created at the end of the sixties so its creators might well have been smoking something good! -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-15 13:52 -0700 |
| Message-ID | <18b15fb5-2b96-428a-ad03-75e9fd02803f@googlegroups.com> |
| In reply to | #92320 |
On Monday, August 15, 2016 at 3:32:34 PM UTC-5, Bart wrote: > No matter how I approach it, whatever I try and do with an array or a > pointer ends up converging to the same thing, yet you will persist in > saying the two are distinct! Perhaps the best way to approach the issue would be to recognize that some operations act upon lvalues, and some act upon rvalues, and that array-type lvalues and rvalues behave very differently. An array-type rvalue will behave like a pointer to the first element of the array. An array-type lvalue will behave as something completely different. Unlike most lvalues, array-type lvalues cannot be written, but like other lvalues they do have a size and an address. The Standard seems to regard use of the [] operator on an array as performing an rvalue conversion and then indexing the resulting pointer, but that would make arrays of non-character type within unions unusable for aliasing purposes.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-16 16:39 -0400 |
| Message-ID | <a5693597-af4e-1907-ad45-4f3eaecc8b10@verizon.net> |
| In reply to | #92288 |
BartC <bc@freeuk.com> writes:
...
> I've put together my new collection of C quirks here:
>
> https://github.com/bartg/langs/blob/master/C%20Quirks.md
One of the first things that web page says is:
> Arrays and pointers are the same (near enough)
Consider the following code:
#define MAX_NAME_LENGTH 32
#define NAMES 5
char arr1[][MAX_NAME_LENGTH] = {
"BartC",
"Ben Bacarisse",
"Ike Naar",
"James Russell Kuyper Jr.",
"Keith Thompson"
};
char *arr2[NAMES] = {
arr1[4]+4, arr1[3]+3, arr1[2]+2, arr1[1]+1, arr1[0]
};
char (*arr3)[MAX_NAME_LENGTH] = arr1+3;
char **arr4 = arr2+4;
Since arrays are the same as pointers, I should be free to rearrange
those declarations as follows:
char **arr1 = {
"BartC",
"Ben Bacarisse",
"Ike Naar",
"James Russell Kuyper Jr.",
"Keith Thompson"
};
char (*arr2)[MAX_NAME_LENGTH] = {
arr1[4]+4, arr1[3]+3, arr1[2]+2, arr1[1]+1, arr1[0]
};
char *arr3[NAMES] = arr1+3;
char arr4[][MAX_NAME_LENGTH] = arr2+4;
However, when I tried that, for some reason I got an error message for
every declaration, and a warning message about every initializer. Can
you explain that?
Since arrays and pointers are the same thing, then I would expect that
all four of these numbers would be the same:
printf("%zu %zu %zu %zu\n",
sizeof arr1, sizeof arr2, sizeof arr3, sizeof arr4);
For some reason, that didn't work out, either. Also, since arrays are
the same as pointers, I'd expected all three of the following lines to
be equally valid, but my compiler objects to the first two, but not
third one:
arr1 = arr2+2;
arr2 = arr2+2;
arr4 = arr2+2;
Similarly, it accepts only the last of the following three lines - but
according to you, they should all be equally valid:
arr1[0] = "odd";
arr3[0] = "odd";
arr4[0] = "odd";
Finally, I tried the following:
char works[] = "This works";
char fails[] = arr4[0];
"This works" is an array of char, arr4[0] is a char*, but since arrays
and pointers are the same, both of those definitions should be equally
acceptable. Oddly enough, the compiler accepts the first one, but
complains about the second.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-16 22:33 +0100 |
| Message-ID | <np00s2$sev$1@dont-email.me> |
| In reply to | #92345 |
On 16/08/2016 21:39, James R. Kuyper wrote:
> BartC <bc@freeuk.com> writes:
> ...
> One of the first things that web page says is:
>> Arrays and pointers are the same (near enough)
>
> Consider the following code:
>
> #define MAX_NAME_LENGTH 32
> #define NAMES 5
>
> char arr1[][MAX_NAME_LENGTH] = {
> "BartC",
> "Ben Bacarisse",
> "Ike Naar",
> "James Russell Kuyper Jr.",
> "Keith Thompson"
> };
...
> char **arr1 = {
> "BartC",
> "Ben Bacarisse",
> "Ike Naar",
> "James Russell Kuyper Jr.",
> "Keith Thompson"
> };
> char (*arr2)[MAX_NAME_LENGTH] = {
> arr1[4]+4, arr1[3]+3, arr1[2]+2, arr1[1]+1, arr1[0]
> };
> char *arr3[NAMES] = arr1+3;
> char arr4[][MAX_NAME_LENGTH] = arr2+4;
>
> However, when I tried that, for some reason I got an error message for
> every declaration, and a warning message about every initializer. Can
> you explain that?
Buried within C's type system is a half-decent treatment of arrays and
pointers. But there are limited opportunities to exploit that within
normal expression handling.
You get to see some of it at work however when declaring objects and
initialising tables (I've already said something somewhere along those
lines).
So write your two kinds of table (char[][] and char**) like this (taking
advantage of the different treatment between arrays and pointers because
it won't be there for long):
char arr1[][MAX_NAME_LENGTH] = {
"BartC",
"Ben Bacarisse",
"Ike Naar",
"James Russell Kuyper Jr.",
"Keith Thompson"
};
char* abc2[]={arr1[0],arr1[1],arr1[2],arr1[3],arr1[4]};
char **abc1 = abc2;
Now print out the first table:
for (i=0; i<NAMES; ++i) printf("%s\n", arr1[i]);
And now the second:
for (i=0; i<NAMES; ++i) printf("%s\n", abc1[i]);
What's the difference between the two other than the name of the table?
In this example, you might argue it's good to hide the implementation of
the table and be able to use the exact same access code.
But sometimes you're trying to understand the data structures by looking
at the code that uses them.
Here you can't really tell. (Apart from the first level of access being
a pointer or array, also not apparent here is the second level, as
char[] also can't be distinguished, in this code, from char*.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-16 15:32 -0700 |
| Message-ID | <eecabdde-0bd3-44ac-bffe-4f612c9531e4@googlegroups.com> |
| In reply to | #92349 |
On Tuesday, August 16, 2016 at 5:34:04 PM UTC-4, Bart wrote:
> On 16/08/2016 21:39, James R. Kuyper wrote:
> > BartC <bc@freeuk.com> writes:
> > ...
>
> > One of the first things that web page says is:
> >> Arrays and pointers are the same (near enough)
> >
> > Consider the following code:
> >
> > #define MAX_NAME_LENGTH 32
> > #define NAMES 5
> >
> > char arr1[][MAX_NAME_LENGTH] = {
> > "BartC",
> > "Ben Bacarisse",
> > "Ike Naar",
> > "James Russell Kuyper Jr.",
> > "Keith Thompson"
> > };
> ...
> > char **arr1 = {
> > "BartC",
> > "Ben Bacarisse",
> > "Ike Naar",
> > "James Russell Kuyper Jr.",
> > "Keith Thompson"
> > };
> > char (*arr2)[MAX_NAME_LENGTH] = {
> > arr1[4]+4, arr1[3]+3, arr1[2]+2, arr1[1]+1, arr1[0]
> > };
> > char *arr3[NAMES] = arr1+3;
> > char arr4[][MAX_NAME_LENGTH] = arr2+4;
> >
> > However, when I tried that, for some reason I got an error message for
> > every declaration, and a warning message about every initializer. Can
> > you explain that?
>
> Buried within C's type system is a half-decent treatment of arrays and
> pointers. But there are limited opportunities to exploit that within
> normal expression handling.
>
> You get to see some of it at work however when declaring objects and
> initialising tables (I've already said something somewhere along those
> lines).
>
> So write your two kinds of table (char[][] and char**) like this (taking
> advantage of the different treatment between arrays and pointers because
> it won't be there for long):
>
> char arr1[][MAX_NAME_LENGTH] = {
> "BartC",
> "Ben Bacarisse",
> "Ike Naar",
> "James Russell Kuyper Jr.",
> "Keith Thompson"
> };
>
> char* abc2[]={arr1[0],arr1[1],arr1[2],arr1[3],arr1[4]};
> char **abc1 = abc2;
>
> Now print out the first table:
>
> for (i=0; i<NAMES; ++i) printf("%s\n", arr1[i]);
>
> And now the second:
>
> for (i=0; i<NAMES; ++i) printf("%s\n", abc1[i]);
>
> What's the difference between the two other than the name of the table?
Virtually every single code sample you provide to justify confusing arrays and
pointers depends upon just one thing that the C standard says about arrays:
"... an expression that has type ‘‘array of type’’ is converted to an
expression with type ‘‘pointer to type’’ that points to the initial element of
the array object ..." (6.3.2.1p3)
That rule was created as a convenience. It serves two useful purposes. First of
all, it means that C only needs one set of rules for subscripting, rather than
having one set for pointer values and one for arrays. I know that you prefer
*(pointer+index) over pointer[index], but the designers of C didn't share that
preference, and neither do most of the users of C. This single simple rule is
sufficient to make subscripting work for both purposes. Secondly, without that
rule, &array_lvalue[0] would have to be a very commonplace C idiom. You might
not consider this convenience worth the trouble. But even if you don't approve
of it, you should find it much easier to cope with than you actually do. You
seem to go out of your way to avoid understanding it, and to describe the
consequences of this rule in ways that make it hard to understand it. Most C
users find this rule far easier to understand than you do.
There is a second rule that also promotes the confusion of arrays with
pointers, and that is the rule that if a function parameter is declared using
the same syntax that normally would declare an array, it is treated as a
declaration of a pointer to the element type of that array. However, this rule
seems to play a far less significant role in justifying your confusion between
arrays and pointers.
The standard says lots of other things about arrays and pointers than just
6.3.2.1p3, and virtually everything else it says about them is different in
some way between arrays and pointers, a fact you choose to ignore. Even the
array->pointer rule has three important exceptions, and one limitation. My
previous message was carefully designed to reflect all of the ways that arrays
differ from pointers. The following is a detailed explanation:
Definition of an array requires allocation of sufficient memory to store all of
the elements of that array. Definition of a pointer object allocates enough
memory to store the address of the object pointed at; whatever it points at
must be allocated separately. There's a corresponding difference in the correct
ways to initialize arrays and pointers.
In claiming that arrays and pointers are the same, you're ignoring the
exceptions listed in 6.3.2.1p3: "Except when it is the operand of the sizeof
operator, the _Alignof operator, or the unary & operator, or is a string
literal used to initialize an array, ...", and you're also ignoring a key
limitation on the resulting pointer: "... is not an lvalue.".
Because of that first exception, when the sizeof operator is applied to an
array, the result is the amount of space required to store all of the elements
of that array. When applied to a pointer object, the result is the amount of
space required to store the address of the object that it points at.
Because the pointer value that results from the conversion of an array is not
itself an lvalue, it need not reside in any location that your program can
refer to. As a result, you cannot take the address of that pointer, nor can you
assign a value to that pointer. That is the reason for the second exception
listed in 6.3.2p3; the syntax that would otherwise have given the address of
that non-existent pointer object, instead gives that address of the entire
array object. Any attempt to assign a value to that pointer is a constraint
violation.
Finally, when a string literal (an lvalue of array type) is used to initialize
an array of character type, the corresponding semantics have nothing to do with
pointers: the array is initialized by copying the elements of the the array
associated with the string literal. A pointer to such an array cannot be
substituted for a string literal in this context.
With all of these exceptions, why cling so tightly to your confusion of arrays
with pointers? Just learn the correct rule, which says that sometimes (but not
always) arrays get converted to pointer values, which is very much not the same
thing as arrays being the same as pointers.
[toc] | [prev] | [next] | [standalone]
Page 12 of 20 — ← Prev page 1 … 10 11 [12] 13 14 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web