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 6 of 20 — ← Prev page 1 … 4 5 [6] 7 8 … 20 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-12-07 10:54 -0800 |
| Message-ID | <15bd5c20-171e-488c-8785-f36037481cbf@googlegroups.com> |
| In reply to | #78117 |
On Monday, December 7, 2015 at 1:43:46 PM UTC-5, Richard Damon wrote: > On 12/7/15 5:52 AM, Rick C. Hodgin wrote: > > David Brown wrote: > >> Writing "if ((x = f(x), x) != 42)" is, IMHO, even worse... > > > > The # could be a global thing, to use the value before the expression began: > > > > if ((#x = f(x)) != 42 || #x == 43 || x == 44) > > > > Meaning: > > > > t = x; > > x = f(x); > > if (t != 42 || t == 43 || x == 44) > > You do know that #x has a meaning in C don't you? To my knowledge, the #x and ##x syntaxes are used only in macros. And in the case of CAlive, if you needed to use them within that context, you can escape them using \#\#x, for example. Presumably the same could be used in C were these features added to the standard). Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-07 11:00 +0000 |
| Message-ID | <n43oo9$sej$1@dont-email.me> |
| In reply to | #78042 |
On 07/12/15 10:38, David Brown wrote: <snip stuff I largely disagree with - life's too short!> > I bet that every time you intend to write > something like "if (a = b)", you will write "if ((a = b))" - in order to > make it clear to the compiler and the reader that you really mean an > assignment and not a comparison, and do avoid compile-time warnings. Data point: personally, I don't. If I mean if(a = b) then I write if(a = b), and I don't put in unnecessary parentheses. A good compiler will, rather helpfully, document the code for me, using a diagnostic message. Anyone compiling the code will thus have their attention drawn to that line - but (if they are wise) they won't dare change it without first reading it very carefully to be absolutely sure they know what it does, at which point (a) they won't need to change it, and (b) they will understand the code a little better now. In an attempt to be fair to those people, however, I do not commonly use unadorned assignment in control constructs such as if() and while(). I might write if((c = getchar()) != EOF), but I won't write if(c = getchar()). > Assuming that's true, Ahaha, sirrah! Let us not be too hasty. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-07 13:07 +0100 |
| Message-ID | <n43sma$b9a$1@dont-email.me> |
| In reply to | #78046 |
On 07/12/15 12:00, Richard Heathfield wrote: > On 07/12/15 10:38, David Brown wrote: > > <snip stuff I largely disagree with - life's too short!> > >> I bet that every time you intend to write >> something like "if (a = b)", you will write "if ((a = b))" - in order to >> make it clear to the compiler and the reader that you really mean an >> assignment and not a comparison, and do avoid compile-time warnings. > > Data point: personally, I don't. If I mean if(a = b) then I write if(a = > b), and I don't put in unnecessary parentheses. A good compiler will, > rather helpfully, document the code for me, using a diagnostic message. > Anyone compiling the code will thus have their attention drawn to that > line - but (if they are wise) they won't dare change it without first > reading it very carefully to be absolutely sure they know what it does, > at which point (a) they won't need to change it, and (b) they will > understand the code a little better now. It is standard practice, as far as I am concerned, to make code that is tested and "finished" (to the extent that code is ever finished...) compile without generating any warnings. That way if something changes in the code to generate warnings, you can see that you have now introduced a potential problem or questionable code - your real issues don't get drowned out in the noise of "mere warnings". > > In an attempt to be fair to those people, however, I do not commonly use > unadorned assignment in control constructs such as if() and while(). I > might write if((c = getchar()) != EOF), but I won't write if(c = > getchar()). > >> Assuming that's true, > > Ahaha, sirrah! Let us not be too hasty. >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-12-07 04:19 -0800 |
| Message-ID | <8e09d4be-3985-4704-840c-a38cb65bcff2@googlegroups.com> |
| In reply to | #78059 |
On Monday, December 7, 2015 at 12:08:05 PM UTC, David Brown wrote: > On 07/12/15 12:00, Richard Heathfield wrote: > > It is standard practice, as far as I am concerned, to make code that is > tested and "finished" (to the extent that code is ever finished...) > compile without generating any warnings. That way if something changes > in the code to generate warnings, you can see that you have now > introduced a potential problem or questionable code - your real issues > don't get drowned out in the noise of "mere warnings". > It's too hard for cross-platform development. lint used to warn about unchecked return values from printf(). Some compilers will warn about unreachable code, others will warn about a missing return from an unreachable function closing brace. Some compilers make such a huge fuss about conversions that potentially lose information that code needs to be littered with casts, which just gives a false sense of security (the conversion is safe if and only if the value cannot go outside the narrower type's limit, which is usually obvious to the programmer, but not to a compiler).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-07 13:58 +0100 |
| Message-ID | <n43vku$m97$1@dont-email.me> |
| In reply to | #78061 |
On 07/12/15 13:19, Malcolm McLean wrote: > On Monday, December 7, 2015 at 12:08:05 PM UTC, David Brown wrote: >> On 07/12/15 12:00, Richard Heathfield wrote: >> >> It is standard practice, as far as I am concerned, to make code that is >> tested and "finished" (to the extent that code is ever finished...) >> compile without generating any warnings. That way if something changes >> in the code to generate warnings, you can see that you have now >> introduced a potential problem or questionable code - your real issues >> don't get drowned out in the noise of "mere warnings". >> > It's too hard for cross-platform development. Most of my code is specific to a given embedded target (cross compilation, but not cross platform), but some supports a range of platforms. It's not hard. > lint used to warn about unchecked return values from printf(). Use appropriate checking mechanisms, and appropriate warnings, for the platforms in question. > Some compilers will warn about unreachable code, others will > warn about a missing return from an unreachable function > closing brace. Again, it is not hard - at least, not when the there is a limited number of tools involved. Writing code in such a way as to be warning-free on unknown compilers and unknown options is infeasible. But making the code warning-free, or at least very close to warning-free, on a reasonable choice of realistic platforms and option choices is perfectly possible. > Some compilers make such a huge fuss about conversions that potentially lose > information that code needs to be littered with casts, which just gives a > false sense of security (the conversion is safe if and only if the value > cannot go outside the narrower type's limit, which is usually obvious to > the programmer, but not to a compiler). > It makes sense to match warning options with the code and code style. Many compilers, linters, and other checkers can generate warnings on code that is considered perfectly safe and acceptable to some people but questionable to others. Just because a compiler or tools supports a particular warning, does not mean that it is sensible to use it. But having made your selection of warnings, you should aim to be warning-free. If you choose to warn on mixing signed and unsigned integers in order to prevent accidents, then you will have to put in casts in places that you know you are mixing such types. If you want to mix these types without casts, don't enable such warnings.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-07 12:32 +0000 |
| Message-ID | <n43u3m$gkf$1@dont-email.me> |
| In reply to | #78059 |
On 07/12/15 12:07, David Brown wrote: > On 07/12/15 12:00, Richard Heathfield wrote: >> On 07/12/15 10:38, David Brown wrote: >> >> <snip stuff I largely disagree with - life's too short!> >> >>> I bet that every time you intend to write >>> something like "if (a = b)", you will write "if ((a = b))" - in order to >>> make it clear to the compiler and the reader that you really mean an >>> assignment and not a comparison, and do avoid compile-time warnings. >> >> Data point: personally, I don't. If I mean if(a = b) then I write if(a = >> b), and I don't put in unnecessary parentheses. A good compiler will, >> rather helpfully, document the code for me, using a diagnostic message. >> Anyone compiling the code will thus have their attention drawn to that >> line - but (if they are wise) they won't dare change it without first >> reading it very carefully to be absolutely sure they know what it does, >> at which point (a) they won't need to change it, and (b) they will >> understand the code a little better now. > > It is standard practice, as far as I am concerned, to make code that is > tested and "finished" (to the extent that code is ever finished...) > compile without generating any warnings. That way if something changes > in the code to generate warnings, you can see that you have now > introduced a potential problem or questionable code - your real issues > don't get drowned out in the noise of "mere warnings". That is certainly the rationale for a "clean compile", yes, and it is a rationale that I embraced early in my C programming - set the warning level as high as possible, and then fix *everything*. This put me at odds with my team members on occasion - I recall one chap saying in a broad Chicago accent, "clean compile at level FOUR? That's im/pahss/ible!" (It wasn't impossible, of course. For me, it was routine. But he seemed to think it was a huge deal. When I looked at some of his code, I began to realise why he... but no, it would be unkind to continue that thought.) In recent years, however, diagnostics have "improved" to the point where I found myself having to hack perfectly clear and correct code for the sake of getting rid of what I considered to be "spurious diagnostic messages" (if that thread title rings any bells). I am therefore considerably less fussy now than I was then about such things. (I'm still fussy about the *code* - I'm just less fussy about persuading the lint-conscience of the compiler not to criticise that code.) Nowadays, I view the list of diagnostics much as I view comp.lang.c - lots of noise, with the occasional gem. I compile as we are often urged to vote - early and often! So I read the diagnostic list, fix what needs to be fixed, and develop a sense of what is being reported that I can note and then set aside. This works fine during constant early development of the code. Later, when I come back to a program that I haven't touched for a while, the diagnostic list I get on a "make clean; make" (which may indeed be lengthy) becomes a handy guide to re-acquainting myself with the code, *which I would have to do anyway* when revisiting old code, because making changes without having a good understanding of the code you're changing is a fool's errand. But I work on the principle that "I have seen this message before, and I didn't change the code then, so it's probably fine, and I'll just take two seconds to look at it to make assurance doubly sure". Yes, it takes a little extra time, but not as much time as working out the best way to shut up a pointless warning about correct code without making the code /worse/ in the process. I fully accept that not everybody looks at it this way; therefore, if I'm working in a team, I adopt the team's conventions. If that means a clean compile, I am perfectly willing and able to fit in with that. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-07 20:57 +0000 |
| Message-ID | <87fuze9dtj.fsf@bsb.me.uk> |
| In reply to | #78042 |
David Brown <david.brown@hesbynett.no> writes:
> On 07/12/15 01:13, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
<snip>
>>> I think it would have been much easier if C didn't have return values
>>> from assignment or increment.
>>
>> Is your objection to the value, or to the fact that assignment is an
>> expression
<snip>
> My complaint is that assignment is an expression.
Thanks for clearing that up.
<snip>
>>> It might be convenient to occasionally
>>> write "while (n--) { .. } " - but how much harder would it have been
>>> to write "while (n) { n--; ... }" ?
>>
>> They are (as you know) slightly different, and there are cases where the
>> difference can be helpful. If the loop has an alternate exit point
>> (i.e. a break) then the C idiom can sometimes help to determine why the
>> loop ended:
>>
>> while (n--) if (some_condition_based_on(n)) break;
>> if (n < 0) // not found
>>
>> while (n) { n--; if (some_condition_based_on(n)) break; }
>> if (???)
>
> I appreciate the difference, but it is not difficult to fix.
>
> One key point, perhaps, is that often the convenient alternative to
> using the value of an assignment or increment expression is to use booleans:
>
> bool found = false;
> while (n) {
> if (check(n)) {
> found = true;
> break;
> }
> n--;
> }
> if (found) ...
>
> In the early days of C compilers, such extra booleans were expensive -
> the language did not have the convenience of C99 for declaring new
> variables except at the start of a block, making such code a little
> uglier, and the optimisers in early compilers were not as smart as
> modern ones. A modern compiler will turn the "found" variable into
> simple jumps - this kind of condition-tracking boolean is free.
Free in terms of execution costs, but there's a cost in terms of
clarity, at least for me.
It's interesting (to me) that you would advocate (or at least describe
as convenient) the above in preference to having an assignment in a
condition, but in the end it's just a curiosity; there's no point in
either of us trying to change the others mind.
>> and the same applies when using short-circuit &&:
>>
>> while (n-- && !some_condition_based_on(n));
>> if (n < 0) // not found
>>
>> while (n && !some_condition_based_on(n - 1)) n--;
>> if (???)
>>
>> But for me, the best advertisement for assignment as an expression is
>> the pattern
>>
>> while ((c = getchar()) != EOF && c != '\n') {
>> // ... do stuff with c ...
>> }
>
> I appreciate that - but consider how often you need to write such code,
> and compare it to how often mistakes have been made as a result of
> allowing it in the language.
I can't consider it because I really don't know. You may have some data
on this, but do bear in mind that not all mistakes are equal. What
matters are hard bugs, not things that show up right way as soon as you
do the first test.
> It is a tradeoff in language design, and I
> think the wrong choice was made (again, this is with hindsight).
>
>> No matter how simple the code to set c (and it's just a function call
>> here) I get annoyed when a language makes me repeat myself:
>>
>> int c = getchar();
>> while (c != EOF && c != '\n') {
>> // ... do stuff with c ...
>> c = getchar();
>> }
>
> int c;
> while (true) {
> c = getchar();
> if ((c == EOF) || (c == '\n')) break;
> // do stuff...
> }
Well, that's another one for the Usenet programming anthropology
notebook. I've seen code like that before, of course, so I know people
like to write it, but I don't recall meeting someone who advocates it.
(And now three come along in one thread.)
<snip>
>> I would never want to loose it. I don't recall any hard-to-find errors
>> caused bye a misplaced assignment. They do cause errors, but they get
>> found (in my experience) in the first compile (if the compiler warns
>> about it) or in the first test run. I am sure someone has a horror
>> story of how it took a team of experts months of work to find a
>> misplaced x--, but rare cases make bad language design.
>
> A good compiler can warn about suspicious testing of assignment (such as
> "if (x = 10) ..."). However, that requires a good compiler, and
> appropriate use of warnings. I bet that every time you intend to write
> something like "if (a = b)", you will write "if ((a = b))" - in order to
> make it clear to the compiler and the reader that you really mean an
> assignment and not a comparison, and do avoid compile-time warnings.
No, because it seems very rare to me. It's uncommon to have a bare
assignment where the assigned value is the correct one to test. I am
sure it happens every now and then, but it's not common enough for me to
have wanted a way round the warnings about it.
It's very common (in my sort of code) when the assignment is implicit
(as in while (n--) or while (*--cp) and so on) but those never give you
a warning -- the compiler assumes you are using the band saw correctly.
> Assuming that's true, it shows clearly that the syntax of C is
> considered non-ideal here, and you prefer to partially disable the C
> feature and replace it with a new and less risky syntax.
I'd prefer a "sic" annotation to disable the warning rather than some
mysterious syntax like superfluous parentheses. As it is, I just live
with the warning when they happen, but then I just program for fun these
days so I'm not really a good example.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-08 00:10 +0100 |
| Message-ID | <n453hf$efp$1@dont-email.me> |
| In reply to | #78132 |
On 07/12/15 21:57, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 07/12/15 01:13, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
> <snip>
> Free in terms of execution costs, but there's a cost in terms of
> clarity, at least for me.
I agree entirely with you on the principle here - we just differ a
little on what we think of as "clear". It is also worth remembering
that these examples are all out of context - I suspect that in context,
we would have less to disagree about.
>
> It's interesting (to me) that you would advocate (or at least describe
> as convenient) the above in preference to having an assignment in a
> condition, but in the end it's just a curiosity; there's no point in
> either of us trying to change the others mind.
But it is useful to get ideas of different ways to write code, even if
we each decide that we like our own habits best.
>
>>> and the same applies when using short-circuit &&:
>>>
>>> while (n-- && !some_condition_based_on(n));
>>> if (n < 0) // not found
>>>
>>> while (n && !some_condition_based_on(n - 1)) n--;
>>> if (???)
>>>
>>> But for me, the best advertisement for assignment as an expression is
>>> the pattern
>>>
>>> while ((c = getchar()) != EOF && c != '\n') {
>>> // ... do stuff with c ...
>>> }
>>
>> I appreciate that - but consider how often you need to write such code,
>> and compare it to how often mistakes have been made as a result of
>> allowing it in the language.
>
> I can't consider it because I really don't know. You may have some data
> on this, but do bear in mind that not all mistakes are equal. What
> matters are hard bugs, not things that show up right way as soon as you
> do the first test.
I have only apocryphal data, not real facts.
One thing that makes a difference here is that compilers for embedded
systems have often been poorer at helping developers write correct code,
than compilers on bigger systems (such as gcc, icc, msvc). Many
embedded compilers have been niche products - they are often slightly
weird, have unusual extensions, perhaps don't fully support C standards,
are often way behind the times (such as being ANSI/C89 only), and often
have poor warnings. (That is changing now, as gcc is dominating
embedded development.) Combined with very limited debugging
possibilities on many systems, this means that slips such as writing "if
(a = b)" instead of "if (a == b)" can be harder to spot on older
embedded development systems than it would be on desktop systems.
As I noted elsewhere, most embedded coding standards disallow testing
the results of an assignment - some (not MISRA) even insist you write
"if (10 == x)" rather than "if (x == 10)" in order to allow the compiler
to spot a mixup between "==" and "=". This suggests that groups that
make a living investigating bugs and finding ways to avoid them see this
as a realistic issue. (Personally, I prefer to let gcc warn me about
"if (x = 10)" rather than writing my conditionals as Yoda would.)
>
>> It is a tradeoff in language design, and I
>> think the wrong choice was made (again, this is with hindsight).
>>
>>> No matter how simple the code to set c (and it's just a function call
>>> here) I get annoyed when a language makes me repeat myself:
>>>
>>> int c = getchar();
>>> while (c != EOF && c != '\n') {
>>> // ... do stuff with c ...
>>> c = getchar();
>>> }
>>
>> int c;
>> while (true) {
>> c = getchar();
>> if ((c == EOF) || (c == '\n')) break;
>> // do stuff...
>> }
>
> Well, that's another one for the Usenet programming anthropology
> notebook. I've seen code like that before, of course, so I know people
> like to write it, but I don't recall meeting someone who advocates it.
> (And now three come along in one thread.)
It's an alternative since you didn't want to repeat the getchar(). I
would be most likely to write the first version in practice (I don't
mind the repetition, as long as it is simple) - but without the rest of
the context it is hard to guess what I would actually use in a given
situation.
>
> <snip>
>>> I would never want to loose it. I don't recall any hard-to-find errors
>>> caused bye a misplaced assignment. They do cause errors, but they get
>>> found (in my experience) in the first compile (if the compiler warns
>>> about it) or in the first test run. I am sure someone has a horror
>>> story of how it took a team of experts months of work to find a
>>> misplaced x--, but rare cases make bad language design.
>>
>> A good compiler can warn about suspicious testing of assignment (such as
>> "if (x = 10) ..."). However, that requires a good compiler, and
>> appropriate use of warnings. I bet that every time you intend to write
>> something like "if (a = b)", you will write "if ((a = b))" - in order to
>> make it clear to the compiler and the reader that you really mean an
>> assignment and not a comparison, and do avoid compile-time warnings.
>
> No, because it seems very rare to me. It's uncommon to have a bare
> assignment where the assigned value is the correct one to test. I am
> sure it happens every now and then, but it's not common enough for me to
> have wanted a way round the warnings about it.
>
> It's very common (in my sort of code) when the assignment is implicit
> (as in while (n--) or while (*--cp) and so on) but those never give you
> a warning -- the compiler assumes you are using the band saw correctly.
I am quite happy with things like "while (n--)" (although if the
language didn't support it, I would not see it as a big loss). Perhaps
that is slightly inconsistent of me - my "line" may be more of a wiggle
if you look closely!
>
>> Assuming that's true, it shows clearly that the syntax of C is
>> considered non-ideal here, and you prefer to partially disable the C
>> feature and replace it with a new and less risky syntax.
>
> I'd prefer a "sic" annotation to disable the warning rather than some
> mysterious syntax like superfluous parentheses. As it is, I just live
> with the warning when they happen, but then I just program for fun these
> days so I'm not really a good example.
>
It's very rare that I would need the extra parenthesis, because I rarely
write code that would trigger the warning. And it is quite likely that
I would put a comment along with it to explain the odd code.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-07 15:40 -0800 |
| Message-ID | <a0fbecd8-32fc-4ed3-8877-28f5da80f8a2@googlegroups.com> |
| In reply to | #78148 |
On Monday, December 7, 2015 at 5:11:07 PM UTC-6, David Brown wrote: > One thing that makes a difference here is that compilers for embedded > systems have often been poorer at helping developers write correct code, > than compilers on bigger systems (such as gcc, icc, msvc). On the flip side, many embedded systems compilers regarded C as being a low- level language such that operations in C which mapped clearly to operations on the target platform would inherit the target-platform semantics in cases where the C Standard imposed no requirements--a very useful characteristic in a language used for embedded programming, and one which should be embraced in an embedded C standard. It's too bad that efforts at writing such a standard seem to have gotten stalled, since the increasing aggressiveness of optimizers is increasing the need for it.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-12-08 12:55 +1300 |
| Message-ID | <dcmkjnF3951U7@mid.individual.net> |
| In reply to | #78148 |
David Brown wrote: > > One thing that makes a difference here is that compilers for embedded > systems have often been poorer at helping developers write correct code, > than compilers on bigger systems (such as gcc, icc, msvc). Many > embedded compilers have been niche products - they are often slightly > weird, have unusual extensions, perhaps don't fully support C standards, > are often way behind the times (such as being ANSI/C89 only), and often > have poor warnings. (That is changing now, as gcc is dominating > embedded development.) Combined with very limited debugging > possibilities on many systems, this means that slips such as writing "if > (a = b)" instead of "if (a == b)" can be harder to spot on older > embedded development systems than it would be on desktop systems. Which is why I always develop and unit test embedded code in a hosted environment, usually using a couple of compilers. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-08 00:43 +0000 |
| Message-ID | <87egex93cy.fsf@bsb.me.uk> |
| In reply to | #78148 |
David Brown <david.brown@hesbynett.no> writes:
> On 07/12/15 21:57, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 07/12/15 01:13, Ben Bacarisse wrote:
<snip>
>>>> No matter how simple the code to set c (and it's just a function call
>>>> here) I get annoyed when a language makes me repeat myself:
>>>>
>>>> int c = getchar();
>>>> while (c != EOF && c != '\n') {
>>>> // ... do stuff with c ...
>>>> c = getchar();
>>>> }
>>>
>>> int c;
>>> while (true) {
>>> c = getchar();
>>> if ((c == EOF) || (c == '\n')) break;
>>> // do stuff...
>>> }
>>
>> Well, that's another one for the Usenet programming anthropology
>> notebook. I've seen code like that before, of course, so I know people
>> like to write it, but I don't recall meeting someone who advocates it.
>> (And now three come along in one thread.)
>
> It's an alternative since you didn't want to repeat the getchar(). I
> would be most likely to write the first version in practice (I don't
> mind the repetition, as long as it is simple) - but without the rest
> of the context it is hard to guess what I would actually use in a
> given situation.
Ah, I see. It seems that maybe only BartC is in favour of this
version.
I don't mind repetition per se (sometimes you just have to write several
getchar calls), it's the fact that the two getchar calls are logically
the same that bugs me. You need to write two just to get the same
execution ordering that you get from one in the simpler version. So,
for me, it's not just (as Eric pointed out) that changes to them must be
synchronised, it's the irritation of them being, essentially, the same
but written separately.
C's IO is designed round this "try it first" style. The getchar example
is a simple one, but you might have a much more complex IO operation:
while ((n = fread(data, sizeof *data, N_ITEMS, fp)) > 0) {
// use data[0] ... data[n-1]
}
Would you duplicate that here or switch to the while (1) ... break pattern?
Finally, there are complex cases where you often have no assignment
except as a side effect of a function call. I presume that's OK, and
you would not duplicate the scanf here:
while (scanf("%d: %d %10s", &lno, &n, word) == 4) {
// ...
}
So maybe I can tempt you with
char c;
while (scanf("%c", &c) == 1 && c != '\n') {
// ...
}
Is that better?
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-08 01:28 +0000 |
| Message-ID | <n45bkk$6h2$1@dont-email.me> |
| In reply to | #78157 |
On 08/12/2015 00:43, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> C's IO is designed round this "try it first" style. The getchar example
> is a simple one, but you might have a much more complex IO operation:
>
> while ((n = fread(data, sizeof *data, N_ITEMS, fp)) > 0) {
> // use data[0] ... data[n-1]
> }
Maybe I just don't like complicated expressions like this as conditions,
especially if they are doing a lot of work.
If an explicit break is not acceptable, then I think I would break that
down:
while (n = fread(data, sizeof *data, N_ITEMS, fp),
n > 0) {
// use data[0] ... data[n-1]
}
The condition is now the simple 'n>0'. Although I've already mentioned
that I prefer to use eof checks when processing files:
while (! my_eof(fp)) {
n = fread(data, sizeof *data, N_ITEMS, fp)
// use data[0] ... data[n-1]
}
The condition is now doing a bit more work, but not as much as reading
in big chunks of data.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-08 01:53 +0000 |
| Message-ID | <87wpsp7ljo.fsf@bsb.me.uk> |
| In reply to | #78164 |
BartC <bc@freeuk.com> writes:
> On 08/12/2015 00:43, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>
>> C's IO is designed round this "try it first" style. The getchar example
>> is a simple one, but you might have a much more complex IO operation:
>>
>> while ((n = fread(data, sizeof *data, N_ITEMS, fp)) > 0) {
>> // use data[0] ... data[n-1]
>> }
>
> Maybe I just don't like complicated expressions like this as
> conditions, especially if they are doing a lot of work.
>
> If an explicit break is not acceptable, then I think I would break
> that down:
>
> while (n = fread(data, sizeof *data, N_ITEMS, fp),
> n > 0) {
> // use data[0] ... data[n-1]
> }
OK. There's not much in it for me in that I have no problem with the
extra parenthesis which is the only real difference.
> The condition is now the simple 'n>0'. Although I've already mentioned
> that I prefer to use eof checks when processing files:
>
> while (! my_eof(fp)) {
> n = fread(data, sizeof *data, N_ITEMS, fp)
> // use data[0] ... data[n-1]
What happens if a read error is detected after my_eof has returned
false? You can't just use data[0] ... data[n-1] because there may be
none. And if you have to test for n > 0, why not use that as the
indicator of success?
> }
>
> The condition is now doing a bit more work, but not as much as reading
> in big chunks of data.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-12-08 16:44 +0000 |
| Message-ID | <56670892.4900890@news.xs4all.nl> |
| In reply to | #78164 |
BartC <bc@freeuk.com> wrote:
> The condition is now the simple 'n>0'. Although I've already mentioned
> that I prefer to use eof checks when processing files:
>
> while (! my_eof(fp)) {
> n = fread(data, sizeof *data, N_ITEMS, fp)
> // use data[0] ... data[n-1]
> }
And how do you propose to write your precognitive eof()? Pascal has that
in its official spec; getting it reliable has always proven to be a
complete canine of the female persuasion, and in some cases impossible.
Richard
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-08 17:47 +0000 |
| Message-ID | <n474uk$nuc$1@dont-email.me> |
| In reply to | #78180 |
On 08/12/2015 16:44, Richard Bos wrote:
> BartC <bc@freeuk.com> wrote:
>
>> The condition is now the simple 'n>0'. Although I've already mentioned
>> that I prefer to use eof checks when processing files:
>>
>> while (! my_eof(fp)) {
>> n = fread(data, sizeof *data, N_ITEMS, fp)
>> // use data[0] ... data[n-1]
>> }
>
> And how do you propose to write your precognitive eof()? Pascal has that
> in its official spec; getting it reliable has always proven to be a
> complete canine of the female persuasion, and in some cases impossible.
What are the problems in implementing such an eof function? Other the
ones that can make just about any file processing impossible to those
who are paranoid enough.
(I've been using eof-testing functions of one form or another for
several decades and I don't recall ever having any problems.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-08 10:46 -0800 |
| Message-ID | <ln6108ok1s.fsf@kst-u.example.com> |
| In reply to | #78191 |
BartC <bc@freeuk.com> writes:
> On 08/12/2015 16:44, Richard Bos wrote:
>> BartC <bc@freeuk.com> wrote:
>>> The condition is now the simple 'n>0'. Although I've already mentioned
>>> that I prefer to use eof checks when processing files:
>>>
>>> while (! my_eof(fp)) {
>>> n = fread(data, sizeof *data, N_ITEMS, fp)
>>> // use data[0] ... data[n-1]
>>> }
>>
>> And how do you propose to write your precognitive eof()? Pascal has that
>> in its official spec; getting it reliable has always proven to be a
>> complete canine of the female persuasion, and in some cases impossible.
>
> What are the problems in implementing such an eof function? Other the
> ones that can make just about any file processing impossible to those
> who are paranoid enough.
>
> (I've been using eof-testing functions of one form or another for
> several decades and I don't recall ever having any problems.)
Suppose you're reading characters from an interactive source such as a
keyboard.
The usual C idiom is:
int c;
while ((c = getchar()) != EOF) { /* ... */ }
which tests for an end-of-file condition by checking the value returned
by getchar().
The alternative is to test for end-of-file *before* attempting to read
the next character.
while (not at end-of-file) {
read the next character
/* ... */
}
But the only way to know that there are no more characters to be read is
to attempt to read the next character. You don't know whether the user
is *just about to* type Ctrl-D (or Ctrl-Z, or ...).
If you're reading from a disk file this isn't (necessarily) a 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-08 19:27 +0000 |
| Message-ID | <n47arl$hh9$1@dont-email.me> |
| In reply to | #78195 |
On 08/12/2015 18:46, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 08/12/2015 16:44, Richard Bos wrote:
>>> And how do you propose to write your precognitive eof()? Pascal has that
>>> in its official spec; getting it reliable has always proven to be a
>>> complete canine of the female persuasion, and in some cases impossible.
>>
>> What are the problems in implementing such an eof function? Other the
>> ones that can make just about any file processing impossible to those
>> who are paranoid enough.
>>
>> (I've been using eof-testing functions of one form or another for
>> several decades and I don't recall ever having any problems.)
>
> Suppose you're reading characters from an interactive source such as a
> keyboard.
>
> The usual C idiom is:
>
> int c;
> while ((c = getchar()) != EOF) { /* ... */ }
>
> which tests for an end-of-file condition by checking the value returned
> by getchar().
>
> The alternative is to test for end-of-file *before* attempting to read
> the next character.
>
> while (not at end-of-file) {
> read the next character
> /* ... */
> }
>
> But the only way to know that there are no more characters to be read is
> to attempt to read the next character. You don't know whether the user
> is *just about to* type Ctrl-D (or Ctrl-Z, or ...).
>
> If you're reading from a disk file this isn't (necessarily) a problem.
Well, I wouldn't bother using the eof idiom for interactive input which
doesn't a well-defined end-of-file. (There might be Ctrl D, Ctrl Z or
Ctrl C keys, but these are ways to break out of a program, and don't
need any help.)
Also, your loop still doesn't know whether it can terminate until it's
waited for the next character, which will be EOF or not EOF.
However, I tried the following on stdin and it seemed to be reasonably
well-behaved:
#include <stdio.h>
int eof(FILE* f){
int c;
c=fgetc(f);
if (c==EOF) return 1;
ungetc(c,f);
return 0;
}
int main(void) {
int c;
while (!eof(stdin)) {
c=fgetc(stdin);
switch (c) {
case '\n':
printf("%d <NL>\n",c);
break;
default:
printf("%d <%c>\n",c,c);
}
}
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-08 12:30 -0800 |
| Message-ID | <lnwpson0nf.fsf@kst-u.example.com> |
| In reply to | #78199 |
BartC <bc@freeuk.com> writes:
> On 08/12/2015 18:46, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 08/12/2015 16:44, Richard Bos wrote:
>
>>>> And how do you propose to write your precognitive eof()? Pascal has that
>>>> in its official spec; getting it reliable has always proven to be a
>>>> complete canine of the female persuasion, and in some cases impossible.
>>>
>>> What are the problems in implementing such an eof function? Other the
>>> ones that can make just about any file processing impossible to those
>>> who are paranoid enough.
>>>
>>> (I've been using eof-testing functions of one form or another for
>>> several decades and I don't recall ever having any problems.)
>>
>> Suppose you're reading characters from an interactive source such as a
>> keyboard.
>>
>> The usual C idiom is:
>>
>> int c;
>> while ((c = getchar()) != EOF) { /* ... */ }
>>
>> which tests for an end-of-file condition by checking the value returned
>> by getchar().
>>
>> The alternative is to test for end-of-file *before* attempting to read
>> the next character.
>>
>> while (not at end-of-file) {
>> read the next character
>> /* ... */
>> }
>>
>> But the only way to know that there are no more characters to be read is
>> to attempt to read the next character. You don't know whether the user
>> is *just about to* type Ctrl-D (or Ctrl-Z, or ...).
>>
>> If you're reading from a disk file this isn't (necessarily) a problem.
>
> Well, I wouldn't bother using the eof idiom for interactive input which
> doesn't a well-defined end-of-file. (There might be Ctrl D, Ctrl Z or
> Ctrl C keys, but these are ways to break out of a program, and don't
> need any help.)
Ctrl-D (on Unix-like systems) or Ctrl-Z (on Windows) are way to trigger
and end-of-file condition, *not* to break out of a program.
Programs that read from stdin can work equally well reading from a
keyboard or a disk file, and can handle the end-of-file (or error)
condition in the same way.
> Also, your loop still doesn't know whether it can terminate until it's
> waited for the next character, which will be EOF or not EOF.
>
> However, I tried the following on stdin and it seemed to be reasonably
> well-behaved:
>
> #include <stdio.h>
>
> int eof(FILE* f){
> int c;
>
> c=fgetc(f);
> if (c==EOF) return 1;
> ungetc(c,f);
>
> return 0;
> }
>
> int main(void) {
> int c;
>
> while (!eof(stdin)) {
> c=fgetc(stdin);
> switch (c) {
> case '\n':
> printf("%d <NL>\n",c);
> break;
> default:
> printf("%d <%c>\n",c,c);
> }
> }
> }
I might take a look at it later. My only immediate comment is that it's
a lot of unnecessary extra code compared to the usual idiom of checking
in the loop whether fgetc() returned EOF.
--
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 | 2015-12-08 12:37 -0800 |
| Message-ID | <9f499441-6c43-431f-9597-69458234aad0@googlegroups.com> |
| In reply to | #78202 |
On Tuesday, December 8, 2015 at 2:31:01 PM UTC-6, Keith Thompson wrote: > Ctrl-D (on Unix-like systems) or Ctrl-Z (on Windows) are way to trigger > and end-of-file condition, *not* to break out of a program. Control-D causes any pending I/O request on the keyboard to return immediately with whatever data has been typed since the last newline or control-D. If a program is performing an fread on the console, it will return with zero characters. Since the normal reason for a zero-character fread is an end-of- file condition, many programs will interpret the zero-character fread in that fashion, but that doesn't mean it's a "real" end-of-file condition, since future fread operations from the console may return data.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-08 21:47 +0000 |
| Message-ID | <n47j1f$k2m$1@dont-email.me> |
| In reply to | #78202 |
On 08/12/2015 20:30, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> int eof(FILE* f){
....
>> while (!eof(stdin)) {
...
>> }
>> }
>> }
>
> I might take a look at it later. My only immediate comment is that it's
> a lot of unnecessary extra code compared to the usual idiom of checking
> in the loop whether fgetc() returned EOF.
(1) You write eof() once then forget about it
(2) The advantage is that you then *don't* need to bother messing with
EOF checking if reading a character at a time
(3) You *know* more data is available when you do the read (or
technically, was available at the time of the eof check)
(4) The eof-checking loop becomes the new idiom for all sorts of serial
file reading not just character-based. Code can get simpler:
while (!eof(f)) putchar(fgetc(f));
--
bartc
[toc] | [prev] | [next] | [standalone]
Page 6 of 20 — ← Prev page 1 … 4 5 [6] 7 8 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web