Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #77859 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2015-12-04 16:06 -0800 |
| Last post | 2015-12-10 10:00 -0800 |
| Articles | 20 on this page of 400 — 31 participants |
Back to article view | Back to comp.lang.c
Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-04 16:06 -0800
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-05 13:15 +1300
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-04 16:19 -0800
Re: Prefix and postfix Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 01:18 +0000
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-04 20:33 -0500
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-05 07:55 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-05 09:09 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-05 11:40 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-06 23:33 +0100
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-06 23:10 +0000
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-06 15:34 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 10:14 +0100
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 16:11 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 00:27 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 01:15 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 00:13 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 01:26 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-07 14:51 +1300
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 02:25 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-07 15:55 +1300
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 11:13 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 11:32 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 12:55 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 12:14 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 12:29 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:49 +0100
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:47 +0100
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-07 14:11 +0000
Re: Prefix and postfix Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2015-12-13 00:39 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 01:17 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-12 18:21 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-13 08:31 +0000
Re: Prefix and postfix Udyant Wig <udyantw@gmail.com> - 2015-12-13 15:12 +0530
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-13 03:40 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 11:41 +0000
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-07 12:55 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-07 11:46 -0800
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-08 01:07 +0000
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-07 09:11 -0500
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 15:26 +0100
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-07 08:25 -0500
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-07 13:59 +0000
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-07 09:06 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 14:12 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-07 08:36 -0800
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-07 21:01 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-07 15:16 -0800
Re: Prefix and postfix Ken Brody <kenbrody@spamcop.net> - 2015-12-08 13:58 -0500
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-07 12:11 -0500
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 11:06 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:02 +0100
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 14:37 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 15:17 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 21:39 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 23:04 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-08 01:19 +0000
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-08 01:12 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-08 09:11 +0100
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 17:19 +0100
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 22:50 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-08 01:26 +0100
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-08 01:27 +0000
Re: Prefix and postfix Udyant Wig <udyantw@gmail.com> - 2015-12-09 17:22 +0530
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-09 13:15 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-09 13:07 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-08 07:54 +1300
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 23:41 +0100
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-07 17:50 -0500
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-07 19:43 -0500
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 23:14 +0000
Re: Prefix and postfix David Thompson <dave.thompson2@verizon.net> - 2015-12-22 06:45 -0500
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-07 12:00 -0500
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 09:04 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 19:59 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 12:14 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 12:45 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 19:56 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 01:58 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 11:48 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 19:09 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 19:41 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 23:26 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 11:38 +0100
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 02:52 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:04 +0100
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 05:10 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 13:57 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 08:20 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 08:42 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 17:19 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 09:27 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 17:41 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 09:46 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 09:50 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 18:09 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 10:17 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-07 10:21 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 15:33 +0100
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 08:50 -0800
Re: Prefix and postfix Richard Damon <Richard@Damon-Family.org> - 2015-12-07 13:43 -0500
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 10:54 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 11:00 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:07 +0100
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-07 04:19 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:58 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 12:32 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 20:57 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-08 00:10 +0100
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-07 15:40 -0800
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-08 12:55 +1300
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-08 00:43 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-08 01:28 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-08 01:53 +0000
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-08 16:44 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-08 17:47 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-08 10:46 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-08 19:27 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-08 12:30 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-08 12:37 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-08 21:47 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-08 23:20 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-09 01:15 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-09 02:07 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-09 13:24 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-09 14:54 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-09 15:20 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-09 07:59 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-09 21:43 +0000
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-09 08:45 -0800
Re: Prefix and postfix David Thompson <dave.thompson2@verizon.net> - 2015-12-22 06:45 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-08 19:20 -0800
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-10 21:01 +0000
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-10 16:31 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-10 14:03 -0800
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-11 02:16 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 10:20 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-11 02:24 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 10:39 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-11 03:20 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 12:02 +0000
Re: Prefix and postfix Ken Brody <kenbrody@spamcop.net> - 2015-12-11 13:06 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-10 21:46 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-11 10:57 +1300
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-10 22:09 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-11 11:22 +1300
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-10 17:27 -0500
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-10 23:07 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 00:11 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 00:25 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 01:42 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 02:36 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 02:55 +0000
Re: Prefix and postfix Udyant Wig <udyantw@gmail.com> - 2015-12-11 20:04 +0530
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-11 02:22 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 10:33 +0000
Re: Prefix and postfix Ken Brody <kenbrody@spamcop.net> - 2015-12-11 13:28 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-11 12:30 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 11:23 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 12:38 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 14:21 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 14:55 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 15:19 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 15:28 +0000
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-11 08:46 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-11 12:18 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-11 12:27 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-11 17:30 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-11 08:51 -0800
Re: Prefix and postfix Philip Lantz <prl@canterey.us> - 2015-12-17 10:55 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-17 11:24 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-11 18:04 +0100
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-12 08:58 +1300
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 22:08 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-12 11:32 +1300
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 22:48 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-12 11:57 +1300
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-11 15:33 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 23:43 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-11 20:37 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-11 23:23 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-12 00:01 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-12 02:15 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-12 11:15 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-13 00:52 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 02:05 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-12 18:35 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 13:35 +0000
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-13 11:48 -0800
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-13 20:36 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-13 13:14 -0800
Re: Prefix and postfix Gareth Owen <gwowen@gmail.com> - 2015-12-13 21:38 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 22:35 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-13 14:48 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 23:05 +0000
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-13 18:08 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-13 15:44 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-14 00:42 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-13 19:48 -0800
Re: Prefix and postfix Gareth Owen <gwowen@gmail.com> - 2015-12-14 06:58 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-14 00:04 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 12:12 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-14 08:07 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 17:23 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-14 10:58 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-14 12:29 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 14:52 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-14 19:37 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 20:33 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-15 09:45 +1300
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-14 13:16 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 21:34 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-14 21:45 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 22:00 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-14 22:23 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-14 14:41 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 23:38 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 00:50 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-14 17:00 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-15 01:20 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 11:41 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-15 04:03 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 12:47 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-15 05:42 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 14:11 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-15 06:24 -0800
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-15 17:13 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 08:57 -0800
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-15 11:05 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 03:52 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-16 05:38 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-15 22:30 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-16 11:17 +0100
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 05:38 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-16 15:02 +0100
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 06:10 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-16 14:47 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 07:09 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 08:11 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 09:04 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 09:21 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 15:19 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-16 07:33 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 15:34 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 15:54 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 21:11 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 22:36 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 15:33 -0800
Re: Prefix and postfix ais523 <ais523@nethack4.org> - 2015-12-24 09:02 +0000
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-25 09:12 -0800
Re: Prefix and postfix ais523 <ais523@nethack4.org> - 2015-12-28 07:15 +0000
Re: Prefix and postfix Philip Lantz <prl@canterey.us> - 2015-12-27 18:40 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-17 00:39 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-17 02:22 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-16 11:00 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 16:06 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 08:52 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 21:24 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 16:04 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-17 00:55 +0000
Re: Prefix and postfix Gareth Owen <gwowen@gmail.com> - 2015-12-17 19:45 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-17 01:54 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-16 22:43 -0500
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-17 04:34 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-17 08:46 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 23:45 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 16:14 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-17 14:12 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-17 22:42 +0000
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 18:21 -0500
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 18:43 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-18 00:21 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-17 17:01 -0800
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-16 22:38 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-17 06:25 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 17:10 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-17 15:04 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 17:24 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 12:26 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 14:46 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-16 07:14 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 07:28 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 15:28 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-16 07:40 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-16 16:58 +0100
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-16 09:02 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-17 13:58 +0100
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-17 09:38 -0800
Re: Prefix and postfix Les Cargill <lcargill99@comcast.com> - 2015-12-17 12:31 -0600
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-17 21:07 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-18 11:35 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-18 11:12 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-19 15:08 +0100
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-19 19:36 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-19 21:08 +0100
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-20 00:48 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-20 09:51 +0100
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-19 12:09 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-19 23:13 +0100
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-19 14:50 -0800
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-19 17:18 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-19 14:56 -0800
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-19 18:04 -0500
Re: Prefix and postfix David Thompson <dave.thompson2@verizon.net> - 2015-12-28 05:12 -0500
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-19 21:42 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-20 09:42 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-20 08:54 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-21 17:04 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-21 18:34 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-22 15:47 +1300
Re: Prefix and postfix Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2015-12-22 07:09 +0100
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-22 21:56 +1300
Re: Prefix and postfix Melzzzzz <mel@zzzzz.com> - 2015-12-22 12:12 +0100
Re: Prefix and postfix Paul <nospam@needed.com> - 2015-12-22 06:49 -0500
Re: Prefix and postfix Melzzzzz <mel@zzzzz.com> - 2015-12-22 14:44 +0100
Re: Prefix and postfix David Thompson <dave.thompson2@verizon.net> - 2015-12-28 05:13 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-20 21:45 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-20 19:04 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-21 10:51 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-21 12:22 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-20 21:49 +1300
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-20 06:36 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-20 18:42 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-20 15:28 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-20 09:17 -0800
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-21 08:10 +1300
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-21 08:06 +1300
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-20 19:58 +0000
Re: Prefix and postfix "D. Lowe" <d.lowe@openmailbox.org> - 2015-12-20 21:16 +0000
Re: Prefix and postfix "D. Lowe" <d.lowe@openmailbox.org> - 2015-12-20 21:22 +0000
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-20 16:39 -0500
Re: Prefix and postfix "D. Lowe" <d.lowe@openmailbox.org> - 2015-12-20 21:57 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-18 11:18 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-18 11:50 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-18 04:04 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-18 22:56 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-18 20:28 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-19 22:13 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-18 09:31 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-18 08:44 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-19 12:44 -0800
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-19 11:59 +1300
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-19 15:18 +0100
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-20 11:32 +1300
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-20 09:58 +0100
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 17:05 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-16 21:27 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-17 02:39 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 08:20 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 15:52 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 18:51 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 08:19 -0800
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-17 00:16 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-15 11:07 +1300
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-14 19:53 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 01:14 +0000
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-14 20:42 -0500
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-14 20:50 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 02:00 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-14 21:27 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 10:45 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-15 03:20 -0800
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-15 08:25 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 14:38 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-15 11:12 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 08:53 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 18:10 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 11:50 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 20:13 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 13:21 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 22:13 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 16:40 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 01:48 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 23:56 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 11:38 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 14:11 +0000
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-15 17:23 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 02:51 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-14 08:18 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-14 09:10 -0800
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-14 09:22 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-14 12:28 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-14 09:41 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-14 11:13 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-14 12:42 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-14 09:05 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-13 12:24 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-13 13:17 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-11 19:56 -0500
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-11 20:09 -0500
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-11 12:44 -0500
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-11 21:52 +0000
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-13 20:25 +0000
Re: Prefix and postfix Ken Brody <kenbrody@spamcop.net> - 2015-12-11 12:58 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-08 11:54 -0800
Re: Prefix and postfix Tim Rentsch <txr@alumni.caltech.edu> - 2015-12-09 11:59 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-08 09:41 +0100
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-08 09:45 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 00:31 +0000
Re: Prefix and postfix John Bode <jfbode1029@gmail.com> - 2015-12-10 08:56 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-10 10:00 -0800
Page 3 of 20 — ← Prev page 1 2 [3] 4 5 … 20 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-12-07 08:25 -0500 |
| Message-ID | <n44189$sps$1@dont-email.me> |
| In reply to | #78050 |
On 12/07/2015 06:19 AM, Stefan Ram wrote: > BartC <bc@freeuk.com> writes: >> In a language where 'a=b' doesn't return a value, then: >> a = b; >> is not an expression, but a statement. > > It seems to assume that in C, �a=b� returns a value. > But this is false. It might have a value, but does not > return a value. The C standard speaks in terms of expressions having a result, rather than in terms of them returning values. I wouldn't fault BartC for making this mistake - I've made it myself, and he routinely makes much worse ones. The expression a=b does in fact have a result in C, and this would not be the case in his hypothetical language: it would not be an expression, and it would not have a result. > It seems to assume that in C, �a=b;� is an expression. In C, a=b is an expression, and a=b; is an expression-statement. In the hypothetical language he's talking about, since a=b would not be an expression, a=b; could not be an expression statement, so it would have to be a special statement type of it's own. An [optionally compound] assignment operator would be a key component in the grammar of an assignment-statement. He's not using quite the right terminology to make the comparison with C clear, but it isn't that bad. > It seems to assume that in a hypothetical language > which is not being described in more details, �a=b;� > is a statement. He's not assuming that, he's describing one of those details. The way he's worded it, the language he's talking about is identified as BEING the language that he's talking about by the fact that it possesses this feature. As such, the description is inherently correct. It might have other problems, such as being unimplementable or a bad idea (I don't think either one applies - I personally think C might have been better off if initially designed that way), but it inherently cannot be wrong. > ... But this is false. What �a=b;� is in > that hypothetical language would be given by the specification > of that language. Yes, and he's telling you what that specification says. > ... Since we do not have that specification, He's describing for you what that specification says, so you do have it, or at least enough of the specification to understand what he's saying. > we cannot know what it is in that language. Well, if you refuse to recognize as such his description of what that language's specification says, you can't know what it is - but that says more about you than about his description. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-12-07 13:59 +0000 |
| Message-ID | <n443br$o4b$1@speranza.aioe.org> |
| In reply to | #78075 |
James Kuyper <jameskuyper@verizon.net> wrote: > On 12/07/2015 06:19 AM, Stefan Ram wrote: (snip) >> It seems to assume that in C, �a=b� returns a value. >> But this is false. It might have a value, but does not >> return a value. > The C standard speaks in terms of expressions having a result, rather > than in terms of them returning values. I wouldn't fault BartC for > making this mistake - I've made it myself, and he routinely makes much > worse ones. > The expression a=b does in fact have a result in C, and this would not > be the case in his hypothetical language: it would not be an expression, > and it would not have a result. >> It seems to assume that in C, �a=b;� is an expression. > In C, a=b is an expression, and a=b; is an expression-statement. In the > hypothetical language he's talking about, since a=b would not be an > expression, a=b; could not be an expression statement, so it would have > to be a special statement type of it's own. An [optionally compound] > assignment operator would be a key component in the grammar of an > assignment-statement. He's not using quite the right terminology to make > the comparison with C clear, but it isn't that bad. It doesn't seem so hard to do. Java allows assignment expressions and method invocation as statements, but not other expressions. In Java 2+2 isn't a statement, and there isn't much reason for allowing it in C. A good compiler will optimize it out, maybe even a not so good one. It is interesting to allow simplify the language definition by allowing all expressions as statements, but doesn't help much in actual use. >> It seems to assume that in a hypothetical language >> which is not being described in more details, �a=b;� >> is a statement. > He's not assuming that, he's describing one of those details. The way > he's worded it, the language he's talking about is identified as BEING > the language that he's talking about by the fact that it possesses this > feature. As such, the description is inherently correct. It might have > other problems, such as being unimplementable or a bad idea (I don't > think either one applies - I personally think C might have been better > off if initially designed that way), but it inherently cannot be wrong. Being unimplementable, especially being ambiguous, can be a problem. One not yet mentioned is the problem of not having reserved words. In Fortran and PL/I, you can't have a function call as a statement by itself, as it would be ambiguous with some actual statements. Both languages have the CALL statement for non-function prodedure calls. I believe Java allows for ignoring the return value on non-void methods. One might argue that is a mistake. >> ... But this is false. What �a=b;� is in >> that hypothetical language would be given by the specification >> of that language. > Yes, and he's telling you what that specification says. >> ... Since we do not have that specification, > He's describing for you what that specification says, so you do have it, > or at least enough of the specification to understand what he's saying. >> we cannot know what it is in that language. > Well, if you refuse to recognize as such his description of what that > language's specification says, you can't know what it is - but that says > more about you than about his description. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-12-07 09:06 -0500 |
| Message-ID | <n443jp$734$1@dont-email.me> |
| In reply to | #78080 |
On 12/7/2015 8:59 AM, glen herrmannsfeldt wrote:
>
> Java allows assignment expressions and method invocation as statements,
> but not other expressions.
>
> In Java 2+2 isn't a statement, and there isn't much reason for
> allowing it in C. A good compiler will optimize it out, maybe
> even a not so good one.
>
> It is interesting to allow simplify the language definition by
> allowing all expressions as statements, but doesn't help much
> in actual use.
#define NDEBUG
assert("Counterexample?");
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-07 14:12 +0000 |
| Message-ID | <n443vr$8jc$1@dont-email.me> |
| In reply to | #78080 |
On 07/12/2015 13:59, glen herrmannsfeldt wrote: > James Kuyper <jameskuyper@verizon.net> wrote: >> In C, a=b is an expression, and a=b; is an expression-statement. In the > In Java 2+2 isn't a statement, and there isn't much reason for > allowing it in C. A good compiler will optimize it out, maybe > even a not so good one. When implementing a recent language with a sharp division between assignments and statements, there were a number of constructs that were useful in both. Those constructs existed internally as separate but parallel features. Features occurring in both expressions, and as standalone statements: - Assignment - Increment - Function call In expressions only: - Expressions In statements only: - Compound assignment (+= etc) To evaluate an expression, and then to ignore the value, would need a special statement for that purpose (eg. 'evaluate x+y;', although I haven't bothered yet). Statement versions of assignment, increment and function call are also much easier to implement than their expression counterparts. > It is interesting to allow simplify the language definition by > allowing all expressions as statements, but doesn't help much > in actual use. I used to allow just that. Fortunately it was just me that used the language and the code remained sane. Some people however do like to pull out all the stops if presented with the opportunity. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-07 08:36 -0800 |
| Message-ID | <lnvb8anrlo.fsf@kst-u.example.com> |
| In reply to | #78075 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 12/07/2015 06:19 AM, Stefan Ram wrote:
>> BartC <bc@freeuk.com> writes:
>>> In a language where 'a=b' doesn't return a value, then:
>>> a = b;
>>> is not an expression, but a statement.
>>
>> It seems to assume that in C, �a=b� returns a value.
>> But this is false. It might have a value, but does not
>> return a value.
>
> The C standard speaks in terms of expressions having a result, rather
> than in terms of them returning values. I wouldn't fault BartC for
> making this mistake - I've made it myself, and he routinely makes much
> worse ones.
The standard terminology is that a function *returns* a value and an
expression *yields* a result. But I've seen a draft of the standard
itself refer to an expression returning a value. I think any such
glitches have been corrected in the current standard.
[...]
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-12-07 21:01 +0000 |
| Message-ID | <n44s31$jpr$1@speranza.aioe.org> |
| In reply to | #78097 |
Keith Thompson <kst-u@mib.org> wrote: > James Kuyper <jameskuyper@verizon.net> writes: (snip) >> The C standard speaks in terms of expressions having a result, rather >> than in terms of them returning values. I wouldn't fault BartC for >> making this mistake - I've made it myself, and he routinely makes much >> worse ones. > The standard terminology is that a function *returns* a value and an > expression *yields* a result. But I've seen a draft of the standard > itself refer to an expression returning a value. I think any such > glitches have been corrected in the current standard. Does getchar() yield a value or return a result? As I understand a popular implementation, it is a macro that either yields a value out of a buffer, or returns a result from a function call to do actual I/O. Or is just looking like a function call enough? -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-07 15:16 -0800 |
| Message-ID | <lnmvtlonnl.fsf@kst-u.example.com> |
| In reply to | #78133 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>
> (snip)
>>> The C standard speaks in terms of expressions having a result, rather
>>> than in terms of them returning values. I wouldn't fault BartC for
>>> making this mistake - I've made it myself, and he routinely makes much
>>> worse ones.
>
>> The standard terminology is that a function *returns* a value and an
>> expression *yields* a result. But I've seen a draft of the standard
>> itself refer to an expression returning a value. I think any such
>> glitches have been corrected in the current standard.
>
> Does getchar() yield a value or return a result?
>
> As I understand a popular implementation, it is a macro that either
> yields a value out of a buffer, or returns a result from a function
> call to do actual I/O.
>
> Or is just looking like a function call enough?
If getchar is a function, `getchar()` is an expression that yields a
result (a value) when it's evaluated, and `getchar` is a function that
returns a result (a value) when it's called.
If getchar is a macro, `getchar()` expands to an expression as above.
It's required to behave like a function call in most ways, so we can
still loosely say that `getchar` returns a result.
--
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 | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2015-12-08 13:58 -0500 |
| Message-ID | <n4793b$a90$1@dont-email.me> |
| In reply to | #78133 |
On 12/7/2015 4:01 PM, glen herrmannsfeldt wrote: > Keith Thompson <kst-u@mib.org> wrote: >> James Kuyper <jameskuyper@verizon.net> writes: > > (snip) >>> The C standard speaks in terms of expressions having a result, rather >>> than in terms of them returning values. I wouldn't fault BartC for >>> making this mistake - I've made it myself, and he routinely makes much >>> worse ones. > >> The standard terminology is that a function *returns* a value and an >> expression *yields* a result. But I've seen a draft of the standard >> itself refer to an expression returning a value. I think any such >> glitches have been corrected in the current standard. > > Does getchar() yield a value or return a result? > > As I understand a popular implementation, it is a macro that either > yields a value out of a buffer, or returns a result from a function > call to do actual I/O. > > Or is just looking like a function call enough? My take would be... "getchar()" is an expression which yields a value. If it happens to be implemented as a function, then the function named "getchar" returns a value, which is then used by the expression "getchar()" to yield its value. Seems perfectly clear to me. :-) -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-12-07 12:11 -0500 |
| Message-ID | <5665BDCC.8090609@verizon.net> |
| In reply to | #78050 |
On 12/07/2015 12:01 PM, Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> It seems to assume that in C, »a=b« returns a value.
>> But this is false. It might have a value, but does not
>> return a value.
>
> And in C, one can clearly show the difference!
>
> #include <stdio.h>
>
> void f( void ){ puts( "f" ); }
> typedef void( *ftype )( void );
> ftype g( void ){ return f; }
>
> int main( void )
> { ftype( *h )( void )= g;
>
> /* here,
> h /has/ the value g, but
> h /returns/ the value f.
The primary expression h has the value g, the function call expression
h() has the value f. The function g is called by using the function
pointer h, and that function returns the value f.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-07 11:06 +0000 |
| Message-ID | <87io4a1prs.fsf@bsb.me.uk> |
| In reply to | #78022 |
Ian Collins <ian-news@hotmail.com> writes:
<snip>
>> On 07/12/2015 00:13, Ben Bacarisse wrote:
<snip>
>>> But for me, the best advertisement for assignment as an expression is
>>> the pattern
>>>
>>> while ((c = getchar()) != EOF && c != '\n') {
>>> // ... do stuff with c ...
>>> }
<snip>
> I've had to take assignments out of expressions one too many times
> while debugging someone else's code to ever put them there in the
> first place.
I find that surprising and a little disappointing. What is it about
debugging that is hindered by embedded assignments? I presume that it's
something to do with the tools. I haven't used an interactive debugger
for C in anger for many years so maybe I have been naive in assuming
that they would have evolved to enable easy debugging of common language
patterns. I know that they used to be very much line-oriented but that
was in the 80s when I was often debugging Fortran for which that worked
just fine. Have they not moved on? And if not (since I don't imagine
you are alone in finding this frustrating) I wonder why not.
I often see annoyance about code patterns that hinder debugging, but not
so much annoyance at debugging tools that don't work for common code
patterns. That seems to me to be the wrong way round.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-07 13:02 +0100 |
| Message-ID | <n43sbs$a3r$1@dont-email.me> |
| In reply to | #78049 |
On 07/12/15 12:06, Ben Bacarisse wrote:
> Ian Collins <ian-news@hotmail.com> writes:
> <snip>
>>> On 07/12/2015 00:13, Ben Bacarisse wrote:
> <snip>
>>>> But for me, the best advertisement for assignment as an expression is
>>>> the pattern
>>>>
>>>> while ((c = getchar()) != EOF && c != '\n') {
>>>> // ... do stuff with c ...
>>>> }
> <snip>
>
>> I've had to take assignments out of expressions one too many times
>> while debugging someone else's code to ever put them there in the
>> first place.
>
> I find that surprising and a little disappointing. What is it about
> debugging that is hindered by embedded assignments? I presume that it's
> something to do with the tools. I haven't used an interactive debugger
> for C in anger for many years so maybe I have been naive in assuming
> that they would have evolved to enable easy debugging of common language
> patterns. I know that they used to be very much line-oriented but that
> was in the 80s when I was often debugging Fortran for which that worked
> just fine. Have they not moved on? And if not (since I don't imagine
> you are alone in finding this frustrating) I wonder why not.
>
> I often see annoyance about code patterns that hinder debugging, but not
> so much annoyance at debugging tools that don't work for common code
> patterns. That seems to me to be the wrong way round.
>
Debuggers tend to put a strong emphasis on lines - you set a breakpoint
on a line, you single-step line by line, etc. If you want to
conveniently step through pieces of code, it is much easier and clearer
if each operation, evaluation, function call, concept (or whatever you
want to call "bits of code") is on its own line.
It also makes it easier to use version control and diff viewing (which
is mostly line oriented), or code reviews.
As Ian said, different people have different points where we say "that
is a convenient and concise way to express the code" and where we say
"that is line noise". Experience with different types of tools may
influence that dividing point, as will experience with different
programmers and the code they write (there is nothing like fixing bugs
in other people's code to make you a fan of more conservative coding
styles).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-07 14:37 +0000 |
| Message-ID | <877fkq1g0i.fsf@bsb.me.uk> |
| In reply to | #78057 |
David Brown <david.brown@hesbynett.no> writes:
> On 07/12/15 12:06, Ben Bacarisse wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>> <snip>
>>>> On 07/12/2015 00:13, Ben Bacarisse wrote:
>> <snip>
>>>>> But for me, the best advertisement for assignment as an expression is
>>>>> the pattern
>>>>>
>>>>> while ((c = getchar()) != EOF && c != '\n') {
>>>>> // ... do stuff with c ...
>>>>> }
>> <snip>
>>
>>> I've had to take assignments out of expressions one too many times
>>> while debugging someone else's code to ever put them there in the
>>> first place.
>>
>> I find that surprising and a little disappointing. What is it about
>> debugging that is hindered by embedded assignments? I presume that it's
>> something to do with the tools. I haven't used an interactive debugger
>> for C in anger for many years so maybe I have been naive in assuming
>> that they would have evolved to enable easy debugging of common language
>> patterns. I know that they used to be very much line-oriented but that
>> was in the 80s when I was often debugging Fortran for which that worked
>> just fine. Have they not moved on? And if not (since I don't imagine
>> you are alone in finding this frustrating) I wonder why not.
>>
>> I often see annoyance about code patterns that hinder debugging, but not
>> so much annoyance at debugging tools that don't work for common code
>> patterns. That seems to me to be the wrong way round.
>>
>
> Debuggers tend to put a strong emphasis on lines - you set a breakpoint
> on a line, you single-step line by line, etc. If you want to
> conveniently step through pieces of code, it is much easier and clearer
> if each operation, evaluation, function call, concept (or whatever you
> want to call "bits of code") is on its own line.
That's odd (to me) because almost no languages put a string emphasis on
lines. I'd have thought debuggers would help with that, but if they
don't -- and the people who use them are content that they don't -- then
who am I to complain?
The great thing about Usenet is you get to see opinions that you'd never
otherwise see. The next time I see
while (1) {
c = getchar();
if (c == EOF || c == '\n') break;
...
}
I won't think "what shocking code" I'll think "ah, someone's debugger
needs a helping hand".
> It also makes it easier to use version control and diff viewing (which
> is mostly line oriented), or code reviews.
I've never found things like
while ((c = getchar()) != EOF && c != '\n') {
to be a problem in either code review or version control. I'm not
arguing for silly long lines, I'm commenting on having to remove
assignments from expressions because debuggers require you to do that.
> As Ian said, different people have different points where we say "that
> is a convenient and concise way to express the code" and where we say
> "that is line noise". Experience with different types of tools may
> influence that dividing point,
Sure, but we have an actual dividing line here. I wrote
while ((c = getchar()) != EOF && c != '\n') {
...
}
and BartC re-wrote it with a while (1) and a break and Ian then agreed.
It's the location of this specific dividing line that is interesting to
me. It's nowhere near where I thought it would be.
> as will experience with different
> programmers and the code they write (there is nothing like fixing bugs
> in other people's code to make you a fan of more conservative coding
> styles).
It did not have that effect on me, but then I don't consider BartC's
re-write to be conservative, either. It just looks clumsy to me.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-07 15:17 +0000 |
| Message-ID | <n447p9$nof$1@dont-email.me> |
| In reply to | #78090 |
On 07/12/2015 14:37, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> Debuggers tend to put a strong emphasis on lines - you set a breakpoint
>> on a line, you single-step line by line, etc. If you want to
>> conveniently step through pieces of code, it is much easier and clearer
>> if each operation, evaluation, function call, concept (or whatever you
>> want to call "bits of code") is on its own line.
>
> That's odd (to me) because almost no languages put a string emphasis on
> lines.
Even if the language says little about it, nearly all code /is/
organised into lines.
If you need to talk about it, give instructions about a mod over the
phone, or a compiler needs to report an error, then /line/ numbers are a
very convenient way to refer to the source.
But if there's too much on one line, then pinpointing that exact piece
of code in question is harder.
I'd have thought debuggers would help with that, but if they
> don't -- and the people who use them are content that they don't -- then
> who am I to complain?
>
> The great thing about Usenet is you get to see opinions that you'd never
> otherwise see. The next time I see
>
> while (1) {
> c = getchar();
> if (c == EOF || c == '\n') break;
> ...
> }
>
> I won't think "what shocking code" I'll think "ah, someone's debugger
> needs a helping hand".
How would you describe the above as instructions in English? Here's my
attempt (with some context added to keep it meaningful to a non-expert):
Step 1: Get the next ball from the bag
Step 2: If the ball is red or blue, then stop
Step 3: ... do something with the ball ...
Step 4: Repeat from step 1
> Sure, but we have an actual dividing line here. I wrote
>
> while ((c = getchar()) != EOF && c != '\n') {
> ...
> }
>
> and BartC re-wrote it with a while (1) and a break and Ian then agreed.
> It's the location of this specific dividing line that is interesting to
> me. It's nowhere near where I thought it would be.
(In practice I wouldn't write file processing loops like that at all. I
know it's just an example of using assignment within a while condition,
but such loops are more like this, if I can deviate from C for a second:
while not eof(f) do
read ....
end
If your example is processing a line of interactive input as it looks
like, then I would probably use a separate function to fetch the next
line into a buffer. The same function I wrote in 1998 rather than keep
doing this low-level processing that you are fond of.
To get back to the subject, I do often use assignments within
expressions, but I try and keep the whole expression simpler than your
example.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-07 21:39 +0000 |
| Message-ID | <874mfu9bwe.fsf@bsb.me.uk> |
| In reply to | #78091 |
BartC <bc@freeuk.com> writes:
> On 07/12/2015 14:37, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>
>>> Debuggers tend to put a strong emphasis on lines - you set a breakpoint
>>> on a line, you single-step line by line, etc. If you want to
>>> conveniently step through pieces of code, it is much easier and clearer
>>> if each operation, evaluation, function call, concept (or whatever you
>>> want to call "bits of code") is on its own line.
>>
>> That's odd (to me) because almost no languages put a string emphasis on
>> lines.
s/string/strong/
> Even if the language says little about it, nearly all code /is/
> organised into lines.
>
> If you need to talk about it, give instructions about a mod over the
> phone, or a compiler needs to report an error, then /line/ numbers are
> a very convenient way to refer to the source.
>
> But if there's too much on one line, then pinpointing that exact piece
> of code in question is harder.
All things we are in agreement about.
>> I'd have thought debuggers would help with that, but if they
>> don't -- and the people who use them are content that they don't -- then
>> who am I to complain?
>>
>> The great thing about Usenet is you get to see opinions that you'd never
>> otherwise see. The next time I see
>>
>> while (1) {
>> c = getchar();
>> if (c == EOF || c == '\n') break;
>> ...
>> }
>>
>> I won't think "what shocking code" I'll think "ah, someone's debugger
>> needs a helping hand".
>
> How would you describe the above as instructions in English? Here's my
> attempt (with some context added to keep it meaningful to a
> non-expert):
>
> Step 1: Get the next ball from the bag
> Step 2: If the ball is red or blue, then stop
> Step 3: ... do something with the ball ...
> Step 4: Repeat from step 1
I don't get your point. That's a reasonable approximation in one sense
and an unreasonable one on others. I can't see where you are going with
this analogy. Depending on what you intend here we might be having a
furious agreement.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-07 23:04 +0000 |
| Message-ID | <n4534v$d1m$1@dont-email.me> |
| In reply to | #78139 |
On 07/12/2015 21:39, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> On 07/12/2015 14:37, Ben Bacarisse wrote:
>>> otherwise see. The next time I see
>>>
>>> while (1) {
>>> c = getchar();
>>> if (c == EOF || c == '\n') break;
>>> ...
>>> }
>>>
>>> I won't think "what shocking code" I'll think "ah, someone's debugger
>>> needs a helping hand".
>>
>> How would you describe the above as instructions in English? Here's my
>> attempt (with some context added to keep it meaningful to a
>> non-expert):
>>
>> Step 1: Get the next ball from the bag
>> Step 2: If the ball is red or blue, then stop
>> Step 3: ... do something with the ball ...
>> Step 4: Repeat from step 1
>
> I don't get your point. That's a reasonable approximation in one sense
> and an unreasonable one on others. I can't see where you are going with
> this analogy. Depending on what you intend here we might be having a
> furious agreement.
My point is that your original example:
while ((c = getchar()) != EOF && c != '\n') { ...
when you try to express it in English, will more than likely be like the
steps I've shown above.
That pattern has the condition on step 2 not step 1. To me, that
corresponds to a loop that has an exit point not at the beginning or
end, but somewhere in the loop body.
I've looked briefly for a language other than my own which allows
breaking loops in the middle. I've discovered that Ada, a well-respected
language, supports that too:
loop
c := getchar();
exit when c=EOF or c='\n';
... do stuff ...
end loop
(Although this is not quite what I wanted, which was a loop with a
/single/ official exit point, and at the top level. I think Ada allows
any number of exit statements and nested deep within other statements too.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-08 01:19 +0000 |
| Message-ID | <878u5591p2.fsf@bsb.me.uk> |
| In reply to | #78147 |
BartC <bc@freeuk.com> writes:
> On 07/12/2015 21:39, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 07/12/2015 14:37, Ben Bacarisse wrote:
>
>>>> otherwise see. The next time I see
>>>>
>>>> while (1) {
>>>> c = getchar();
>>>> if (c == EOF || c == '\n') break;
>>>> ...
>>>> }
>>>>
>>>> I won't think "what shocking code" I'll think "ah, someone's debugger
>>>> needs a helping hand".
>>>
>>> How would you describe the above as instructions in English? Here's my
>>> attempt (with some context added to keep it meaningful to a
>>> non-expert):
>>>
>>> Step 1: Get the next ball from the bag
>>> Step 2: If the ball is red or blue, then stop
>>> Step 3: ... do something with the ball ...
>>> Step 4: Repeat from step 1
>>
>> I don't get your point. That's a reasonable approximation in one sense
>> and an unreasonable one on others. I can't see where you are going with
>> this analogy. Depending on what you intend here we might be having a
>> furious agreement.
>
> My point is that your original example:
>
> while ((c = getchar()) != EOF && c != '\n') { ...
>
> when you try to express it in English, will more than likely be like
> the steps I've shown above.
Ah, I see.
> That pattern has the condition on step 2 not step 1. To me, that
> corresponds to a loop that has an exit point not at the beginning or
> end, but somewhere in the loop body.
Yes, the loop test is done after some computation. In C, you can write
that like this:
while (f() == something_or_other) {
}
but in English you need to explain that what f does happens first and
then a test is made. There may be a way to fudge it to verbalised more
like the C code, but I won't try. C and English are very different
languages and I would not expect them to express this pattern in similar
ways.
But the fact that the test follows some computation would not make me
write
while (1) {
int n = scanf("%f %f %f", &x, &y, &z);
if (n != 3) break;
// use x, y and z
}
rather than
while (scanf("%f %f %f", &x, &y, &z) == 3) {
// use x, y and z
}
and the presence of an assignment (while ((n = scanf("...")) == 3) or
while ((c = getchar()) ...) would not be enough to make me change my
mind. There is a natural way to write this in C, despite how you'd
verbalise it in English.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-12-08 01:12 +0000 |
| Message-ID | <n45ap5$mc8$2@speranza.aioe.org> |
| In reply to | #78091 |
BartC <bc@freeuk.com> wrote: > On 07/12/2015 14:37, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> Debuggers tend to put a strong emphasis on lines - you set a breakpoint >>> on a line, you single-step line by line, etc. If you want to >>> conveniently step through pieces of code, it is much easier and clearer >>> if each operation, evaluation, function call, concept (or whatever you >>> want to call "bits of code") is on its own line. >> That's odd (to me) because almost no languages put a string emphasis on >> lines. > Even if the language says little about it, nearly all code /is/ > organised into lines. In the days when it was usual for a compiler to print out a source listing, along with appropriate messages, statement maps, and variable maps (giving the address for each variable and statement) it was usual to give each statement an ISN, internal statement number. That number would be used in any maps, and debuggers. But now the we debug with vi and emacs, line numbers are it. > If you need to talk about it, give instructions about a mod over the > phone, or a compiler needs to report an error, then /line/ numbers are a > very convenient way to refer to the source. (snip) -- glen
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-08 09:11 +0100 |
| Message-ID | <n4637n$vm8$1@dont-email.me> |
| In reply to | #78161 |
On 08/12/15 02:12, glen herrmannsfeldt wrote: > BartC <bc@freeuk.com> wrote: >> On 07/12/2015 14:37, Ben Bacarisse wrote: >>> David Brown <david.brown@hesbynett.no> writes: > >>>> Debuggers tend to put a strong emphasis on lines - you set a breakpoint >>>> on a line, you single-step line by line, etc. If you want to >>>> conveniently step through pieces of code, it is much easier and clearer >>>> if each operation, evaluation, function call, concept (or whatever you >>>> want to call "bits of code") is on its own line. > >>> That's odd (to me) because almost no languages put a string emphasis on >>> lines. > >> Even if the language says little about it, nearly all code /is/ >> organised into lines. > > In the days when it was usual for a compiler to print out a source > listing, along with appropriate messages, statement maps, and variable > maps (giving the address for each variable and statement) it was usual > to give each statement an ISN, internal statement number. "In the days..." /I/ generate assembly listing files and detailed map files when building my projects. I don't often look at them, but they are occasionally useful. For some of my code I want to see exactly what sort of assembly is generated. But I have not seen any sort of internal statement number - often it is hard enough to see the correlation between the source code lines and the generated assembly. > > That number would be used in any maps, and debuggers. > > But now the we debug with vi and emacs, line numbers are it. > >> If you need to talk about it, give instructions about a mod over the >> phone, or a compiler needs to report an error, then /line/ numbers are a >> very convenient way to refer to the source. > > (snip) > > -- glen >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-07 17:19 +0100 |
| Message-ID | <n44bdr$6rl$1@dont-email.me> |
| In reply to | #78090 |
On 07/12/15 15:37, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 07/12/15 12:06, Ben Bacarisse wrote:
>>> Ian Collins <ian-news@hotmail.com> writes:
>>> <snip>
>>>>> On 07/12/2015 00:13, Ben Bacarisse wrote:
>>> <snip>
>>>>>> But for me, the best advertisement for assignment as an expression is
>>>>>> the pattern
>>>>>>
>>>>>> while ((c = getchar()) != EOF && c != '\n') {
>>>>>> // ... do stuff with c ...
>>>>>> }
>>> <snip>
>>>
>>>> I've had to take assignments out of expressions one too many times
>>>> while debugging someone else's code to ever put them there in the
>>>> first place.
>>>
>>> I find that surprising and a little disappointing. What is it about
>>> debugging that is hindered by embedded assignments? I presume that it's
>>> something to do with the tools. I haven't used an interactive debugger
>>> for C in anger for many years so maybe I have been naive in assuming
>>> that they would have evolved to enable easy debugging of common language
>>> patterns. I know that they used to be very much line-oriented but that
>>> was in the 80s when I was often debugging Fortran for which that worked
>>> just fine. Have they not moved on? And if not (since I don't imagine
>>> you are alone in finding this frustrating) I wonder why not.
>>>
>>> I often see annoyance about code patterns that hinder debugging, but not
>>> so much annoyance at debugging tools that don't work for common code
>>> patterns. That seems to me to be the wrong way round.
>>>
>>
>> Debuggers tend to put a strong emphasis on lines - you set a breakpoint
>> on a line, you single-step line by line, etc. If you want to
>> conveniently step through pieces of code, it is much easier and clearer
>> if each operation, evaluation, function call, concept (or whatever you
>> want to call "bits of code") is on its own line.
>
> That's odd (to me) because almost no languages put a string emphasis on
> lines. I'd have thought debuggers would help with that, but if they
> don't -- and the people who use them are content that they don't -- then
> who am I to complain?
Debuggers have to be a compromise between ease of use and functionality.
There is no clear absolute line to determine the unit for
single-stepping in a language like C - sometimes you want small steps,
sometimes you want big steps. Sometimes code might look like a single
function call, but maybe it is many, or none (due to macros). Something
might look like a simple expression, but involve complex library calls
(software floating point). And if you have C++, there are all sorts of
additional possible complications (since C++ is off-topic, I'll leave
the details to your imagination).
The common practice for debuggers is to allow "step line" and "step
function", as well as assembly-level single stepping. Stepping lines
makes it fairly clear to the user what is being stepped, and it is much
easier to make an interface to allow setting a breakpoint on a line than
to allow breakpoints on statements, parts of expressions, etc. It is a
practical compromise.
(Of course, things get really complicated with optimisation breaking the
correspondence between source code lines and object code.)
>
> The great thing about Usenet is you get to see opinions that you'd never
> otherwise see. The next time I see
>
> while (1) {
> c = getchar();
> if (c == EOF || c == '\n') break;
> ...
> }
>
> I won't think "what shocking code" I'll think "ah, someone's debugger
> needs a helping hand".
You might think that - but I think you'll be hard pushed to find a
debugger that works well with sub-line stepping and breakpoints.
And you will also find other reasons why someone might want to avoid
squeezing too much into a single expression - even if other programmers
think it is fine.
Instead of thinking "what shocking code", you should rather think "I
wonder if it is written that way intentionally" or "I might not have
written it that way myself, but it is obvious at a glance what that code
does".
>
>> It also makes it easier to use version control and diff viewing (which
>> is mostly line oriented), or code reviews.
>
> I've never found things like
>
> while ((c = getchar()) != EOF && c != '\n') {
>
> to be a problem in either code review or version control. I'm not
> arguing for silly long lines, I'm commenting on having to remove
> assignments from expressions because debuggers require you to do that.
I did not mean to imply that debuggers require you to avoid using the
result of an assignment expression - merely a general rule that
debugging can be easier if complex lines are split up into simpler parts.
>
>> As Ian said, different people have different points where we say "that
>> is a convenient and concise way to express the code" and where we say
>> "that is line noise". Experience with different types of tools may
>> influence that dividing point,
>
> Sure, but we have an actual dividing line here. I wrote
>
> while ((c = getchar()) != EOF && c != '\n') {
> ...
> }
>
> and BartC re-wrote it with a while (1) and a break and Ian then agreed.
> It's the location of this specific dividing line that is interesting to
> me. It's nowhere near where I thought it would be.
I would (normally) avoid using the results of the assignment operation
in a while loop like that. I may occasionally write something like
"while ((c = getchar())) { ... }, but it would be rare in my code - and
I would avoid extra conditionals.
I can't say how common this is, or whether it is just me that draws the
lines where I do. But I do know that embedded coding standards are
often much stricter about these things than is common in "big system"
programming (though I can't say how common the strict use of coding
standards is in embedded programming). The most "standard" of embedded
programming standards, MISRA, would reject this line:
if (c == EOF || c == '\n') break;
MISRA advises (in MISRA, "advises" really means "requires" if you want
to be strictly compliant) that you do not rely on the precedence of most
operators - so the conditional must be written ((c == EOF) || (c ==
'\n)). And MISRA requires brackets for every "if" statement.
It also advises against using the result of assignment operators.
Now, I am not going to say that I agree with every rule in MISRA (I
don't). But I can certainly say that if you find my code "shocking",
you would have a fit if you were asked to write MISRA-compliant code.
And MISRA is not the most restricted or conservative C coding standard
in use.
>
>> as will experience with different
>> programmers and the code they write (there is nothing like fixing bugs
>> in other people's code to make you a fan of more conservative coding
>> styles).
>
> It did not have that effect on me, but then I don't consider BartC's
> re-write to be conservative, either. It just looks clumsy to me.
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-07 22:50 +0000 |
| Message-ID | <87y4d598m9.fsf@bsb.me.uk> |
| In reply to | #78094 |
David Brown <david.brown@hesbynett.no> writes:
> On 07/12/15 15:37, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 07/12/15 12:06, Ben Bacarisse wrote:
>>>> Ian Collins <ian-news@hotmail.com> writes:
>>>> <snip>
>>>>>> On 07/12/2015 00:13, Ben Bacarisse wrote:
>>>> <snip>
>>>>>>> But for me, the best advertisement for assignment as an expression is
>>>>>>> the pattern
>>>>>>>
>>>>>>> while ((c = getchar()) != EOF && c != '\n') {
>>>>>>> // ... do stuff with c ...
>>>>>>> }
>>>> <snip>
>>>>
>>>>> I've had to take assignments out of expressions one too many times
>>>>> while debugging someone else's code to ever put them there in the
>>>>> first place.
>>>>
>>>> I find that surprising and a little disappointing. What is it about
>>>> debugging that is hindered by embedded assignments? I presume that it's
>>>> something to do with the tools. I haven't used an interactive debugger
>>>> for C in anger for many years so maybe I have been naive in assuming
>>>> that they would have evolved to enable easy debugging of common language
>>>> patterns. I know that they used to be very much line-oriented but that
>>>> was in the 80s when I was often debugging Fortran for which that worked
>>>> just fine. Have they not moved on? And if not (since I don't imagine
>>>> you are alone in finding this frustrating) I wonder why not.
>>>>
>>>> I often see annoyance about code patterns that hinder debugging, but not
>>>> so much annoyance at debugging tools that don't work for common code
>>>> patterns. That seems to me to be the wrong way round.
>>>>
>>>
>>> Debuggers tend to put a strong emphasis on lines - you set a breakpoint
>>> on a line, you single-step line by line, etc. If you want to
>>> conveniently step through pieces of code, it is much easier and clearer
>>> if each operation, evaluation, function call, concept (or whatever you
>>> want to call "bits of code") is on its own line.
>>
>> That's odd (to me) because almost no languages put a string emphasis on
>> lines. I'd have thought debuggers would help with that, but if they
>> don't -- and the people who use them are content that they don't -- then
>> who am I to complain?
>
> Debuggers have to be a compromise between ease of use and
> functionality.
Sure. And it seems people are happy with writing debugger-friendly
code. I would prefer a code-friendly debugger, but it may not be
possible. You suggest that the compromise is about right where it is.
(I wrote a debugger in C once (1982 no less -- I shudder to think what
the C was like) but it had the most crude interface you can imagine.
The brief was "something rather than nothing, and by the end of the
month, please".)
> There is no clear absolute line to determine the unit for
> single-stepping in a language like C - sometimes you want small steps,
> sometimes you want big steps.
I'd go for sequence points in the first instance.
<snip>
>> The great thing about Usenet is you get to see opinions that you'd never
>> otherwise see. The next time I see
>>
>> while (1) {
>> c = getchar();
>> if (c == EOF || c == '\n') break;
>> ...
>> }
>>
>> I won't think "what shocking code" I'll think "ah, someone's debugger
>> needs a helping hand".
>
> You might think that - but I think you'll be hard pushed to find a
> debugger that works well with sub-line stepping and breakpoints.
>
> And you will also find other reasons why someone might want to avoid
> squeezing too much into a single expression - even if other programmers
> think it is fine.
>
> Instead of thinking "what shocking code", you should rather think "I
> wonder if it is written that way intentionally" or "I might not have
> written it that way myself, but it is obvious at a glance what that code
> does".
Well, as I said, I won't think "shocking code" anymore. And I'll now
add in the possibility that the author considered that the best way to
write the loop. (I'd not seen your other reply about preferring this
style for other, non-debugging reasons, when I posted).
>>> It also makes it easier to use version control and diff viewing (which
>>> is mostly line oriented), or code reviews.
>>
>> I've never found things like
>>
>> while ((c = getchar()) != EOF && c != '\n') {
>>
>> to be a problem in either code review or version control. I'm not
>> arguing for silly long lines, I'm commenting on having to remove
>> assignments from expressions because debuggers require you to do that.
>
> I did not mean to imply that debuggers require you to avoid using the
> result of an assignment expression - merely a general rule that
> debugging can be easier if complex lines are split up into simpler
> parts.
But the general rule does apply in this case, doesn't it? You dislike
assignments in expressions -- they are a design flaw in your opinion --
and you site ease of debugging, and problem in code review and for
version control in support of that opinion. And you offered a re-write
of this specific code as being better since it avoid the design flaw of
assignments in expressions.
I don't want to get into a vague discussion about complex lines being
simplified into several -- I do that all the time, as does every
programmer, I imagine. I wanted to know where you draw the line and I
thought we'd found an example. That's why I stuck my neck out and said
I had not found those things to be problematic in code review or version
control. If it's not an example of that, can you post one, because we
might agree about it.
>>> As Ian said, different people have different points where we say "that
>>> is a convenient and concise way to express the code" and where we say
>>> "that is line noise". Experience with different types of tools may
>>> influence that dividing point,
>>
>> Sure, but we have an actual dividing line here. I wrote
>>
>> while ((c = getchar()) != EOF && c != '\n') {
>> ...
>> }
>>
>> and BartC re-wrote it with a while (1) and a break and Ian then agreed.
>> It's the location of this specific dividing line that is interesting to
>> me. It's nowhere near where I thought it would be.
>
> I would (normally) avoid using the results of the assignment operation
> in a while loop like that. I may occasionally write something like
> "while ((c = getchar())) { ... }, but it would be rare in my code - and
> I would avoid extra conditionals.
(I'm assuming you mean "while ((c = getchar()) != EOF) { ... }" because
that conditional is not an extra one -- it's the one that makes the code
useful in the first place.)
But I don't get where this is going. Is it rare because you don't often
write loops where this pattern might come up (but you'd use the pattern
every time it did), or is it rare because you only let yourself do it
some times and not in most cases where you might? If the latter, what
kind of consideration makes you choose?
<snip on coding standards>
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 3 of 20 — ← Prev page 1 2 [3] 4 5 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web