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 18 of 20 — ← Prev page 1 … 16 17 [18] 19 20 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-18 23:04 +0100 |
| Message-ID | <87fuq1ray7.fsf@bsb.me.uk> |
| In reply to | #92448 |
BartC <bc@freeuk.com> writes: > On 18/08/2016 01:55, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: <snip> >>> Someone declares int(*A)[] and uses it as a 1D table. >> >> (you need a size in there) > > Why? It's a pointer to an unbounded array as I don't know the size > until runtime. Are we still talking about C? How do you use it? >>> Someone else declares int(*A)[] and uses it as a 2D table. It's like >>> one of those magic books that, each time you open it, has something >>> different inside! >> >> No, it's always a 2D table. Whilst in mathematics a 2D matrix with one >> row is just called a vector, almost all programming languages (and all >> the ones I know well enough) distinguish between these cases. >> >> Thus, if you wanted to help people understand C, you'd say that int >> (*A)[N] makes a pointer into a 2D array. Even more simply, it's a >> pointer to the first (and maybe only) element of the pointer's type. >> This happens to be an array type which is why the access is 2D even if >> there is only one row in the 2D structure. >> >> I am sure that a lot of people *don't* think of it this way, and they >> manage fine with their own explanations of all this, > > You don't think there is something wrong with a language when people > are even having a debate on how many dimensions a declaration > represents?! Or has a array-pointer model so complex that people have > to develop their own personal philosophies to cope with it? Oh dear. Can you cite *anyone* saying that there is no problem with C? But despite arguing against something no one has every said (to my knowledge) your argument is still a terrible one. Pop over to sci.math to see endless arguments about the validity of sound, thoroughly well-examined theorems. I can't think of anything less open to debate that a simple mathematical theorem, but that does not stop people on Usenet. So, no, I don't think the presence of a dispute *here* to be indicative of anything at all. But note also that you are not helping. You have added to the world yet another document containing statements like "arrays and pointer are the same". That will help fuel the confusion for another generation. > This stuff could be completely open and completely obvious. There > should be no ambiguity. No, it could not be, at least not without costs and potential benefits that I don't think you have any handle on (I certainly don't). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-19 00:10 +0100 |
| Message-ID | <np5f8v$k1b$1@dont-email.me> |
| In reply to | #92483 |
On 18/08/2016 23:04, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 18/08/2016 01:55, Ben Bacarisse wrote:
>>> BartC <bc@freeuk.com> writes:
> <snip>
>>>> Someone declares int(*A)[] and uses it as a 1D table.
>>>
>>> (you need a size in there)
>>
>> Why? It's a pointer to an unbounded array as I don't know the size
>> until runtime.
>
> Are we still talking about C? How do you use it?
int main(void){
int (*A)[]; // pointer to (unbounded) array of int
#define N 1000
int i;
A = malloc(N*sizeof(int));
for (i=0; i<1000; ++i)
(*A)[i] = i*7;
for (i=0; i<1000; ++i)
printf("%d %d\n",i,(*A)[i]);
}
A is a /single/ pointer to an array of ints.
And since the array is unbounded, it would not be possible to do A[j] on
this pointer; the type can only have ONE dimension, that of the array;
not of the pointer which has no dimension. (gcc doesn't even allow
*(A+0) or A[0].)
> But note also that you are not helping. You have added to the world yet
> another document containing statements like "arrays and pointer are the
> same". That will help fuel the confusion for another generation.
I like to show things warts and all. I actually didn't know about C's
remarkable abilities in silently adding extra arrays and dimensions to
what in your mind is a perfectly obvious data type.
Perhaps it would help others avoiding similar problems. If they get to
see it, as it's not advertised except for the one link here.
>> This stuff could be completely open and completely obvious. There
>> should be no ambiguity.
>
> No, it could not be, at least not without costs and potential benefits
> that I don't think you have any handle on (I certainly don't).
OK. Could have /been/. Or perhaps a C2 could have come along (I don't
how fir is getting along with that...)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-19 01:08 +0100 |
| Message-ID | <871t1lr560.fsf@bsb.me.uk> |
| In reply to | #92485 |
BartC <bc@freeuk.com> writes:
> On 18/08/2016 23:04, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 18/08/2016 01:55, Ben Bacarisse wrote:
>>>> BartC <bc@freeuk.com> writes:
>> <snip>
>>>>> Someone declares int(*A)[] and uses it as a 1D table.
>>>>
>>>> (you need a size in there)
>>>
>>> Why? It's a pointer to an unbounded array as I don't know the size
>>> until runtime.
>>
>> Are we still talking about C? How do you use it?
>
> int main(void){
> int (*A)[]; // pointer to (unbounded) array of int
> #define N 1000
> int i;
>
> A = malloc(N*sizeof(int));
>
> for (i=0; i<1000; ++i)
> (*A)[i] = i*7;
>
> for (i=0; i<1000; ++i)
> printf("%d %d\n",i,(*A)[i]);
>
> }
>
> A is a /single/ pointer to an array of ints.
Your point was about the confusion caused by int (*A)[];
| Someone declares int(*A)[] and uses it as a 1D table.
|
| Someone else declares int(*A)[] and uses it as a 2D table. It's like
| one of those magic books that, each time you open it, has something
| different inside!
but you correctly say:
> And since the array is unbounded,
(by the way, it's called an incomplete type)
> it would not be possible to do A[j]
> on this pointer; the type can only have ONE dimension, that of the
> array; not of the pointer which has no dimension. (gcc doesn't even
> allow *(A+0) or A[0].)
Without a size, you can't do this. (I'm just answering your "why?"
asked when I said you need a size.)
As for how you use the this type, I can't see why you would do it this
way. It seems to offer no advantages over the usual method, and
involves slightly more complex declarations and expressions. Am I
missing something?
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-19 11:04 +0100 |
| Message-ID | <np6lko$otj$1@dont-email.me> |
| In reply to | #92488 |
On 19/08/2016 01:08, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 18/08/2016 23:04, Ben Bacarisse wrote: >> int (*A)[]; // pointer to (unbounded) array of int >> A is a /single/ pointer to an array of ints. > > Your point was about the confusion caused by int (*A)[]; > but you correctly say: > >> And since the array is unbounded, > > (by the way, it's called an incomplete type) >> it would not be possible to do A[j] > Without a size, you can't do this. (I'm just answering your "why?" > asked when I said you need a size.) I actually didn't know that there is different behaviour between int(*)[] and int(*)[N]; I'd obviously never tried taking the /single/ pointer I normally set up for the type and adding an offset to it or trying to index it! Why should I? But C obviously expects that to be possible. And it can be made so even when N is 0. > As for how you use the this type, I can't see why you would do it this > way. It seems to offer no advantages over the usual method, and > involves slightly more complex declarations and expressions. Am I > missing something? Because it is the NATURAL way of creating such data structures. Someone wants a 'pointer to array to T', they declare 'pointer to array of T', and access it by dereferencing the 'pointer' part and indexing the 'array' part. That sounds perfectly reasonable. And the reader can understand exactly what's going on, as it also exactly matches the declaration. Are you with me so far? You presumably would start by crossing out the 'array to' part so that you declare 'pointer to T', then access it by applying an offset to that pointer then dereferencing the result, deluding yourself that it is array indexing because you use the [] syntax. It is also ambiguous because you have to declare T*A, which could also mean you want a single pointer to a single T, but readers don't know that. And unfortunately, neither does the language (so that you can index the .prev and .next elements in a linked list). It is also ambiguous when you write A[i], as that /looks/ like A might be a regular int A[] array. So so far there is no contest. But the one big difference as you point out is the syntax. I admit it's not pretty using my method, but it doesn't affect my points above. The syntax is the consequence of other bad decisions in the language design, although my method would still require an extra * dereference even if parentheses were not needed. But the * exactly matches the * pointer in the declaration, making for perfect transparency. Or do you object to that? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-19 12:32 +0100 |
| Message-ID | <87h9ahouyc.fsf@bsb.me.uk> |
| In reply to | #92493 |
BartC <bc@freeuk.com> writes: > On 19/08/2016 01:08, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 18/08/2016 23:04, Ben Bacarisse wrote: > >>> int (*A)[]; // pointer to (unbounded) array of int > >>> A is a /single/ pointer to an array of ints. >> >> Your point was about the confusion caused by int (*A)[]; > >> but you correctly say: >> >>> And since the array is unbounded, >> >> (by the way, it's called an incomplete type) > >>> it would not be possible to do A[j] > >> Without a size, you can't do this. (I'm just answering your "why?" >> asked when I said you need a size.) > > I actually didn't know that there is different behaviour between > int(*)[] and int(*)[N]; I'd obviously never tried taking the /single/ > pointer I normally set up for the type and adding an offset to it or > trying to index it! Why should I? > > But C obviously expects that to be possible. And it can be made so > even when N is 0. I can no longer follow what you are saying, but some of this sounds wrong. Here are some facts about C, some of which you may be disputing in the two paragraphs above: * You may have a pointer to an incomplete array type (like A above). * You can't index that pointer because you can't do arithmetic on a pointer to an incomplete type (void is also an incomplete type and this rule is why you can't add to or subtract from a void *). * Because of the last point, you can't index it even using zero (this came up recently in an unrelated thread). X[Y] is defined to be *(X + Y) and no special permission is granted to add zero to a pointer to an incomplete type. * You can't have a zero array size; i.e. int (*)[N] "when N is 0" is not a valid C type. If N is compile-time constant it's a constraint violation. >> As for how you use the this type, I can't see why you would do it this >> way. It seems to offer no advantages over the usual method, and >> involves slightly more complex declarations and expressions. Am I >> missing something? > > Because it is the NATURAL way of creating such data structures. > > Someone wants a 'pointer to array to T', they declare 'pointer to > array of T', and access it by dereferencing the 'pointer' part and > indexing the 'array' part. That sounds perfectly reasonable. And the > reader can understand exactly what's going on, as it also exactly > matches the declaration. > > Are you with me so far? No, that just alters my question. If that is what you are doing, I would to ask why you want a pointer to an array in the first place. If your answer is that you you are translating (either automatically or by hand) from a language with Pascal-like pointers, then it is disingenuous to claim you using C "naturally". <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-19 13:45 +0100 |
| Message-ID | <np6v1o$npa$1@dont-email.me> |
| In reply to | #92495 |
On 19/08/2016 12:32, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> Because it is the NATURAL way of creating such data structures. >> >> Someone wants a 'pointer to array to T', they declare 'pointer to >> array of T', and access it by dereferencing the 'pointer' part and >> indexing the 'array' part. That sounds perfectly reasonable. And the >> reader can understand exactly what's going on, as it also exactly >> matches the declaration. >> >> Are you with me so far? > > No, that just alters my question. If that is what you are doing, I > would to ask why you want a pointer to an array in the first place. I think 'gobsmacked' would describe my first reaction to that comment... Why indeed... (I have to consider that you might just be winding me up but I'm fairly sure you're not). > your answer is that you you are translating (either automatically or by > hand) from a language with Pascal-like pointers, then it is disingenuous > to claim you using C "naturally". OK. You presumably are happy with the concept of arrays? But sometimes you want to pass an array to function, and you don't want to pass it by value (as they can be all different sizes for a start), so you pass a reference. And the reference can be a pointer to the array. Or you want to allocate an array on the heap. If would be nonsensical for the allocator to return an array by value, so it returns a pointer to an array. Or you apply an address-of operator to an array, and you get, hopefully, a pointer to that array. Or, forget arrays. You can substitute any 'object' for 'array' above, and it would still make sense. I can't see how anyone can't see this is a completely natural and logical way of dealing with such things. At least in the low-level kind of language we're talking about (higher-level ones will hide more of the mechanics so you may not deal with explicit pointers at all). Are you suggesting C's recommended approach, which is more akin to that found in assembly languages which only know about pointers and blocks of memory, is the natural way of doing it? Representing a array of T on the heap or as a parameter in a way indistinguishable from a single value of T? I mean, when you give the address of a building, the address normally refers to the whole building, not of the first floor! (And you might also consider why those other languages -the ones that have explicit pointers - do it that way while C's approach seems to be unique.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-19 14:40 +0100 |
| Message-ID | <87wpjcop11.fsf@bsb.me.uk> |
| In reply to | #92497 |
BartC <bc@freeuk.com> writes: > On 19/08/2016 12:32, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> Because it is the NATURAL way of creating such data structures. >>> >>> Someone wants a 'pointer to array to T', they declare 'pointer to >>> array of T', and access it by dereferencing the 'pointer' part and >>> indexing the 'array' part. That sounds perfectly reasonable. And the >>> reader can understand exactly what's going on, as it also exactly >>> matches the declaration. >>> >>> Are you with me so far? >> >> No, that just alters my question. If that is what you are doing, I >> would to ask why you want a pointer to an array in the first place. > > I think 'gobsmacked' would describe my first reaction to that comment... > > Why indeed... (I have to consider that you might just be winding me up > but I'm fairly sure you're not). > >> your answer is that you you are translating (either automatically or by >> hand) from a language with Pascal-like pointers, then it is disingenuous >> to claim you using C "naturally". > > OK. You presumably are happy with the concept of arrays? > > But sometimes you want to pass an array to function, and you don't > want to pass it by value (as they can be all different sizes for a > start), so you pass a reference. And the reference can be a pointer to > the array. > > Or you want to allocate an array on the heap. If would be nonsensical > for the allocator to return an array by value, so it returns a pointer > to an array. > > Or you apply an address-of operator to an array, and you get, > hopefully, a pointer to that array. > > Or, forget arrays. You can substitute any 'object' for 'array' above, > and it would still make sense. > > I can't see how anyone can't see this is a completely natural and > logical way of dealing with such things. Programming is not natural. I think you are deliberately avoiding terms like idiomatic, canonical and usual because you know that when you want to pass an array to a function "by reference"[1] you pass a pointer to an element of it. Array values decay to pointers precisely to facilitate this, and it allows one to pass a slice quite conveniently. Obviously you know this, so you can't say that what you are doing is usual or canonical or idiomatic and you've settled on it being "natural" instead. Fine. The way one usually passes an array to a function "by reference"[1] is not what you call natural. I really don't want to argue about what that means for a programming language. <snip> [1] Let's leave that error alone shall we? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-19 15:30 +0100 |
| Message-ID | <np7571$cpk$1@dont-email.me> |
| In reply to | #92499 |
On 19/08/2016 14:40, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> Or, forget arrays. You can substitute any 'object' for 'array' above, >> and it would still make sense. >> >> I can't see how anyone can't see this is a completely natural and >> logical way of dealing with such things. > > Programming is not natural. I think you are deliberately avoiding terms > like idiomatic, canonical and usual because you know that when you want > to pass an array If I expand my comment above: if you accept that, given any kind of object of type T, you sometimes want a pointer to it (for multiple reasons), then simply creating a pointer to T, T*, *must* be the simplest and most obvious and natural way of going about it. You don't need to make a special case when T happens to an array, and start dissecting the type into elements and create instead a U* pointer. (Where you also lose information: that fact that the pointer was to part of an array rather than an arbitrary one, and also attributes such as the size of the array type, which sometimes can be useful in type-checking: a function designed to take a pointer to a 4-element array can't be passed a 5-element one.) > Array values decay to pointers precisely to > facilitate this, and it allows one to pass a slice quite conveniently. Yes, slicing is clumsier using the 'higher-level' array-pointer method comparing with the cruder approach. (A url to whole book is going to be more awkward to adapt to a subset of its pages. A url to an individual page will be simpler, given an easy way of stepping to the next. But you don't adopt such a method to deal with entire books in general.) However slicing can be facilitated with purpose-made features in the language. Or, saving some work, you can just revert to pointers-to-elements when you need to. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-19 15:54 +0100 |
| Message-ID | <87lgzsolkw.fsf@bsb.me.uk> |
| In reply to | #92501 |
BartC <bc@freeuk.com> writes: > On 19/08/2016 14:40, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> Or, forget arrays. You can substitute any 'object' for 'array' above, >>> and it would still make sense. >>> >>> I can't see how anyone can't see this is a completely natural and >>> logical way of dealing with such things. >> >> Programming is not natural. I think you are deliberately avoiding terms >> like idiomatic, canonical and usual because you know that when you want >> to pass an array > > If I expand my comment above: if you accept that, given any kind of > object of type T, you sometimes want a pointer to it (for multiple > reasons), then simply creating a pointer to T, T*, *must* be the > simplest and most obvious and natural way of going about it. Did you not see that part where I said I don't want to argue of what natural means? The same goes for "obvious". People with different experience will have different view about what is obvious. I accept that you don't find the usual way of passing an array "by reference" obvious or natural. One of us has to stop this largely pointless exchange, so unless your reply contains actual errors of fact, I'll leave it at that. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-19 16:24 +0100 |
| Message-ID | <np78cv$o46$1@dont-email.me> |
| In reply to | #92503 |
On 19/08/2016 15:54, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> If I expand my comment above: if you accept that, given any kind of >> object of type T, you sometimes want a pointer to it (for multiple >> reasons), then simply creating a pointer to T, T*, *must* be the >> simplest and most obvious and natural way of going about it. > > Did you not see that part where I said I don't want to argue of what > natural means? The same goes for "obvious". People with different > experience will have different view about what is obvious. I accept > that you don't find the usual way of passing an array "by reference" > obvious or natural. OK I will leave it to other people to judge whether the technique of getting a pointer to T by creating a T* type is obvious, natural or logical. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-08-17 16:04 -0700 |
| Message-ID | <6566be1f-775c-4a04-abc3-7e77c32dc90b@googlegroups.com> |
| In reply to | #92404 |
On Wednesday, August 17, 2016 at 3:46:18 PM UTC-5, Bart wrote:
> On 17/08/2016 21:33, jameskuyper@verizon.net wrote:
> > On Wednesday, August 17, 2016 at 3:44:42 PM UTC-4, Bart wrote:
>
> >> I declare:
> >>
> >> int (*B)[10];
> >>
> >> to mean a pointer to a dynamically allocated 1D array. Then you come
> >> along and say it can also be used for a dynamic 2D array!
> >>
> >> So, which is it? 1D, 2D or both?
> >
A 2D array is a 1D array where each element has array type. Thinking about
arrays in that manner makes things a *lot* more sensible.
Take the declaration
T a[N];
We know from the conversion rule that the expression "a" will decay to type
T *
This is true for *any type T*, including *array* types. If we replace T with
the array type Q [M], we get
Q a[N][M]; // N-element array of T ==
// N-element array of M-element array of Q
Since T == Q [M], T * == Q (*)[M]. The only thing that makes it non-
intuitive is the precedence of [] over unary *, so we have to throw in
a bunch of parentheses to make it work. It would have been nice if DMR had
made the dereference operator postfix, but he didn't.
Going at it from the dynamic allocation side,
T *a = malloc( sizeof *a * N );
allocates space for N elements of type T. Again, this is true for *any
type T*, including array types. Doing the same substitution as above:
Q (*a)[M] = malloc( sizeof *a * N );
The semantics are *exactly the same* as allocating a 1D array; all that's
changed is the type of a. We've allocated space for N elements of type
Q [M].
> > 2D, with the option for the first dimension to be 1, which is (by explicit
> > definition in the C language, equivalent o a single object of the array's
> > element type). If you want a dynamically allocated 1D array, use "int *B;", and
> > set it to point at the first element of that array.
>
> So to get an array, I need to declare something that doesn't involve an
> array, and which furthermore is indistinguishable from a pointer to a
> arbitrary, standalone int value?
>
> Yet C is perfectly capable of doing it properly: declare int (*B)[].
>
> Why am I not surprised that C is difficult to learn when everyone is
> doing things backwards!
>
> --
> Bartc
Blame DMR. He wanted to have his cake (preserve array semantics from the B
language) and eat it to (not have to materialize the pointer that B's array
semantics demanded). Thus, we have the rule that array expressions decay to
pointer expressions in most circumstances.
The result is that almost everything is done in terms of pointer
expressions. Once you accept this simple fact, everything suddenly becomes
a lot clearer and easier to understand.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-18 00:41 +0100 |
| Message-ID | <np2sn0$hon$1@dont-email.me> |
| In reply to | #92420 |
On 18/08/2016 00:04, John Bode wrote: > On Wednesday, August 17, 2016 at 3:46:18 PM UTC-5, Bart wrote: >> Why am I not surprised that C is difficult to learn when everyone is >> doing things backwards! > Blame DMR. He wanted to have his cake (preserve array semantics from the B > language) and eat it to (not have to materialize the pointer that B's array > semantics demanded). Thus, we have the rule that array expressions decay to > pointer expressions in most circumstances. > > The result is that almost everything is done in terms of pointer > expressions. Once you accept this simple fact, everything suddenly becomes > a lot clearer and easier to understand. OK, what can you deduce from this expression: A[i][j]; about the data structures involved? Assume this yields a value of type T. Any other language: A is a flat 2D array indexed by i and j; end of story. In C: I estimate a dozen different possibilities. (Four involving combinations of arrays and pointers to define A. Another four when i is the array, and A is the index. Another four when A is again the index, but i and j are each 1D arrays, each declared with as a pointer or array. Considering just the first four, two may not even be set up as a 2D-addressable structures at all, only 1D. While a third might not even be 1D-addressable if it points to a single object (ie. T**A). What a mess.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-17 16:59 -0700 |
| Message-ID | <bb450bcd-743a-49b7-ad78-5b3660b0ef5f@googlegroups.com> |
| In reply to | #92428 |
On Wednesday, August 17, 2016 at 7:41:26 PM UTC-4, Bart wrote: ... > OK, what can you deduce from this expression: > > A[i][j]; > > about the data structures involved? Assume this yields a value of type T. You're supposed to figure that out from looking at the declaration of A. That's what it's there for. > Any other language: A is a flat 2D array indexed by i and j; end of story. That's not true of perl, C++, or IDL, to name three other languages I'm currently familiar with. All three of those languages allow for additional possibilities not even dreamed of in C. You'd die from exhaustion complaining about all of the possibilities they allow.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-18 01:24 +0100 |
| Message-ID | <np2v8f$nsn$1@dont-email.me> |
| In reply to | #92432 |
On 18/08/2016 00:59, jameskuyper@verizon.net wrote: > On Wednesday, August 17, 2016 at 7:41:26 PM UTC-4, Bart wrote: > ... >> OK, what can you deduce from this expression: >> >> A[i][j]; >> >> about the data structures involved? Assume this yields a value of type T. > > You're supposed to figure that out from looking at the declaration of A. That's what it's there for. Well, this is it: you shouldn't need to, to get an /idea/ of what is going on. This is, after all, pretty basic. And even if I did look at the declaration, apparently that's not enough: I need to look at the initialisation code too, to see how any pointers have been initialised. >> Any other language: A is a flat 2D array indexed by i and j; end of story. > > That's not true of perl, C++, or IDL, to name three other languages I'm currently familiar with. All three of those languages allow for additional possibilities not even dreamed of in C. You'd die from exhaustion complaining about all of the possibilities they allow. C++ is just C, in spades. As for the rest, let's keep this about low-level languages where you expect the code to be reasonably transparent. But all the ones I'm familiar with, A[i,j] will index into a table. It might not be a flat rectangular array, but the higher level languages will take care of those details; you don't need to know. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-08-18 08:30 -0700 |
| Message-ID | <2da42916-dac1-4e1c-a14e-297437e3c7fe@googlegroups.com> |
| In reply to | #92428 |
On Wednesday, August 17, 2016 at 6:41:26 PM UTC-5, Bart wrote: > On 18/08/2016 00:04, John Bode wrote: > > On Wednesday, August 17, 2016 at 3:46:18 PM UTC-5, Bart wrote: > > >> Why am I not surprised that C is difficult to learn when everyone is > >> doing things backwards! > > > Blame DMR. He wanted to have his cake (preserve array semantics from the B > > language) and eat it to (not have to materialize the pointer that B's array > > semantics demanded). Thus, we have the rule that array expressions decay to > > pointer expressions in most circumstances. > > > > The result is that almost everything is done in terms of pointer > > expressions. Once you accept this simple fact, everything suddenly becomes > > a lot clearer and easier to understand. > > OK, what can you deduce from this expression: > > A[i][j]; > > about the data structures involved? Assume this yields a value of type T. > By itself, nothing - I don't know if A corresponds to a flat 2D array, or an array of pointers, or whether it's auto or static or dynamically allocated or whatever. I'd have to chase down the definition. It will matter if I want to map A to a 1D sequence (say for certain kinds of image processing or whatever). C'est la guerre. > Any other language: A is a flat 2D array indexed by i and j; end of story. > > In C: I estimate a dozen different possibilities. > > (Four involving combinations of arrays and pointers to define A. Another > four when i is the array, and A is the index. Another four when A is > again the index, but i and j are each 1D arrays, each declared with as a > pointer or array. > To be fair, most C programmers aren't insane (apart from choosing to work in C); outside of the IOCCC, the odds that A is the array (or pointer) while i and j are integers is fairly high (no, not 100%, but high enough to where I don't worry about it). Subscript operator commutativity is one of many warts, but it's not one that gets exploited all that often. > Considering just the first four, two may not even be set up as a > 2D-addressable structures at all, only 1D. While a third might not even > be 1D-addressable if it points to a single object (ie. T**A). What a mess.) > Yup. Arrays in C are special (as in Special Ed). > -- > Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-18 10:49 -0700 |
| Message-ID | <lnlgzuhsql.fsf@kst-u.example.com> |
| In reply to | #92428 |
BartC <bc@freeuk.com> writes:
[...]
> OK, what can you deduce from this expression:
>
> A[i][j];
>
> about the data structures involved? Assume this yields a value of type T.
About as much as you can deduce from
x = y + z;
Even ignoring arrays and pointers, there are a large number of
possible combinations of types for x, y, and z. Integer (signed or
unsigned) floating-point, complex, with implicit conversions galore.
Throw pointers into the mix and either both x and y are pointers
(possibly decayed array expressions), or the author is being perverse
by using "integer+pointer" rather than "pointer+integer".
I don't expect to be able to understand every expression without
knowing something about its operands.
In the case of `A[i][j]`, I expect that i and j are integers and
that A is probably poorly named. If i and j *aren't* integers, I
will blame the author of the code for being (perhaps deliberately)
unclear.
Assuming that i and j are integers, I believe there are 4
possibilities: array of arrays, array of pointers, pointer to array,
pointer to pointer. Finding out which is a simple matter of looking
at the declaration.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-18 19:20 +0100 |
| Message-ID | <np4u9n$n38$1@dont-email.me> |
| In reply to | #92468 |
On 18/08/2016 18:49, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > [...] >> OK, what can you deduce from this expression: >> >> A[i][j]; >> >> about the data structures involved? Assume this yields a value of type T. > > About as much as you can deduce from > > x = y + z; > > Even ignoring arrays and pointers, there are a large number of > possible combinations of types for x, y, and z. Integer (signed or > unsigned) floating-point, complex, with implicit conversions galore. > Throw pointers into the mix and either both x and y are pointers > (possibly decayed array expressions), or the author is being perverse > by using "integer+pointer" rather than "pointer+integer". With x=y+z you can usually assume there's a box containing y, another box for z, and a third box for x. (Well, unless array names are used but then that's part of the same thing with A[i][j].) You're only interested in the 'shape' of the expression. Determining the shape of A is more difficult. > Assuming that i and j are integers, I believe there are 4 > possibilities: array of arrays, array of pointers, pointer to array, > pointer to pointer. Finding out which is a simple matter of looking > at the declaration. At least four, but it depends also on how they are set up: T A[M][N]; //1 array M of array N of T T (*A)[N]; //2 initialised to a single pointer to T[N] T (*A)[N]; //3 initialised to a multiple pointers to T[N] T *A[N]; //4 array of N initialised to single pointers to T T *A[N]; //5 array of N initialised to multiple pointers to T? T **A; //6 initialised to single pointer to a single T T **A; //7 initialised to single pointer to a multiple T T **A; //8 initialised to multiple pointers to multiple T T **A; //9 initialised to multiple pointers to single T A[i][j] will compile with all of these (only four distinct combinations). But the [i] index I think is only meaningful for 1, 3, 4, 5, 8, 9 (it should be * or [0] for the others) The [j] index I think is only meaningful (with the correct [i] or * for the other op) for 1, 2, 5, 7, 8 (and should be * or [0] for the others). Phew! But I'm not totally sure of this lot, which is part of the trouble. And that's ignoring the weirder possibilities. Anyway I hope you get my point... (In my language A[i][j] only makes sense for (1). It's a bit simpler. And a lot less work.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-18 01:39 +0100 |
| Message-ID | <87d1l6uczq.fsf@bsb.me.uk> |
| In reply to | #92397 |
BartC <bc@freeuk.com> writes: > On 17/08/2016 19:51, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> <snip> >>> [...] But I'm talking about the normal case where a pointer has the >>> correct value. One example was: >>> >>> int (*B)[10]; // pointer to array 10 of int >>> >>> This, when properly initialised, is clearly going to point to one >>> object. >> >> Not at all. This is a standard idiom for allocating 2D arrays >> dynamically: >> >> int (*B)[10] = malloc(100 * sizeof *B); > > Cdecl tells me (I knew this one but needed to double check) that > int(*B)[10] is a pointer to array. One array, not two. Yes, it's a pointer to one array amongst many. That's the normal way to use malloc. > A pointer to a 2D 'flat' array of compile-time bounds would be: > > int (*C)[10][20]; // or [][20]; ptr to array of array Yes, but I don't want one of those. > A pointer to a 2D array implemented with Iliffe vectors would be > > int (*(*C)[])[]; // pointer to array of ptr to array I don't want one of those either. > IMO what you're doing with the above is abusing the language. No, this way of making dynamic arrays have been at the heart of C since the start. You don't like it, but it's idiomatic C and not an abuse of the notation at all. And whilst you can certainly say you would like it to have been otherwise, this is how it's done in C. I accept you don't like it. I accept you think it an abuse of the language. I turn, I hope you will accept that it is a normal way to allocate and access a 2D array. > If you > need an array, that declare it as an array, not a ambiguous pointer, > and do everyone reading your code a favour. Dynamic array usually don't have a size know at compile time. The usual idiom does that naturally: int *data = malloc(n_items * size *data); Are you seriously advocating variably modified array types and (since it's dynamic) and extra pointer dereference just for this simple case? Maybe you could show how I should do this as well as how I should have done it before C99 and in C11+ implementations that chose not to implement these. An example would really help. <snip> > Your comments illustrate perfectly what is wrong with C; I declare: > > int (*B)[10]; > > to mean a pointer to a dynamically allocated 1D array. Then you come > along and say it can also be used for a dynamic 2D array! > > So, which is it? 1D, 2D or both? You are playing fast and loose with pronouns. It is a pointer, but, in so far as a pointer has a dimension, it's 2D since you need two indexes to access an object of the base type. Similarly, the data structure you access using it is 2D because it uses 2 dimension in the access the base elements. One of the dimensions may be of size 1, but programming languages almost always distinguish between array types with a size of 1 and scalar types (and, likewise, between 2D arrays with one dimension being 1 and 1D arrays). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-18 10:47 +0100 |
| Message-ID | <np407b$9vn$1@dont-email.me> |
| In reply to | #92438 |
On 18/08/2016 01:39, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 17/08/2016 19:51, Ben Bacarisse wrote: >>> int (*B)[10] = malloc(100 * sizeof *B); >> >> Cdecl tells me (I knew this one but needed to double check) that >> int(*B)[10] is a pointer to array. One array, not two. > > Yes, it's a pointer to one array amongst many. That's the normal way > to use malloc. No, it's a pointer to ONE array. That's determined by the type. What's key here is that very often you DO only want a pointer to one thing, to match a data structure that has been created outside the language, in some pseudo-code, or ported from another language with a narrower concept of a pointer. How then do you express such a pointer in C? You seem to be suggesting that it is impossible. If only one dimension is involved, then a direct C implementation will give me an extra dimension free of charge? What I'm getting is that a natural data structure having N dimensions needs to have one dimension surgically removed in order to fit into C's pattern. >> A pointer to a 2D 'flat' array of compile-time bounds would be: >> >> int (*C)[10][20]; // or [][20]; ptr to array of array > > Yes, but I don't want one of those. Yes, you do. Someone WANTS a pointer to array of array, types that into Cdecl, and it will give them that spec. Should they ignore Cdecl? >> A pointer to a 2D array implemented with Iliffe vectors would be >> >> int (*(*C)[])[]; // pointer to array of ptr to array > > I don't want one of those either. But that is the natural way of implementing Iliffe vectors! Suppose you want a ragged 2D array, which is a list of pointers to arrays of elements. But you have a dynamic number of rows so you need a pointer to a list of pointers to arrays of elements. But C will kindly turn every pointer into a potential extra array and extra dimension. Is nobody going to admit to C's approach to this stuff is completely lousy? I get that the language is what it is, but you don't need to pretend it's wonderful. What exactly is wrong with a pointer that normally points to one thing? It can then be used to naturally create data structures without having to transform them into something else and makes a whole bunch of other things much simpler. And it can be used to create .next and .prev pointers in a linked list without the ludicrous ability to be able to index them as though they were arrays! Then, somebody using pointers to pass a reference variable to a function can do so without the callee treating it as an array either. >> If you >> need an array, that declare it as an array, not a ambiguous pointer, >> and do everyone reading your code a favour. > > Dynamic array usually don't have a size know at compile time. The usual > idiom does that naturally: > > int *data = malloc(n_items * size *data); Yes, that's the usual idiom but only because the indexing syntax for a proper pointer-to-array sucks. People like writing A[i] instead of (*A)[i]. > > Are you seriously advocating variably modified array types and (since > it's dynamic) and extra pointer dereference just for this simple case? In terms of actual machine operations, there should be no difference. Both require three memory accesses (loading the pointer in A, loading the index, followed by a load of the element at A+i). > Maybe you could show how I should do this as well as how I should have > done it before C99 and in C11+ implementations that chose not to > implement these. An example would really help. Sorry, what did C99 and C11 not implement? >> So, which is it? 1D, 2D or both? > > You are playing fast and loose with pronouns. It is a pointer, but, in > so far as a pointer has a dimension A dimension I don't want. That's going to make life difficult. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-18 11:03 -0700 |
| Message-ID | <lnh9aihs3h.fsf@kst-u.example.com> |
| In reply to | #92446 |
BartC <bc@freeuk.com> writes:
> On 18/08/2016 01:39, Ben Bacarisse wrote:
[...]
>> Maybe you could show how I should do this as well as how I should
>> have done it before C99 and in C11+ implementations that chose not to
>> implement these. An example would really help.
>
> Sorry, what did C99 and C11 not implement?
C99 added VLAs (variable length arrays). C11 made them optional.
[...]
--
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 18 of 20 — ← Prev page 1 … 16 17 [18] 19 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web