Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #98254 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2016-12-07 05:08 -0800 |
| Last post | 2016-12-10 13:49 -0800 |
| Articles | 20 on this page of 180 — 22 participants |
Back to article view | Back to comp.lang.c
while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 05:08 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 13:46 +0000
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 07:27 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 16:17 +0000
Re: while loop vs do while loop reading from the file issue Norbert_Paul <norbertpauls_spambin@yahoo.com> - 2016-12-07 14:54 +0100
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 07:29 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 17:20 +0000
Re: while loop vs do while loop reading from the file issue "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-08 01:24 +0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 22:51 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 07:30 +0000
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-07 12:45 -0500
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 17:50 +0000
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-07 12:56 -0500
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-07 11:09 -0800
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-07 14:38 -0500
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 23:29 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 07:35 +0000
Re: while loop vs do while loop reading from the file issue Manfred <noname@invalid.add> - 2016-12-08 16:57 +0100
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 03:45 -0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-09 01:08 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-09 01:30 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-09 01:50 -0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 02:34 -0800
Re: while loop vs do while loop reading from the file issue fir <profesor.fir@gmail.com> - 2016-12-10 03:18 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-10 07:43 -0800
Re: while loop vs do while loop reading from the file issue Manfred <noname@invalid.add> - 2016-12-10 18:21 +0100
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 10:08 +0000
Re: while loop vs do while loop reading from the file issue Manfred <noname@invalid.add> - 2016-12-09 19:19 +0100
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 03:56 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-10 12:39 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 14:58 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-10 16:01 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 19:47 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-10 20:16 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 21:11 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-10 22:33 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 23:50 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 00:35 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-10 16:52 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 01:34 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 02:25 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 17:11 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 18:00 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 19:44 +0000
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-11 13:11 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 22:40 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 02:03 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-12 12:53 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-12 13:04 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 13:27 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-12 15:16 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 23:00 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 00:59 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 03:25 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 13:08 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 05:56 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 15:31 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 08:27 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 18:07 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 18:12 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 18:26 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 18:34 +0000
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2016-12-13 18:39 +0000
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-13 13:47 -0500
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 19:03 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 11:30 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 20:10 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 12:42 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 21:29 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 14:27 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 22:56 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 16:13 -0800
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-14 07:33 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-14 09:05 -0800
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-13 12:48 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 21:37 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 00:08 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 01:24 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 17:56 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-14 02:33 +0000
Re: while loop vs do while loop reading from the file issue David Brown <david.brown@hesbynett.no> - 2016-12-14 10:03 +0100
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 02:09 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 12:24 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 13:00 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-14 08:54 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-14 17:01 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 17:27 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 20:24 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-15 10:47 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-15 11:54 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 04:02 -0800
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-15 07:40 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-15 11:48 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 01:52 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-16 11:09 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 18:35 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 20:18 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 20:14 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 20:15 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 22:26 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 02:19 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 12:45 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-14 14:00 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 20:59 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 21:59 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-15 02:42 +0000
Re: while loop vs do while loop reading from the file issue asetofsymbols@gmail.com - 2016-12-15 01:20 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 09:28 +0000
Re: while loop vs do while loop reading from the file issue asetofsymbols@gmail.com - 2016-12-15 01:42 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 09:53 +0000
Re: while loop vs do while loop reading from the file issue asetofsymbols@gmail.com - 2016-12-15 01:55 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 02:03 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 10:13 +0000
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2016-12-15 22:05 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 14:15 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-15 10:44 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 03:31 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 01:11 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 06:16 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 17:24 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 09:53 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 20:38 +0000
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2016-12-16 21:13 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 21:50 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 14:19 -0800
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-16 15:03 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 02:20 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-17 02:21 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 12:14 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-17 04:56 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 19:28 +0000
Re: while loop vs do while loop reading from the file issue Ike Naar <ike@iceland.freeshell.org> - 2016-12-17 22:51 +0000
Re: while loop vs do while loop reading from the file issue Les Cargill <lcargill99@comcast.com> - 2016-12-17 11:45 -0600
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 19:42 +0000
Re: while loop vs do while loop reading from the file issue Les Cargill <lcargill99@comcast.com> - 2016-12-17 20:39 -0600
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-18 10:49 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-16 09:41 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 10:01 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-16 12:31 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 13:33 -0800
Re: while loop vs do while loop reading from the file issue Ian Collins <ian-news@hotmail.com> - 2016-12-17 11:12 +1300
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 14:30 -0800
Re: while loop vs do while loop reading from the file issue raltbos@xs4all.nl (Richard Bos) - 2016-12-20 11:16 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 03:29 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 16:13 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 01:09 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-10 16:08 -0800
Re: while loop vs do while loop reading from the file issue Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2016-12-11 01:31 +0100
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 14:52 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 15:26 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 16:22 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 16:42 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 16:56 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-11 12:56 -0800
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-11 08:55 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 17:19 +0000
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 04:09 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 15:18 +0000
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 07:30 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 15:43 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-10 14:56 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-10 07:57 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-09 11:40 -0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 03:19 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-10 07:49 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 16:11 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-10 14:45 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 22:59 +0000
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-08 11:26 -0500
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-08 11:48 -0500
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-11 23:33 -0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 23:09 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-07 09:53 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-07 11:26 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-07 11:50 -0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 23:12 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 07:31 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 11:00 +0000
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-09 00:48 -0800
Re: while loop vs do while loop reading from the file issue Siri Cruise <chine.bleu@yahoo.com> - 2016-12-10 13:49 -0800
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-14 02:19 +0000 |
| Message-ID | <87bmwf8d7a.fsf@bsb.me.uk> |
| In reply to | #99282 |
BartC <bc@freeuk.com> writes:
> On 13/12/2016 20:15, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> If there's anything wrong then an empty string is produced.
>>
>> Then I got the name wrong. I meant your language's way of reading three
>> numbers (I did write "readLn x, y, z" and we are talking about exactly
>> that sort of input). Here, I think, errors reading x, y and z are
>> ignored you just supply some default.
>
> Yes. So? It's just a choice I made.
Yes, but not a /good/ choice, in my option. If, say, a read operation
were to return a count of successfully translated numeric items you
could do more with it. You don't have to use the value, but it's there
if you need it, telling you important information that is expensive to
recover. The implementation cost is next to nothing since you need to
decide if there is a number there in order to implement the default
value behaviour.
C does it like this:
while (fgets(line, sizeof line, fp)) {
double x = 0, y = 0, z = 0;
if (sscanf(line, "%g %g %g", &x, &y, &z) > 1)
// process lines with at least one number (others taken as 0)
}
or change the > 1 to == 3 and process only those with three numbers.
Your readLn appears to be a statement without any signalling that goes
back to the caller. That design has leaking into your C with most the
functions not returning any indication of success (readlinen is void and
the conversion functions just have ago).
> What we're talking about is the file-reading framework. Once you have
> a sequence of strings coming in, then you can choose more
> sophisticated error handling. If it's needed.
>
> But you want to keep the data-parsing stuff separate from the
> house-keeping to do with traversing a file. I want to anyway; I guess
> you don't.
I have said nothing that would make you think that. Look at both my C
code for your "challenge" and the C code above.
>>> The thing is, in a program that reads a 20-line configuration file,
>>> you don't really want to deal comprehensively with all those
>>> possibilities.
>>
>> I bet on another day you might post about some daft Linux program where
>> you wasted hours trying to find what was wrong when it turned out the
>> code just ignored errors like O.356 and blithely assumed zero.
>
> Then the file has been manually generated or edited or maliciously
> tampered with or somehow corrupted. Instead of 0.356 that figure could
> have appeared as 0.536; a bit nearer to the true figure then 0.0, but
> still not quite right.
I don't follow this at all. Would you not want to be told that there is
an error in the input? You've said you don't want that for a config
file but I'm just saying I bet you would if the error I showed had
annoyed you enough.
>> Anyway, maybe your language /can/ report an error with numerical input,
>> but your C code does not
>
> Any language can, including these two. But as I keep saying, whether
> the data parsing is crude or sophisticated should not determine
> whether you use an eof loop or not.
Indeed. You should not, in C, use an eof test no matter what parsing
you have to do with the input text afterwards. (There are exceptions,
but we are taking about line oriented input here.) As I keep pointing
out how your code could be shorter and simpler if you removed the eof
function.
>> You code uses a daft test for numerical input.
>
> Actually it uses pretty much the same method as a proper lexer, when
> it looks at the start character to see how to proceed.
But the lexer will then go on and make the right choice. In your case
you only start as a lexer would. My version leverages the floating
point lexer built in to scanf to decide if there is a number present.
You also use that lexer but you discard some of the information that
comes out of it.
>> If it sees a digit or +, -, or . you assume there's data. To me, a line
>> with just
>>
>> -----------------------------------
>
>> on it is just as worthy of being skipped as one that says
>>
>> The data points are:
>
> So what would your criteria be for determining if a line is a valid
> candidate for a data line?
I decided your specification was intended to mean process a line if it
starts with a number ans skip lines like ".....". That was my
application of the common sense you asked me use. The criterion I would
actually use is that there are three numbers on the line, since the code
goes on to use three numbers. However, it was clear that that was not
the inntent of your specification by an stretch of the imagination.
> Would you apply sscanf and "%lf" to the
> whole line to see if it can make sense of it? (That would be a bit
> like attempting to read a line before you know if there's any more
> input!)
I wrote out the code for you -- there is no need to speculate what I
would do. It's only a handful of lines of C. I even said how to switch
to my preferred semantics: change > 0 to == n_items in one function. A
tiny change. Note how the file input and the parsing are separate
(despite your saying above the I want to mix them up).
I keep asking you how you would make that change in your C program but
you don't say.
>>> I don't think it should be tied so much to a language. Reading stuff
>>> from a file is reading stuff from a file.
>>
>> Nonsense. Languages vary hugely in how they implement IO, and using the
>> language's IO system properly is just good programming.
>
> C's IO system allows my code as well as yours to operate.
Of course. And I can write longer more complex versions than yours. I
don't see what that shows.
> Under Windows, C's IO functions are presumably built around WinAPI
> functions, which is what I used to use directly. Those include a
> ReadFile() function to read N bytes, just like C's fread().
>
> While Posix I believe has read() which does similar.
>
> So all languages have to build their IO around the same set of
> functions. Are they really going to be that different?
Yes. Here's the Pascal to sum some input numbers:
program numbers;
var x, sum: real;
begin
sum := 0;
while not eof do begin
read(x);
sum := sum + x
end;
writeln('Sum = ', sum);
end.
What if I want to stop reading when I see the first thing that is not a
number? Or maybe I want to process all the numbers and simply ignore
the non-numeric stuff? I am trapped by Pascal's IO model. The only way
out is to write the whole floating-point input function again but with
extra data being returned on the success or otherwise of the input.
If I could say
if read(x) then sum := sum + x;
I would be home and dry. That's the C way. The language's model of IO
is important.
>>> Everything within the body of the loop then is working with in-memory
>>> strings and can forget about file errors.
>>
>> But not always data errors.
>
> lines:=readlines("input")
>
> # At this point, we've finished with file-handling.
> # Just processing to do:
>
> case user
> when "bart" then
> processlines_lowspec(lines)
> when "ben" then
> processlines_highspec(lines)
> else
> processlines_defaultspec(lines)
> esac
What am I to get from this? Your C code ignores data errors. That you
can write some other program that does not is beside the point. I asked
if the support functions in your code were the ones you use for your
language because that would explain why they are so un-C-like. It would
mean that you've carried over a model from one language (that may
provide other solutions to these problems, I can't possibly know) into
C. That's generally not a good idea and it certainly isn't in this
case.
And it applies to the eof issue to. If the use of your eof function and
the fact that your readlinen function does not report errors are just
artefacts of the translation then they don't need explaining, but if you
chose to write the C that way they most certainly do. (It doesn't make
it the right way to do the line input, but at least it would explain
it.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-14 12:45 +0000 |
| Message-ID | <o2repr$uqa$1@dont-email.me> |
| In reply to | #99303 |
On 14/12/2016 02:19, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
> As I keep pointing
> out how your code could be shorter and simpler if you removed the eof
> function.
See my other recent post of 30 minutes ago. Code using eof on the
Rosetta site is generally easier to follow.
>> So all languages have to build their IO around the same set of
>> functions. Are they really going to be that different?
>
> Yes. Here's the Pascal to sum some input numbers:
>
> program numbers;
> var x, sum: real;
> begin
> sum := 0;
> while not eof do begin
> read(x);
> sum := sum + x
> end;
> writeln('Sum = ', sum);
> end.
>
> What if I want to stop reading when I see the first thing that is not a
> number? Or maybe I want to process all the numbers and simply ignore
> the non-numeric stuff? I am trapped by Pascal's IO model.
I'm not convinced. Here's the way you say you would this stuff in C:
> while (fgets(line, sizeof line, fp)) {
> double x = 0, y = 0, z = 0;
> if (sscanf(line, "%g %g %g", &x, &y, &z) > 1)
> // process lines with at least one number (others taken as 0)
> }
>
Here's the same approach but using my entirely different, dynamic and
interpreted language:
import clib
...
line:=" "*100
while fgets(line, line.len, f) do
x := y := z := 0.0
if sscanf(line, "%lg %lg %lg", &x, &y, &z)>1 then
println x, y, z
fi
od
Being able to call foreign functions, especially C, is common.
But some choose to to do things little differently, often for a good
reason. Or it's possible to mix and match:
while not eof(f) do
x:=y:=z:=0.0
if sscanf(sreadln(f), "%lg %lg %lg", &x,&y,&z)>1 then
println x,y,z
fi
od
However I would normally write such a thing more informally like this
and it should be clear why:
while not eof(f) do
readln @f,x,y,z
println x,y,z
od
Why shouldn't someone introduce the same kind of informality into C? Not
every program is going to be launching a space rocket (and they don't
always get it right).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-14 14:00 +0000 |
| Message-ID | <o2rj7p$e8u$1@dont-email.me> |
| In reply to | #99333 |
On 14/12/16 12:45, BartC wrote: > On 14/12/2016 02:19, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >> As I keep pointing >> out how your code could be shorter and simpler if you removed the eof >> function. > > See my other recent post of 30 minutes ago. Code using eof on the > Rosetta site is generally easier to follow. Easier for you, perhaps. It has to be said that you have so many problems with basic C concepts and tools that, when you say something is "harder to follow" or "easier to follow", it carries very little weight. In general, people have no difficulty with idiomatic C input loops. That you /do/ have difficulty with them comes as no surprise, because you seem to find everything about C difficult. There's nothing wrong with that, of course - I would find everything in APL difficult - but if you are determined to use C, you would get on with it better if you went with its flow instead of trying to fight it the whole time. -- 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 | 2016-12-14 20:59 +0000 |
| Message-ID | <87poku5ism.fsf@bsb.me.uk> |
| In reply to | #99333 |
BartC <bc@freeuk.com> writes:
> On 14/12/2016 02:19, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>> As I keep pointing
>> out how your code could be shorter and simpler if you removed the eof
>> function.
>
> See my other recent post of 30 minutes ago. Code using eof on the
> Rosetta site is generally easier to follow.
OK, then you see my reply to that. If we keep this up you may be able
to avoid ever saying that the shorter simpler code is easy enough to
understand.
>>> So all languages have to build their IO around the same set of
>>> functions. Are they really going to be that different?
>>
>> Yes. Here's the Pascal to sum some input numbers:
>>
>> program numbers;
>> var x, sum: real;
>> begin
>> sum := 0;
>> while not eof do begin
>> read(x);
>> sum := sum + x
>> end;
>> writeln('Sum = ', sum);
>> end.
>>
>> What if I want to stop reading when I see the first thing that is not a
>> number? Or maybe I want to process all the numbers and simply ignore
>> the non-numeric stuff? I am trapped by Pascal's IO model.
>
> I'm not convinced.
Then show me how in Pascal. Your point was that the language did not
matter -- it's bytes in the end. If Pascal's model has not trapped me,
show me show how to get out.
> Here's the way you say you would this stuff in C:
>
>> while (fgets(line, sizeof line, fp)) {
>> double x = 0, y = 0, z = 0;
>> if (sscanf(line, "%g %g %g", &x, &y, &z) > 1)
>> // process lines with at least one number (others taken as 0)
>> }
That's not how I would do "this stuff" in C. It's how I would do one
specific thing in C. Given that your response appears to be to post
something in your private language, can I take you have no issues with
that loop pattern?
> Here's the same approach but using my entirely different, dynamic and
> interpreted language:
For Pete's sake stop with your languages. We both know they are perfect
but that's not the issue. You can't say "the language does not matter,
it's all input" and then choose the language to make some particular
point. If the language's IO model does not matter, it should be easy to
illustrate anything in any of them. I gave a Pascal example because,
unlike your language, we both have access to the specification and we
can both (in principle at least) actually compile and run programs in
it. Show me how to do what I asked in Pascal. It's easy in C.
<snip>
Do you not agree that, in C, the loop above is the better without the extra
eof function and the redundant eof() call?
Do you not agree that your readlinen function would have been more
useful if it had returned som sort of indication of success?
Do you not agree that your strtofloat and readfloat functions would have
been more useful if they could indicate success or failure?
These seem to be un-contentious matters, but if you do disagree, take my
challenge and change your program to process only lines that actually
have three numbers on them (rather than lines that look like they
might). It's not hard (about 19 lines I seem to remember) but it's hard
with the support function you were using.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-14 21:59 +0000 |
| Message-ID | <o2sfa2$nk5$1@dont-email.me> |
| In reply to | #99413 |
On 14/12/2016 20:59, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> Here's the way you say you would [do] this stuff in C:
>>
>>> while (fgets(line, sizeof line, fp)) {
>>> double x = 0, y = 0, z = 0;
>>> if (sscanf(line, "%g %g %g", &x, &y, &z) > 1)
>>> // process lines with at least one number (others taken as 0)
>>> }
>
> That's not how I would do "this stuff" in C. It's how I would do one
> specific thing in C. Given that your response appears to be to post
> something in your private language, can I take you have no issues with
> that loop pattern?
>
>> Here's the same approach but using my entirely different, dynamic and
>> interpreted language:
>
> For Pete's sake stop with your languages. We both know they are perfect
> but that's not the issue. You can't say "the language does not matter,
> it's all input" and then choose the language to make some particular
> point.
The point is that any language that can call foreign functions can
probably call the C runtime library.
Any language that does real work under Windows for example needs to talk
to the Win32 API so calling the C runtime should be child's play.
I don't know if the original Pascal can do that (it was a teaching
language), but ones such as Delphi apparently can talk to a dynamic
library. I'm not however going to download some massive installation
then spend a month trying to learn how to use it in order to prove some
point.
I showed that your approach can be duplicated in other language, and I
was able to adapt that to use an eof() check with little effect on
readability (other than to improve it!). And then I showed how the
sscanf stuff can be tamed too.
> If the language's IO model does not matter, it should be easy to
> illustrate anything in any of them. I gave a Pascal example because,
> unlike your language, we both have access to the specification and we
> can both (in principle at least) actually compile and run programs in
> it. Show me how to do what I asked in Pascal. It's easy in C.
OK, here is your style of file-reading loop in x64 assembly:
http://pastebin.com/y193x07D
There's no C source involved, but it uses the C library as that will
generally be available.
I'm sure there's plenty of info about x64 and NASM syntax around.
> <snip>
>
> Do you not agree that, in C, the loop above is the better without the extra
> eof function and the redundant eof() call?
That's a matter of opinion. I think controlling these loops with
eof-checking is simpler and more general, and is a common techniques
amongst languages that don't use ultra-high level features for file
handling. Others disagree.
But the difference between using eof() and not using it is small,
especially if the main loop is doing line i/o anyway. I can't believe
the size of this thread. And your questions (you keep saying I'm a
politician; are you sure you aren't a lawyer?).
> Do you not agree that your readlinen function would have been more
> useful if it had returned som sort of indication of success?
Probably. What would it have returned as a value? I'd have preferred the
length of the line, but fgets doesn't provide that; it needs to use
strlen, so the caller might as well do it.
> Do you not agree that your strtofloat and readfloat functions would have
> been more useful if they could indicate success or failure?
They would be more useful if they could be written as:
x = readfloat(lineptr);
with an optional set of parameters that could deal with error returns or
return more information about what was read. But that's a C limitation.
Not having optional parameters would make it unwieldy to do any more
than it does, without spending a lot more time on design.
> These seem to be un-contentious matters, but if you do disagree, take my
> challenge and change your program to process only lines that actually
> have three numbers on them (rather than lines that look like they
> might). It's not hard (about 19 lines I seem to remember) but it's hard
> with the support function you were using.
You challenged me to write a file-reading loop using an eof() check as
the loop condition:
while (!myeof(f)) {....}
You didn't like it, preferring your version:
while (n_rows < MAX_ROWS &&
can_read_numbers(f, N_COLUMNS, data[n_rows])) ....
(It would be interesting to show these code fragments to someone who's
not aware of the thread and see if they can guess the broad purpose of
each bit, and whether either of them have anything to do with files.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-15 02:42 +0000 |
| Message-ID | <87bmwd6hfx.fsf@bsb.me.uk> |
| In reply to | #99420 |
BartC <bc@freeuk.com> writes:
> On 14/12/2016 20:59, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> Here's the way you say you would [do] this stuff in C:
>>>
>>>> while (fgets(line, sizeof line, fp)) {
>>>> double x = 0, y = 0, z = 0;
>>>> if (sscanf(line, "%g %g %g", &x, &y, &z) > 1)
>>>> // process lines with at least one number (others taken as 0)
>>>> }
>>
>> That's not how I would do "this stuff" in C. It's how I would do one
>> specific thing in C. Given that your response appears to be to post
>> something in your private language, can I take you have no issues with
>> that loop pattern?
>>
>>> Here's the same approach but using my entirely different, dynamic and
>>> interpreted language:
>>
>> For Pete's sake stop with your languages. We both know they are perfect
>> but that's not the issue. You can't say "the language does not matter,
>> it's all input" and then choose the language to make some particular
>> point.
>
> The point is that any language that can call foreign functions can
> probably call the C runtime library.
And any language can simulate a Turning machine so we can all go home
now.
<snip>
> I showed that your approach can be duplicated in other language,
Not in Pascal you didn't (yet). I chose it because it has a famously
inflexible IO model. If an extension to Pascal allows it to be done
properly by calling some other functions (particularly from another
language) then that rather misses the point.
> and I
> was able to adapt that to use an eof() check with little effect on
> readability (other than to improve it!). And then I showed how the
> sscanf stuff can be tamed too.
I don't know what you are referring to here. You showed how you can add
an unnecessary function to C programs (eof) and how you can ignore the
return value of the scanf functions. Is that taming them?
>> If the language's IO model does not matter, it should be easy to
>> illustrate anything in any of them. I gave a Pascal example because,
>> unlike your language, we both have access to the specification and we
>> can both (in principle at least) actually compile and run programs in
>> it. Show me how to do what I asked in Pascal. It's easy in C.
>
> OK, here is your style of file-reading loop in x64 assembly:
> http://pastebin.com/y193x07D
>
> There's no C source involved, but it uses the C library as that will
> generally be available.
>
> I'm sure there's plenty of info about x64 and NASM syntax around.
What do you think this shows? We are talking about how things are
written in languages like C (and, as an example of the bad style,
Pascal).
>> <snip>
>>
>> Do you not agree that, in C, the loop above is the better without the extra
>> eof function and the redundant eof() call?
>
> That's a matter of opinion. I think controlling these loops with
> eof-checking is simpler and more general, and is a common techniques
> amongst languages that don't use ultra-high level features for file
> handling. Others disagree.
OK. Let's just agree to disagree then. However, I will have to step in
if you reply to someone learning C suggesting that a special eof
function will make a C input loops simpler. I can't persuade you, but I
am pretty sure that others will be persuaded by the examples.
> But the difference between using eof() and not using it is small,
> especially if the main loop is doing line i/o anyway. I can't believe
> the size of this thread.
Quite. It would have been so simple for you to say "the C way works
perfectly well but I have my own way of doing things".
> And your questions (you keep saying I'm a
> politician; are you sure you aren't a lawyer?).
>
>> Do you not agree that your readlinen function would have been more
>> useful if it had returned som sort of indication of success?
>
> Probably. What would it have returned as a value? I'd have preferred
> the length of the line, but fgets doesn't provide that; it needs to
> use strlen, so the caller might as well do it.
fgets's interface is a real wasted opportunity. That's true for a lot
of the standard library functions. This part of C is a victim of it's
success.
>> Do you not agree that your strtofloat and readfloat functions would have
>> been more useful if they could indicate success or failure?
>
> They would be more useful if they could be written as:
>
> x = readfloat(lineptr);
Did you mean &lineptr?
> with an optional set of parameters that could deal with error returns
> or return more information about what was read. But that's a C
> limitation. Not having optional parameters would make it unwieldy to
> do any more than it does, without spending a lot more time on design.
Again, let's agree to disagree. If it set an "output variable" and
returns a status you can write
readfloat(&lineptr, &x), x
when you want to ignore it. Alternatively you could use
x = readfloat(&lineptr, 0);
(0 for a null pointer to a status result). Finally, you could provide a
wrapper that ignores the status for when you want to do that. None of
these is anything like complex enough to be worth ditching the benefit.
>> These seem to be un-contentious matters, but if you do disagree, take my
>> challenge and change your program to process only lines that actually
>> have three numbers on them (rather than lines that look like they
>> might). It's not hard (about 19 lines I seem to remember) but it's hard
>> with the support function you were using.
>
> You challenged me to write a file-reading loop using an eof() check as
> the loop condition:
>
> while (!myeof(f)) {....}
>
> You didn't like it, preferring your version:
No, I preferred my version overall. For the algorithm you chose, I
preferred a read-line check in the loop. I wrote that out numerous
times asking if you did not think that removing the extra function helps
(I know you don't).
>
> while (n_rows < MAX_ROWS &&
> can_read_numbers(f, N_COLUMNS, data[n_rows])) ....
>
> (It would be interesting to show these code fragments to someone who's
> not aware of the thread and see if they can guess the broad purpose of
> each bit, and whether either of them have anything to do with files.)
Yes, it would. You should also include how easily people can debug the
code, and if they think that what the programs do with a line like this:
---------------------------
is a bad decisions, how easily they can change it. Good code is not all
about initial impressions. (It's a real test since I've not tried
turning mine into yours in this respect. It may be very messy thus
explaining, in part, the different structures we chose.)
But I'd hope no one thinks my version was about files. Almost all
programs like this are better when they don't care about that (just like
yours, barring one line).
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-12-15 01:20 -0800 |
| Message-ID | <e9c94e27-fe02-47b7-a5f0-9918629dfd48@googlegroups.com> |
| In reply to | #99420 |
If you want the loop in C with EOF
I think it is better
something as
while(!eof(fp)&!error(fp))
{instructions...}
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-15 09:28 +0000 |
| Message-ID | <o2tnkp$uf1$1@dont-email.me> |
| In reply to | #99466 |
On 15/12/16 09:20, asetofsymbols@gmail.com wrote:
> If you want the loop in C with EOF
> I think it is better
>
> something as
> while(!eof(fp)&!error(fp))
> {instructions...}
Why do you think that is better than the much more elegant:
while(an attempt to get the data succeeded)
{
do something with the data
}
if(something went wrong)
{
handle it
}
--
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 | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-12-15 01:42 -0800 |
| Message-ID | <38e00208-cef0-476f-8f06-48666dc0f933@googlegroups.com> |
| In reply to | #99468 |
I post that because it seems I read
some where
while(eof(fp))
{}
Could it be possible error(fp)==1 and eof(fp)==0?
Yes the complete input program for
me could be
while(!eof(fp)&!error(fp))
{instructions...}
if(error(fp))return error123;
if(!getinput) return error124;
return 0
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-15 09:53 +0000 |
| Message-ID | <o2tp42$3ob$1@dont-email.me> |
| In reply to | #99469 |
On 15/12/16 09:42, asetofsymbols@gmail.com wrote:
> I post that
Post what? Learn to keep enough context to make sense of your reply.
> because it seems I read
> some where
>
> while(eof(fp))
> {}
>
> Could it be possible error(fp)==1 and eof(fp)==0?
Since you haven't defined the eof() function or the error() function
(neither of which are standard C functions), how can anyone possibly tell?
But if you mean ferror and feof, as far as I am aware the answer is "no".
> Yes the complete input program for
> me could be
>
> while(!eof(fp)&!error(fp))
> {instructions...}
> if(error(fp))return error123;
> if(!getinput) return error124;
> return 0
One obvious problem is this approach is that of code repetition.
Having tested for EOF and for error, you then enter the loop, where
presumably your first job is to retrieve some input. At this point, you
have to check for EOF and, if EOF has indeed been reached, you may even
choose to check for error. If you have to do this within the loop
anyway, why do it in the loop control statement /as well/?
--
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 | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-12-15 01:55 -0800 |
| Message-ID | <c78bf3db-0b94-454b-8e34-6e39adace1f8@googlegroups.com> |
| In reply to | #99468 |
On Thursday, December 15, 2016 at 10:28:19 AM UTC+1, Richard Heathfield wrote:
> On 15/12/16 09:20, asetofsymbols@gmail.com wrote:
> > If you want the loop in C with EOF
> > I think it is better
> >
> > something as
> > while(!eof(fp)&!error(fp))
> > {instructions...}
>
> Why do you think that is better than the much more elegant:
>
> while(an attempt to get the data succeeded)
> {
> do something with the data
> }
> if(something went wrong)
> {
> handle it
> }
Yes I think above it is better
I would write
while(r=getobj(&obj, fp ))
{instructions(); if(something)break;...;}
if(error(fp)) return error123;
if(r==0) return error124;
return 0 // ok
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-15 02:03 -0800 |
| Message-ID | <b3e99481-11dd-4c1c-a902-c3801aa173e4@googlegroups.com> |
| In reply to | #99468 |
On Thursday, December 15, 2016 at 9:28:19 AM UTC, Richard Heathfield wrote:
> On 15/12/16 09:20, asetofsymbols@gmail.com wrote:
> > If you want the loop in C with EOF
> > I think it is better
> >
> > something as
> > while(!eof(fp)&!error(fp))
> > {instructions...}
>
> Why do you think that is better than the much more elegant:
>
> while(an attempt to get the data succeeded)
> {
> do something with the data
> }
> if(something went wrong)
> {
> handle it
> }
>
Because if we change the contents of a while loop to a
magic flag which goes true or false in the same way as
the condition, the program shouldn't change. In other
words, the condition should have no side effects.
while(!endoffile(fp))
{
line = getline(fp);
processline(line);
}
is easier to follow than
while(line = getline(fp))
priocessline(line);
Many compilers will warn about unclear code for method 2.
(You shut them up by adding superfluous parentheses, but
the fact you have to do this shows that the code has
undesireable properties).
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-15 10:13 +0000 |
| Message-ID | <o2tqa0$7i6$1@dont-email.me> |
| In reply to | #99473 |
On 15/12/16 10:03, Malcolm McLean wrote:
> On Thursday, December 15, 2016 at 9:28:19 AM UTC, Richard Heathfield wrote:
>> On 15/12/16 09:20, asetofsymbols@gmail.com wrote:
>>> If you want the loop in C with EOF
>>> I think it is better
>>>
>>> something as
>>> while(!eof(fp)&!error(fp))
>>> {instructions...}
>>
>> Why do you think that is better than the much more elegant:
>>
>> while(an attempt to get the data succeeded)
>> {
>> do something with the data
>> }
>> if(something went wrong)
>> {
>> handle it
>> }
>>
> Because if we change the contents of a while loop to a
> magic flag which goes true or false in the same way as
> the condition, the program shouldn't change.
Why do you think so?
> In other
> words, the condition should have no side effects.
Why not?
> while(!endoffile(fp))
> {
> line = getline(fp);
Stop right there. Before you process this line, how do you know you have
some data to process?
> processline(line);
> }
>
>
> is easier to follow than
>
> while(line = getline(fp))
> priocessline(line);
Why?
> Many compilers will warn about unclear code for method 2.
Well, I can see how a compiler might warn about there being no prototype
for priocessline() :-)
But it's a strawman. The canonical forms are:
while((c = getc(fp)) != EOF)
{
procchar(c);
}
for which the compiler does *not* issue a warning, and
while(fgets(line, sizeof line, fp) != NULL)
{
procline(line);
}
for which, again, the compiler doesn't issue a warning.
> (You shut them up by adding superfluous parentheses,
No, I don't. I don't get the warning because I don't write the code in
the way you suggest.
> but the fact you have to do this shows that the code has
> undesireable properties).
But I don't have to do that. Nor does the addition of superfluous
parentheses necessarily mean bad code. I would, for example, rather see
this expression:
(x << y) | z
in code I was asked to maintain than this one:
x << y | z
even though the parentheses are superfluous.
--
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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-12-15 22:05 +0000 |
| Message-ID | <87y3zgyhj9.fsf@gmail.com> |
| In reply to | #99474 |
Richard Heathfield <rjh@cpax.org.uk> writes: > But I don't have to do that. Nor does the addition of superfluous > parentheses necessarily mean bad code. I would, for example, rather > see this expression: > > (x << y) | z > > in code I was asked to maintain than this one: > > x << y | z > > even though the parentheses are superfluous. Those parentheses are only superfluous if you are a C compiler :)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-15 14:15 -0800 |
| Message-ID | <5534bcfa-4d14-49b9-9c79-45028b21d9bc@googlegroups.com> |
| In reply to | #99474 |
On Thursday, December 15, 2016 at 10:13:48 AM UTC, Richard Heathfield wrote:
> But I don't have to do that. Nor does the addition of superfluous
> parentheses necessarily mean bad code. I would, for example, rather see
> this expression:
>
> (x << y) | z
>
> in code I was asked to maintain than this one:
>
> x << y | z
>
> even though the parentheses are superfluous.
>
I like x, y and z to be names for co-ordinates in Cartesian space.
Whilst never say never, the expression doesn't make much sense
if x, y and z are used at all conventionally.
if we have
newbitrack = bitrack << Nbits | newbits;
it's much less exceptional. (Though I'd agree it's still better
to have the parentheses).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-15 10:44 +0000 |
| Message-ID | <8760ml5v5k.fsf@bsb.me.uk> |
| In reply to | #99473 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, December 15, 2016 at 9:28:19 AM UTC, Richard Heathfield wrote:
>> On 15/12/16 09:20, asetofsymbols@gmail.com wrote:
>> > If you want the loop in C with EOF
>> > I think it is better
>> >
>> > something as
>> > while(!eof(fp)&!error(fp))
>> > {instructions...}
>>
>> Why do you think that is better than the much more elegant:
>>
>> while(an attempt to get the data succeeded)
>> {
>> do something with the data
>> }
>> if(something went wrong)
>> {
>> handle it
>> }
>>
> Because if we change the contents of a while loop to a
> magic flag which goes true or false in the same way as
> the condition, the program shouldn't change. In other
> words, the condition should have no side effects.
That rules out BartC's eof function which he's been promoting to
complicate C input loops. Why didn't you tell him it was a bad idea?
I feel part of the the trouble is an narrow view of the syntax. Doing
something "in the condition" is simply doing something before every test
and I don't think you have an objection to that basic idea:
loop
line := getline(fp)
while line != EOF do
process(line)
end
Here the syntax has some space for the action before every test. If
you think of C's while as being
while (action-before-test,
test) {
body
}
(as I do) you may be happier with this pattern (unless it /is/ the basic
idea that somehow bothers you).
> while(!endoffile(fp))
> {
> line = getline(fp);
> processline(line);
> }
>
>
> is easier to follow than
>
> while(line = getline(fp))
> priocessline(line);
I think it's easy to see that one is right and one is (probably)
wrong -- they do different things so it's reasonable to compare the
snippets.
Anyway, how do you propose to write the endoffile function without
putting a side effect into the condition?
> Many compilers will warn about unclear code for method 2.
> (You shut them up by adding superfluous parentheses, but
> the fact you have to do this shows that the code has
> undesireable properties).
I think you are conflating a couple of different things there. The
compiler warnings I've seen are about whether = is intended rather than
and complaint about action in the condition. If C had no possible =/==
confusion, I don't think any compiler would have a reason to complain.
Have you seen other, more general, warnings?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-15 03:31 -0800 |
| Message-ID | <37e325fb-4aa8-4c84-9bcd-c1aa790fadc7@googlegroups.com> |
| In reply to | #99475 |
On Thursday, December 15, 2016 at 10:44:32 AM UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > while(line = getline(fp))
> > priocessline(line);
>
> Anyway, how do you propose to write the endoffile function without
> putting a side effect into the condition?
>
You can't easily support all stream types, which is why C's feof()
doesn't work as everyone new to C thinks it should.
> > Many compilers will warn about unclear code for method 2.
> > (You shut them up by adding superfluous parentheses, but
> > the fact you have to do this shows that the code has
> > undesireable properties).
>
> I think you are conflating a couple of different things there. The
> compiler warnings I've seen are about whether = is intended rather than
> and complaint about action in the condition. If C had no possible =/==
> confusion, I don't think any compiler would have a reason to complain.
> Have you seen other, more general, warnings?
>
Essentially the idea is the predicate function. C++ (and C with qsort)
make it difficult for a predicate to have side effects by demanding
that all the arguments are const.
If we rewrite
while(fp->pos < fp->N)
line = getline(fp);
it looks more like simple iteration. However of course that requires
that N be available.
(Ben knows this, but the C++ convention is to use the '<' operator
for built in algorithms. When overload it is usually const-qualified.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-16 01:11 +0000 |
| Message-ID | <87zijw3cfs.fsf@bsb.me.uk> |
| In reply to | #99480 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, December 15, 2016 at 10:44:32 AM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > while(line = getline(fp))
>> > priocessline(line);
>>
>> Anyway, how do you propose to write the endoffile function without
>> putting a side effect into the condition?
>>
> You can't easily support all stream types, which is why C's feof()
> doesn't work as everyone new to C thinks it should.
Here is the code you cut. My question makes no sense without it.
|| while(!endoffile(fp))
|| {
|| line = getline(fp);
|| processline(line);
|| }
You seem to be saying that your endoffile(fp) can not be written in C,
and even if it built in to the language (or supplied in some other way)
it won't work on all streams. I agree on both counts but I don't see
why you want to take C back to the 70s.
>> > Many compilers will warn about unclear code for method 2.
>> > (You shut them up by adding superfluous parentheses, but
>> > the fact you have to do this shows that the code has
>> > undesireable properties).
>>
>> I think you are conflating a couple of different things there. The
>> compiler warnings I've seen are about whether = is intended rather than
>> and complaint about action in the condition. If C had no possible =/==
>> confusion, I don't think any compiler would have a reason to complain.
>> Have you seen other, more general, warnings?
>>
> Essentially the idea is the predicate function. C++ (and C with qsort)
> make it difficult for a predicate to have side effects by demanding
> that all the arguments are const.
>
> If we rewrite
>
> while(fp->pos < fp->N)
> line = getline(fp);
>
> it looks more like simple iteration. However of course that requires
> that N be available.
>
> (Ben knows this, but the C++ convention is to use the '<' operator
> for built in algorithms. When overload it is usually const-qualified.)
I hope some people can follow this as I hope some people understood my
points. I think that's the best we can hope for at the moment.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-16 06:16 -0800 |
| Message-ID | <e67e45a0-8f62-4d17-9719-f3e6275a089c@googlegroups.com> |
| In reply to | #99592 |
On Friday, December 16, 2016 at 1:11:42 AM UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > On Thursday, December 15, 2016 at 10:44:32 AM UTC, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >>
> >> > while(line = getline(fp))
> >> > priocessline(line);
> >>
> >> Anyway, how do you propose to write the endoffile function without
> >> putting a side effect into the condition?
> >>
> > You can't easily support all stream types, which is why C's feof()
> > doesn't work as everyone new to C thinks it should.
>
> Here is the code you cut. My question makes no sense without it.
>
> || while(!endoffile(fp))
> || {
> || line = getline(fp);
> || processline(line);
> || }
>
> You seem to be saying that your endoffile(fp) can not be written in C,
> and even if it built in to the language (or supplied in some other way)
> it won't work on all streams. I agree on both counts but I don't see
> why you want to take C back to the 70s.
>
Really we want this (pseudo-code)
nextline:
line = getline();
if(line == endofdata)
goto endofdata;
processline(line);
goto nextline;
endofdata:
but it's not structured.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-16 17:24 +0000 |
| Message-ID | <878trf23ef.fsf@bsb.me.uk> |
| In reply to | #99653 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, December 16, 2016 at 1:11:42 AM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > On Thursday, December 15, 2016 at 10:44:32 AM UTC, Ben Bacarisse wrote:
>> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> >>
>> >> > while(line = getline(fp))
>> >> > priocessline(line);
>> >>
>> >> Anyway, how do you propose to write the endoffile function without
>> >> putting a side effect into the condition?
>> >>
>> > You can't easily support all stream types, which is why C's feof()
>> > doesn't work as everyone new to C thinks it should.
>>
>> Here is the code you cut. My question makes no sense without it.
>>
>> || while(!endoffile(fp))
>> || {
>> || line = getline(fp);
>> || processline(line);
>> || }
>>
>> You seem to be saying that your endoffile(fp) can not be written in C,
>> and even if it built in to the language (or supplied in some other way)
>> it won't work on all streams. I agree on both counts but I don't see
>> why you want to take C back to the 70s.
>>
> Really we want this (pseudo-code)
>
> nextline:
> line = getline();
> if(line == endofdata)
> goto endofdata;
> processline(line);
> goto nextline;
> endofdata:
>
> but it's not structured.
I think we agree about some of this though for some reason you cut the
goto-less pseudo-code version of this that I posted. What didn't you
like about it? I much prefer it to using goto.
And you also cut the C version. What's unstructured about
while (
line = getline(),
line != endofdata ) {
processline(line);
}
? (I know the term "structured" is not exactly specified.)
I used a comma, by the way, because it matches the sequencing of your
pseudo code more closely. You would, in practice, simplify the
expression in C to while ((line = getline()) != endofdata) but the
pattern
while (
code before,
loop condition )
body;
is the more general one.
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web