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 17 of 20 — ← Prev page 1 … 15 16 [17] 18 19 20 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-19 17:14 +0100 |
| Message-ID | <87fuq0ohw8.fsf@bsb.me.uk> |
| In reply to | #92504 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, August 19, 2016 at 3:46:01 PM UTC+1, Ben Bacarisse wrote: >> >> The O(N log N) method using binary search sounds odd -- the description >> does not seem to match any selection algorithm I know. Can you explain >> what you meant? >> > Pass through the data, taking maximum and minimum. Then use (max + > min)/2 as you first guess for the median. Pass through again counting > elements above and below, and the nearest in both directions. If you > are wrong, use (max (or min) + guess)/2 as your refined guess and > repeat, doing a binary search. > If you are right, the nearest rather than the guess is the answer. Interesting. I did not know that one. Maybe the fact that it's not linear time makes people overlook it, but there must be times when neither copying nor rearranging the array is acceptable. A bit more searching suggests that some people call this Torben's algorithm. Do you know the inventor or simply a definite name for it? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-19 23:38 +0100 |
| Subject | O(n log n) in place median algorithm (was: Difference between these pointer syntaxes) |
| Message-ID | <87oa4omljv.fsf_-_@bsb.me.uk> |
| In reply to | #92508 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> On Friday, August 19, 2016 at 3:46:01 PM UTC+1, Ben Bacarisse wrote: >>> >>> The O(N log N) method using binary search sounds odd -- the description >>> does not seem to match any selection algorithm I know. Can you explain >>> what you meant? >>> >> Pass through the data, taking maximum and minimum. Then use (max + >> min)/2 as you first guess for the median. Pass through again counting >> elements above and below, and the nearest in both directions. If you >> are wrong, use (max (or min) + guess)/2 as your refined guess and >> repeat, doing a binary search. >> If you are right, the nearest rather than the guess is the answer. > > Interesting. I did not know that one. Maybe the fact that it's not > linear time makes people overlook it, but there must be times when > neither copying nor rearranging the array is acceptable. > > A bit more searching suggests that some people call this Torben's > algorithm. Do you know the inventor or simply a definite name for it? That's a first name and probably not that of the originator. Does anyone know more about it? (I've changed the subject and set Followup-To: comp.programming.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-19 08:09 -0700 |
| Message-ID | <ef363dbb-d2c5-49f4-a29f-505abc6cbb08@googlegroups.com> |
| In reply to | #92500 |
On Friday, August 19, 2016 at 8:50:29 AM UTC-5, Malcolm McLean wrote: > It's also unconventional. David Brown is right, and it's pretty > awful that median reorders data, especially if it also returns > a failure mode flag. (You can write it using binary search, > which has the same O(N log N) runtime as the more obvious sort > version, and doesn't need extra memory). However it's quite common > to see medians that do just that - the first hit on "median C > source code" from Google did so. If one is allowed to rearrange the array, the median (or kth best item) can be found with an average O(N) runtime on random data, rather than O(NlgN). If one does not know that the data are sorted and there are no duplicates, the run-time will be at least O(N) because there is no way one can examine fewer than N items and know the median (or kth best), so the O(N) asymptotic bound is optimal. BTW, the linear-average-time technique for finding the median or kth-best item is basically a quicksort, except that after each partitioning step one one can ignore the partition that doesn't contain the item of interest.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-18 07:27 -0700 |
| Message-ID | <a86b3023-109c-4fb3-b810-d78cf7425760@googlegroups.com> |
| In reply to | #92452 |
On Thursday, August 18, 2016 at 7:26:29 AM UTC-5, Malcolm McLean wrote: > const is mainly clutter. It doesn't really add anything except the > ability to pass a const-qualified pointer, though you can argue > that it helps to document input vs output. For "const" to be most useful, there would need to two additional aspects: 1. A distinction between the promises "object will not be changed via pointer unless it is converted to another type", "object will not be changed via pointer nor any pointer derived from it" [meaning that if the compiler knows there would be no *other* way for the object to change, it could assume it won't change at all], and "object will not be changed via any means whatsoever, so the compiler may safely cache any value read via the pointer without regard for aliasing". 2. A means of indicating that a function's return type should be regarded as having qualifiers derived from argument types. If such a means had predated strchr, its prototype could be something like: char *strchr(char return *str, char chr); thus allowing: char Fred[5] = "Fred"; const char Kate[5] = "Kate"; const char *st3 = strchr(Fred, ch); // Strchr returns non-const char *st2 = strchr(Fred, ch); const char *st1 = strchr(Kate, ch); // Strchr returns const but not char *st4 = strchr(Kate, ch); since the return from that strchr call would be const-qualified as a consequence of the argument being likewise. Incidentally, C would also benefit enormously from having a distinction between pointer arguments that will not be copied to anything that outlives the function call, those that may be returned but not otherwise copied, and those which may be copied beyond the function call.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-18 17:40 +0200 |
| Message-ID | <np4ksp$ef2$1@dont-email.me> |
| In reply to | #92455 |
On 18/08/16 16:27, supercat@casperkitty.com wrote: > On Thursday, August 18, 2016 at 7:26:29 AM UTC-5, Malcolm McLean wrote: >> const is mainly clutter. It doesn't really add anything except the >> ability to pass a const-qualified pointer, though you can argue >> that it helps to document input vs output. > > For "const" to be most useful, there would need to two additional aspects: > > 1. A distinction between the promises "object will not be changed via pointer > unless it is converted to another type", If you have a pointer-to-const pointing at an object, and convert it to a different type in order to change the object, then the behaviour is undefined. You have already promised not to do this by using C - re-stating this promise in some way is unnecessary. > "object will not be changed via > pointer nor any pointer derived from it" [meaning that if the compiler > knows there would be no *other* way for the object to change, it could > assume it won't change at all], pointer-to-const gives you exactly that. > and "object will not be changed via any > means whatsoever, so the compiler may safely cache any value read via > the pointer without regard for aliasing". Declaring the object as "const" in the first place gives you that. What C is missing is a good way to say "Here is an object that is initially mutable so that I can set it up. But now that it has been initialised, it will never change again". (Even C++ could not do that well until C++14, I think.) However, I doubt if it would be /that/ useful, and you could get a reasonable substitute by starting with a mutable object (or pointer to one), doing the initialisation, then using it to initialise a const (or pointer-to-const), then letting the original non-const object or pointer go out of scope. > > 2. A means of indicating that a function's return type should be regarded > as having qualifiers derived from argument types. If such a means had > predated strchr, its prototype could be something like: > > char *strchr(char return *str, char chr); > > thus allowing: > > char Fred[5] = "Fred"; > const char Kate[5] = "Kate"; > const char *st3 = strchr(Fred, ch); // Strchr returns non-const > char *st2 = strchr(Fred, ch); > const char *st1 = strchr(Kate, ch); // Strchr returns const > > but not > > char *st4 = strchr(Kate, ch); > > since the return from that strchr call would be const-qualified as a > consequence of the argument being likewise. That is a challenge for const correctness. C takes the attitude that it can't be done nicely in C (you'd need two versions of the strchr function, and it would be up to the user to pick the right one) - so it gives you a single version that takes a "const char *" and returns a "char *". This function can't be written by the user in a fully portable manner, because it contains undefined behaviour - but it's fine for the standard library because that can use whatever implementation-defined behaviour is needed to make it safe. It is then up to the user to keep it safe - there is no compile-time checking. C++ takes the attitude that it /can/ be done - you just make two overloaded functions, and thus get compile-time checking. The cost is that the implementation will be repetitive (templates and a smart compiler/linker can give you efficient end results). > > Incidentally, C would also benefit enormously from having a distinction > between pointer arguments that will not be copied to anything that outlives > the function call, those that may be returned but not otherwise copied, and > those which may be copied beyond the function call. > I don't know how "enormously" beneficial this would be, but it would certainly certain types of optimisations. More useful, I think, would be some sort of "transitive const" to solve Bart's problem where const pointers into a idiomatic linked list structure can be used to change elements on the list despite the "const". But again, this is outside the scope of C - you can write safe functions if you want, but that is up to the user. If you want the tools needed to enforce this sort of thing, look for C++.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-18 10:34 -0700 |
| Message-ID | <lnpop6htfr.fsf@kst-u.example.com> |
| In reply to | #92463 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> That is a challenge for const correctness. C takes the attitude that it
> can't be done nicely in C (you'd need two versions of the strchr
> function, and it would be up to the user to pick the right one) - so it
> gives you a single version that takes a "const char *" and returns a
> "char *". This function can't be written by the user in a fully
> portable manner, because it contains undefined behaviour - but it's fine
> for the standard library because that can use whatever
> implementation-defined behaviour is needed to make it safe. It is then
> up to the user to keep it safe - there is no compile-time checking.
[...]
In my opinion, the ANSI C committee made a mistake here. It *could*
have been done nicely in C -- by having introducing two different
versions of the strchr function (perhaps strchr and strcchr). Several
other standard library functions have the same problem.
--
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-18 09:49 -0700 |
| Message-ID | <bf7017c6-1a09-4bd3-b0fc-8e427e48fae2@googlegroups.com> |
| In reply to | #92466 |
On Thursday, August 18, 2016 at 11:03:01 AM UTC-5, Keith Thompson wrote: > In my opinion, the ANSI C committee made a mistake here. It *could* > have been done nicely in C -- by having introducing two different > versions of the strchr function (perhaps strchr and strcchr). Several > other standard library functions have the same problem. What makes you think the problem doesn't exist in user code, in ways that can't be solved via code duplication (e.g. because one needs to have collection of pointers to things, some of which are const and some of which aren't, and needs to be able to write the non-const ones)? There needs to be a type for "pointer to a possibly-const thing that might be used (after casting) to write the thing if it wasn't const". I.e. the kind of "const" that C has.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-18 13:04 -0700 |
| Message-ID | <ln4m6hj12e.fsf@kst-u.example.com> |
| In reply to | #92471 |
supercat@casperkitty.com writes:
> On Thursday, August 18, 2016 at 11:03:01 AM UTC-5, Keith Thompson wrote:
>> In my opinion, the ANSI C committee made a mistake here. It *could*
>> have been done nicely in C -- by having introducing two different
>> versions of the strchr function (perhaps strchr and strcchr). Several
>> other standard library functions have the same problem.
>
> What makes you think the problem doesn't exist in user code, in ways that
> can't be solved via code duplication (e.g. because one needs to have
> collection of pointers to things, some of which are const and some of
> which aren't, and needs to be able to write the non-const ones)? There
> needs to be a type for "pointer to a possibly-const thing that might be
> used (after casting) to write the thing if it wasn't const". I.e. the
> kind of "const" that C has.
What makes you think I don't think such problems exist?
Plenty of problems exist in user code. The `const` keyword clearly does
not solve all possible problems with objects that should or should not
be writable. It might be nice to have an array object some of whose
members are read-only and some of which are writable, with the compiler
enforcing it. Many such things can be addressed using wrappers and
opaque data types -- or just programmer discipline, with or without the
compiler's help.
My only point is that strchr() pokes a hole in const-safety, letting you
attempt to modify a const-qualified object with no warning from the
compiler. A simple example:
#include <stdio.h>
#include <string.h>
int main(void) {
const char *s = "hello";
char *ptr = strchr(s, 'h');
*ptr = 'H';
puts(s);
}
(With gcc, this dies with a segmentation fault. With tcc it prints
"Hello".)
And in my opinion it would have been better to plug that hole by
splitting strchr() into two functions, something like:
char *strchr ( char *s, int c);
const char *strcchr(const char *s, int c);
I make no claims that such a change would have solved all problems
having to do with read-only data, merely that in my opinion it
would have been an improvement over the current situation.
On the other hand, given the current definition of strchr(),
programmers merely have to exercise some case to avoid accidentally
modifying read-only objects (with insufficient help from the
compiler), so it's not *that* bad.
--
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-18 12:05 -0700 |
| Message-ID | <31203bb9-a8dd-403f-b4f3-1ddb09f3b904@googlegroups.com> |
| In reply to | #92477 |
On Thursday, August 18, 2016 at 1:31:59 PM UTC-5, Keith Thompson wrote: > My only point is that strchr() pokes a hole in const-safety, letting you > attempt to modify a const-qualified object with no warning from the > compiler. A simple example: Having the compiler treat the return type as having the same qualifiers as the argument would be helpful there, but the semantic usefulness of the language for some purposes would be greatly impeded if all programs had to be statically verifiable as const correct. As for splitting strchr into two functions, that function and many programs which use it existed well before c89. While it might have been good to introduce two newly-named functions and deprecate invocation of strchr by its original name, there's no way the authors of C89 could have specified strchr without breaking a lot of code in ways that would be awkward to fix. Besides, the only time the existing semantics would pose a problem would be if compiler writers wanted to perform optimizations that wouldn't become practical until long after the C89 Standard was published.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-18 13:52 -0700 |
| Message-ID | <lnvayxhkay.fsf@kst-u.example.com> |
| In reply to | #92479 |
supercat@casperkitty.com writes:
> On Thursday, August 18, 2016 at 1:31:59 PM UTC-5, Keith Thompson wrote:
>> My only point is that strchr() pokes a hole in const-safety, letting you
>> attempt to modify a const-qualified object with no warning from the
>> compiler. A simple example:
>
> Having the compiler treat the return type as having the same qualifiers as
> the argument would be helpful there, but the semantic usefulness of the
> language for some purposes would be greatly impeded if all programs had to
> be statically verifiable as const correct.
I'm not talking about "all programs", just a handful of standard library
functions that make it too easy to violate const-correctness.
> As for splitting strchr into two functions, that function and many programs
> which use it existed well before c89. While it might have been good to
> introduce two newly-named functions and deprecate invocation of strchr by
> its original name, there's no way the authors of C89 could have specified
> strchr without breaking a lot of code in ways that would be awkward to fix.
To avoid breaking existing code, I suppose C89 could have introduced
two new functions with new names and deprecated the existing strchr()
(and actually *removed* it in C99). That would have been a bit
more confusing than the approach I suggested. I'm not sure which
approach would be better.
> Besides, the only time the existing semantics would pose a problem would be
> if compiler writers wanted to perform optimizations that wouldn't become
> practical until long after the C89 Standard was published.
The existing semantics pose a problem in the sample program I
posted in my previous article, which you snipped in your followup.
You know, the one that died with a segmentation fault. Sheesh.
--
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-18 12:51 -0700 |
| Message-ID | <fe3a8696-a75d-49b7-bdea-2818a8412547@googlegroups.com> |
| In reply to | #92480 |
On Thursday, August 18, 2016 at 2:19:10 PM UTC-5, Keith Thompson wrote:
> I'm not talking about "all programs", just a handful of standard library
> functions that make it too easy to violate const-correctness.
If you're not complaining about the existence of a const-safety hole, but
merely the fact that strchr can breach it without a typecast, I have no
agreement. I thought you were objecting to the hole's existence.
> > Besides, the only time the existing semantics would pose a problem would be
> > if compiler writers wanted to perform optimizations that wouldn't become
> > practical until long after the C89 Standard was published.
>
> The existing semantics pose a problem in the sample program I
> posted in my previous article, which you snipped in your followup.
> You know, the one that died with a segmentation fault. Sheesh.
The existing semantics say that the program produces UB, and I can't think
of any particularly useful semantics the program should have on a system
which includes write-protected storage. I thus don't see a problem.
On the other hand, given something like:
void f1(int const *p); // Code not visible to compiler
void f2(void);
int foo(void)
{
int x=1;
f1(&x);
x++;
f2();
return x;
}
the lack of a pointer qualifier to say that the outside function won't
modify *x nor persist x means that even if there were a callee-saved
register available to hold x across the function calls, the compiler
would have to reload x from storage after calling f1, write the updated
value to storage before calling f2, and reload the value of x again
after calling f2. If a suitable pointer qualifier existed, even a very
simplistic compiler could eliminate two indirect reads and an indirect
write.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-18 14:58 -0700 |
| Message-ID | <lnr39lhh92.fsf@kst-u.example.com> |
| In reply to | #92481 |
supercat@casperkitty.com writes:
> On Thursday, August 18, 2016 at 2:19:10 PM UTC-5, Keith Thompson wrote:
>> I'm not talking about "all programs", just a handful of standard library
>> functions that make it too easy to violate const-correctness.
>
> If you're not complaining about the existence of a const-safety hole,
> but merely the fact that strchr can breach it without a typecast, I
> have no agreement. I thought you were objecting to the hole's
> existence.
Do you mean we have no *disagreement*?
Of course there are plenty of ways to breach const-correctness, mostly
involving casts -- and the fact that string literals aren't const is
another problem (but I understand the historical reasons for it). I
just would prefer it if the standard library didn't *help* to breach
const-correctness.
>> > Besides, the only time the existing semantics would pose a problem
>> > would be if compiler writers wanted to perform optimizations that
>> > wouldn't become practical until long after the C89 Standard was
>> > published.
>>
>> The existing semantics pose a problem in the sample program I
>> posted in my previous article, which you snipped in your followup.
>> You know, the one that died with a segmentation fault. Sheesh.
>
> The existing semantics say that the program produces UB, and I can't think
> of any particularly useful semantics the program should have on a system
> which includes write-protected storage. I thus don't see a problem.
The problem is that a program that appears innocuous, which performs no
casts, quietly violates const-correctness and exhibits undefined
behavior.
[snip more stuff I wasn't talking about]
--
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-18 15:36 -0700 |
| Message-ID | <685af4c4-9605-4c13-a723-0d40645d2054@googlegroups.com> |
| In reply to | #92482 |
On Thursday, August 18, 2016 at 3:24:41 PM UTC-5, Keith Thompson wrote: > supercat writes: > > If you're not complaining about the existence of a const-safety hole, > > but merely the fact that strchr can breach it without a typecast, I > > have no agreement. I thought you were objecting to the hole's > > existence. > > Do you mean we have no *disagreement*? Yes. > Of course there are plenty of ways to breach const-correctness, mostly > involving casts -- and the fact that string literals aren't const is > another problem (but I understand the historical reasons for it). I > just would prefer it if the standard library didn't *help* to breach > const-correctness. Compilers aren't expected detect most forms of UB prior to program execution, and given all the defined ways that programs can use things like memcpy to move pointers around would mean that some programs with defined behavior would not be statically verifiable even if there were no way to breach pointer-const-correctness without UB. That raises a practicality question, however: if one wants to minimize code duplication, is it better to cast pointers going into functions that will "pass them through" to code that may or may not need to write them, require the casts in the cases where code may need to write the pointers, or place the casts in the pass-through functions so as to avoid the need to include casts elsewhere? If pointer-const-correctness cannot be violated without UB, achieving correct behavior with clean compiles will require cluttering a lot of code with casts that could have been avoided with other approaches. > The problem is that a program that appears innocuous, which performs no > casts, quietly violates const-correctness and exhibits undefined > behavior. Compilers cannot reasonably be expected to catch all possible problems that could cause UB.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-18 09:14 -0700 |
| Message-ID | <616fcb25-ec87-4400-b33a-b789197cb8a8@googlegroups.com> |
| In reply to | #92463 |
On Thursday, August 18, 2016 at 4:40:17 PM UTC+1, David Brown wrote: > > What C is missing is a good way to say "Here is an object that is > initially mutable so that I can set it up. But now that it has been > initialised, it will never change again". (Even C++ could not do that > well until C++14, I think.) However, I doubt if it would be /that/ > useful, and you could get a reasonable substitute by starting with a > mutable object (or pointer to one), doing the initialisation, then using > it to initialise a const (or pointer-to-const), then letting the > original non-const object or pointer go out of scope. > That's certainly one very common situation. Another one is caching. Often you want to attach intermediate results to a high-level object to avoid repeating the same work, but you don't actually want to change the meaning of the object. C++ allows "mutable". But that's just asking for "immutable" and you get the common programming "spoof problem" (program one pretends to be a human to drive program two, which expects user input, then program two wants to know if it is really being driven by a human or an automatic script, then program one pretends to be a real human to fool program two into behaving in the "right" way). > > That is a challenge for const correctness. > As soon as you use a term like "const correctness" you know that the idea has got out of control. The problem is const poisoning, everything that const touches becomes const. So we provide a function pointer, which takes a void * context pointer. But our context isn't in fact modified by the function. So now we need a crazy interface whereby the context pointer can be const void* or void * controlled by a flag, just to solve the problem the compiler has created for us. And it's not as is there's much danger of accidentally corrupting a constant context, it's not that it can't happen, but it's not a common sort of bug - the whole system is driven by the fact that const is relatively easy for the compiler to detect, not because it gives something very helpful to the programmer. The best solution is to deprecate and eliminate const. Just get rid of it. const correctness is a burden we don't need and offers us only a few very slight advantages.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-18 09:37 -0700 |
| Message-ID | <0a1c13eb-331a-4419-9ed4-68bc4f5096d7@googlegroups.com> |
| In reply to | #92463 |
On Thursday, August 18, 2016 at 10:40:17 AM UTC-5, David Brown wrote:
> If you have a pointer-to-const pointing at an object, and convert it to
> a different type in order to change the object, then the behaviour is
> undefined. You have already promised not to do this by using C -
> re-stating this promise in some way is unnecessary.
Casting away a const qualifier and writing to the resulting pointer is only
UB if the underlying storage is in fact declared "const". Given:
#include <string.h>
#include <stdio.h>
int main(void)
{
char fred[5] = "FRED";
char const *p1 = fred;
char *p2 = strchr(p1,'D');
*p2 = 'E';
printf(p1);
return 0;
}
the assignment to *p2 will be well-defined even though the pointer was
derived from a const-qualified pointer.
> > "object will not be changed via
> > pointer nor any pointer derived from it" [meaning that if the compiler
> > knows there would be no *other* way for the object to change, it could
> > assume it won't change at all],
>
> pointer-to-const gives you exactly that.
No it doesn't. See above. The strchr function takes a const-qualified
argument, but if the pointer given to it identifies a non-const object, the
object can be modified using the pointer returned by strchr.
> > and "object will not be changed via any
> > means whatsoever, so the compiler may safely cache any value read via
> > the pointer without regard for aliasing".
>
> Declaring the object as "const" in the first place gives you that.
Only in cases where the value of the object can be established at compile
time.
> What C is missing is a good way to say "Here is an object that is
> initially mutable so that I can set it up. But now that it has been
> initialised, it will never change again". (Even C++ could not do that
> well until C++14, I think.) However, I doubt if it would be /that/
> useful, and you could get a reasonable substitute by starting with a
> mutable object (or pointer to one), doing the initialisation, then using
> it to initialise a const (or pointer-to-const), then letting the
> original non-const object or pointer go out of scope.
One can't use a statically or automatically-object that's qualified "const"
for that purpose, and there's no form of "const" qualifier that would give
the appropriate semantics to anything else. Further, even if there were
such a qualifier, a compiler could only achieve the optimizations in
question would be if it could determine that no unconstrained pointers to
the object could possibly exist. Requiring a compiler to figure that out
seems far less reasonable than adding a qualifier that would tell the
compiler "this pointer will only identify things whose value will never
change throughout their remaining lifetime".
> supercat:
> > 2. A means of indicating that a function's return type should be regarded
> > as having qualifiers derived from argument types. If such a means had
> > predated strchr, its prototype could be something like:
> >
> > char *strchr(char return *str, char chr);
> >
> > thus allowing:
> >
> > char Fred[5] = "Fred";
> > const char Kate[5] = "Kate";
> > const char *st3 = strchr(Fred, ch); // Strchr returns non-const
> > char *st2 = strchr(Fred, ch);
> > const char *st1 = strchr(Kate, ch); // Strchr returns const
> >
> > but not
> >
> > char *st4 = strchr(Kate, ch);
> >
> > since the return from that strchr call would be const-qualified as a
> > consequence of the argument being likewise.
>
> That is a challenge for const correctness. C takes the attitude that it
> can't be done nicely in C (you'd need two versions of the strchr
> function, and it would be up to the user to pick the right one) - so it
> gives you a single version that takes a "const char *" and returns a
> "char *". This function can't be written by the user in a fully
> portable manner, because it contains undefined behaviour - but it's fine
> for the standard library because that can use whatever
> implementation-defined behaviour is needed to make it safe. It is then
> up to the user to keep it safe - there is no compile-time checking.
The strchr function doesn't need any special magic for that. There were
plenty of other similar functions in user code which needed the ability to
operate on both const- and non-const data, and I've seen no evidence that
the authors of the Standard intended to force such functions to be split
into separate "const" and "non-const" versions; indeed, I believe they
expressly indicated a desire *not* to force such splits.
The proper remedy would have been to have a "return" qualifier such that
char *strchr(char const return *st, const ch);
would apply to the return type any qualifiers that were present on return-
qualified arguments, but the Standard never did such a thing.
> C++ takes the attitude that it /can/ be done - you just make two
> overloaded functions, and thus get compile-time checking. The cost is
> that the implementation will be repetitive (templates and a smart
> compiler/linker can give you efficient end results).
In my limited experience with C++, I couldn't get it to properly handle
overloading of functions which differed only in const-ness. Further,
something seems wrong to be about the idea that programmers should be
forced to duplicate code to allow a compiler to perform some optimizations
that may or may not actually buy anything.
> > Incidentally, C would also benefit enormously from having a distinction
> > between pointer arguments that will not be copied to anything that outlives
> > the function call, those that may be returned but not otherwise copied, and
> > those which may be copied beyond the function call.
>
> I don't know how "enormously" beneficial this would be, but it would
> certainly certain types of optimisations.
It would enable optimziations, and especially if there were a means by
which prototypes of variadic functions could apply it to their arguments,
would also allow compilers to warn about many cases where the addresses of
automatic variables get exposed to the outside world without generating a
ton of nuisance warnings when the addresses are passed to functions that
won't persist them.
> More useful, I think, would be some sort of "transitive const" to solve
> Bart's problem where const pointers into a idiomatic linked list
> structure can be used to change elements on the list despite the
> "const". But again, this is outside the scope of C - you can write safe
> functions if you want, but that is up to the user. If you want the
> tools needed to enforce this sort of thing, look for C++.
The set of reliably-useful semantics of C has been steadily degrading in
pursuit of "optimization". I view such an approach as both dangerous and
counterproductive. If it is necessary to facilitate optimizations, that
should be accomplished by adding new ways of giving the compiler information
about how storage will be used, rather than trying to limit how programmers
can use it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-17 17:58 -0700 |
| Message-ID | <lnoa4qki57.fsf@kst-u.example.com> |
| In reply to | #92417 |
BartC <bc@freeuk.com> writes:
> On 17/08/2016 23:37, Malcolm McLean wrote:
>> On Wednesday, August 17, 2016 at 9:46:18 PM UTC+1, Bart wrote:
>>> On 17/08/2016 21:33, jameskuyper@verizon.net wrote:
>>>
>>> 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?
>>>
>> To get an array you need to obtain a buffer, then put data into it.
>> The data is then your array, it's an array of data, not of memory
>> elements. Just as an array of soldiers is the men, not the
>> spaces on the parade ground they occupy.
>>
>> The C standard misuses the term array to include buffers, which is
>> one source of confusion. Then it is a little glitch that a pointer
>> to a datum and a pointer to a buffer are not distinguished, but of
>> course normally they will resolve to the same machine operations.
>> It works reasonably well.
>
> But I'm starting to discover it doesn't actually work that well at all.
Bart, I suggest you ignore Malcolm's comments on this matter.
He's invented some ludicrous distinction between "arrays" and
"buffers", where what he calls "arrays" are *not* C arrays.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-17 16:46 -0700 |
| Message-ID | <3b468188-f048-48de-9aaa-eaadd06133d0@googlegroups.com> |
| In reply to | #92425 |
On Thursday, August 18, 2016 at 12:32:13 AM UTC+1, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > > On 17/08/2016 23:37, Malcolm McLean wrote: > >> On Wednesday, August 17, 2016 at 9:46:18 PM UTC+1, Bart wrote: > >>> On 17/08/2016 21:33, jameskuyper@verizon.net wrote: > >>> > >>> 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? > >>> > >> To get an array you need to obtain a buffer, then put data into it. > >> The data is then your array, it's an array of data, not of memory > >> elements. Just as an array of soldiers is the men, not the > >> spaces on the parade ground they occupy. > >> > >> The C standard misuses the term array to include buffers, which is > >> one source of confusion. Then it is a little glitch that a pointer > >> to a datum and a pointer to a buffer are not distinguished, but of > >> course normally they will resolve to the same machine operations. > >> It works reasonably well. > > > > But I'm starting to discover it doesn't actually work that well at all. > > Bart, I suggest you ignore Malcolm's comments on this matter. > He's invented some ludicrous distinction between "arrays" and > "buffers", where what he calls "arrays" are *not* C arrays. > The term "buffer" and the term "array" are not my invention. Nor did I invent the military parade ground or the infantry square and musket tactics which necessitated the development of drill. Some things are genuinely my invention, but not these.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-17 19:03 -0700 |
| Message-ID | <ln8tvukf45.fsf@kst-u.example.com> |
| In reply to | #92430 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, August 18, 2016 at 12:32:13 AM UTC+1, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> > On 17/08/2016 23:37, Malcolm McLean wrote:
[...]
>> >> To get an array you need to obtain a buffer, then put data into it.
>> >> The data is then your array, it's an array of data, not of memory
>> >> elements. Just as an array of soldiers is the men, not the
>> >> spaces on the parade ground they occupy.
>> >>
>> >> The C standard misuses the term array to include buffers, which is
>> >> one source of confusion. Then it is a little glitch that a pointer
>> >> to a datum and a pointer to a buffer are not distinguished, but of
>> >> course normally they will resolve to the same machine operations.
>> >> It works reasonably well.
>> >
>> > But I'm starting to discover it doesn't actually work that well at all.
>>
>> Bart, I suggest you ignore Malcolm's comments on this matter.
>> He's invented some ludicrous distinction between "arrays" and
>> "buffers", where what he calls "arrays" are *not* C arrays.
>>
> The term "buffer" and the term "array" are not my invention.
[...]
Ok, but whether you personally invented the terms is not the issue.
You are deliberately using the word "array" with a meaning that is
inconsistent with the way the C standard uses the word, and you are
doing it in a thread discussing the semantics of C arrays. You are
just making matters even more confusing than they already are.
Whatever it is you mean by "array", please find another term for it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-18 01:55 +0100 |
| Message-ID | <8760qyuc9n.fsf@bsb.me.uk> |
| In reply to | #92417 |
BartC <bc@freeuk.com> writes: <snip> > But I'm starting to discover it doesn't actually work that well at all. > > Every time you declare or come across a pointer: to a single int, to > an array of ints, to anything at all, then the language can't get away > from the fact that that pointer COULD be pointing to a bunch of those > things, not just one. How long have you been using C? <snip> > Someone declares int(*A)[] and uses it as a 1D table. (you need a size in there) > 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, but I've had some practice at trying to find explanations that reduce the number of principles the need to be understood. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-18 11:04 +0100 |
| Message-ID | <np4185$cu6$1@dont-email.me> |
| In reply to | #92441 |
On 18/08/2016 01:55, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > <snip> >> But I'm starting to discover it doesn't actually work that well at all. >> >> Every time you declare or come across a pointer: to a single int, to >> an array of ints, to anything at all, then the language can't get away >> from the fact that that pointer COULD be pointing to a bunch of those >> things, not just one. > > How long have you been using C? I've been using it to implement MY data structures. > <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. >> 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? This stuff could be completely open and completely obvious. There should be no ambiguity. -- Bartc but I've had some > practice at trying to find explanations that reduce the number of > principles the need to be understood. >
[toc] | [prev] | [next] | [standalone]
Page 17 of 20 — ← Prev page 1 … 15 16 [17] 18 19 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web