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 213 — 23 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 raltbos@xs4all.nl (Richard Bos) - 2016-12-27 20:19 +0000
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 Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 13:27 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:41 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-29 13:57 -0800
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2016-12-29 22:55 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-29 15:34 -0800
Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 02:51 -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 Les Cargill <lcargill99@comcast.com> - 2016-12-26 14:30 -0600
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 03:48 +0000
Re: while loop vs do while loop reading from the file issue Les Cargill <lcargill99@comcast.com> - 2016-12-28 07:15 -0600
Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 01:05 -0800
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-29 13:25 -0800
Re: while loop vs do while loop reading from the file issue Ian Collins <ian-news@hotmail.com> - 2016-12-30 10:48 +1300
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 16:46 -0800
Re: while loop vs do while loop reading from the file issue Ian Collins <ian-news@hotmail.com> - 2016-12-30 13:51 +1300
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 17:22 -0800
Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 02:45 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-30 01:01 +0000
Re: while loop vs do while loop reading from the file issue Ian Collins <ian-news@hotmail.com> - 2016-12-30 14:04 +1300
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 17:23 -0800
Re: while loop vs do while loop reading from the file issue asetofsymbols@gmail.com - 2016-12-30 00:56 -0800
Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 02:41 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 09:59 -0800
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2017-01-13 18:48 +0000
Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 12:08 -0800
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2017-01-15 23:09 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2017-01-15 23:18 +0000
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2017-01-15 23:37 +0000
Re: while loop vs do while loop reading from the file issue raltbos@xs4all.nl (Richard Bos) - 2017-01-18 11:32 +0000
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2017-01-18 21:25 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2017-01-13 11:54 -0800
Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 11:58 -0800
Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 12:05 -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 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| 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]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-16 09:53 -0800 |
| Message-ID | <a724d7fb-b68b-444f-866d-e9b0d9d4cf8e@googlegroups.com> |
| In reply to | #99666 |
On Friday, December 16, 2016 at 5:24:32 PM UTC, Ben Bacarisse wrote:
> 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.
>
That pattern isn't structured.
Structured program are only allowed square blocks which do things
and diamond blocks which take binary branches. (And recursion,
but that's not an issue here). And they must be themselves
square blocks. (You must be able to take a structured program
and insert it as a square block in a greater program).
I don't think we can draw it thusly
start
|
|-Illegal join here-------|
| |
|-------------| |
| code before | |
|-------------| |
| |
/ \ |
/ \ |
/ \ |
/ \ |------| |
/condition\------------| body |---
\ ? / |------|
\ /
\ /
\ /
\ /
|
stop
I think that's right. I will admit you've got me puzzled.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-16 20:38 +0000 |
| Message-ID | <87wpezzk1o.fsf@bsb.me.uk> |
| In reply to | #99672 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, December 16, 2016 at 5:24:32 PM UTC, Ben Bacarisse wrote:
>> 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.
>>
> That pattern isn't structured.
>
> Structured program are only allowed square blocks which do things
> and diamond blocks which take binary branches.
Where does that definition come from? It just sounds like a flow chart
to me, which was how programs were often sketched before structured
programming cam along.
> I don't think we can draw it thusly
<snip flow chart>
Given S a statement, C an expression suitable for a truth condition, and
E an arbitrary expression which we will turn into an expression
statement by adding a semi-colon, is
E;
while (C) { S; E; }
a structured program? What diagram does it correspond to? In what way
is that diagram different to the diagram you would have to draw for
while (E, C) S;
?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-12-16 21:13 +0000 |
| Message-ID | <8737hnfuha.fsf@gmail.com> |
| In reply to | #99685 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> That pattern isn't structured. >> >> Structured program are only allowed square blocks which do things >> and diamond blocks which take binary branches. > > Where does that definition come from? It just sounds like a flow chart > to me, which was how programs were often sketched before structured > programming cam along. Where do you suppose it came from? Do you think a) Malcolm looked upwhat "structured programme" meant and understood it or b) just made up his own definition based on something he once heard?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-16 21:50 +0000 |
| Message-ID | <87r357zgq3.fsf@bsb.me.uk> |
| In reply to | #99685 |
Just a clarification...
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>> On Friday, December 16, 2016 at 5:24:32 PM UTC, Ben Bacarisse wrote:
>>> 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.
>>>
>> That pattern isn't structured.
>>
>> Structured program are only allowed square blocks which do things
>> and diamond blocks which take binary branches.
>
> Where does that definition come from? It just sounds like a flow chart
> to me, which was how programs were often sketched before structured
> programming cam along.
>
>> I don't think we can draw it thusly
> <snip flow chart>
>
> Given S a statement, C an expression suitable for a truth condition, and
> E an arbitrary expression which we will turn into an expression
> statement by adding a semi-colon, is
>
> E;
> while (C) { S; E; }
>
> a structured program? What diagram does it correspond to? In what way
> is that diagram different to the diagram you would have to draw for
>
> while (E, C) S;
>
> ?
That's not a fruitful question, especially considering your last remark
that I did not properly register:
> I will admit you've got me puzzled.
I expected you to say (or for me to out out) that both meet your rather
sketchy definition but it's now clear to me that you know that more is
needed. So a better questions is what is it about the differences that
is so important to your notion of structured? I.e. why is one graph of
boxes and lines OK and another not?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-16 14:19 -0800 |
| Message-ID | <4fd933b6-d713-43b4-9d3c-06657a4bcb91@googlegroups.com> |
| In reply to | #99706 |
On Friday, December 16, 2016 at 9:50:21 PM UTC, Ben Bacarisse wrote: > Just a clarification... > > That's not a fruitful question, especially considering your last remark > that I did not properly register: > > > I will admit you've got me puzzled. > > I expected you to say (or for me to out out) that both meet your rather > sketchy definition but it's now clear to me that you know that more is > needed. So a better questions is what is it about the differences that > is so important to your notion of structured? I.e. why is one graph of > boxes and lines OK and another not? > Blocks have to have one point of entry and of exit, and you can't get round that rule by splitting a block and jumping into or out of the connector line you have created. OTOH iteration is an allowed operation, and of course that means entering the block either from the first pass or from a subsequent one. So there must be a loop and hence a merge structure. Now I had thought that the C while was robust to creating non- structured programs. But I think now it is not. But it's not quite clear to me which rule you are breaking and why.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-16 15:03 -0800 |
| Message-ID | <ec373472-53cd-42e0-8c52-858178796bba@googlegroups.com> |
| In reply to | #99711 |
On Friday, December 16, 2016 at 4:19:41 PM UTC-6, Malcolm McLean wrote:
> Now I had thought that the C while was robust to creating non-
> structured programs. But I think now it is not. But it's not quite
> clear to me which rule you are breaking and why.
Conditional tests aren't allowed to have side-effects in the traditional
pattern, but the remedy is to extend the rules of structured programming
to allow for "loop-and-a-half" constructs. While some people might prefer:
while(get_data(&my_data))
{
process_data(my_data);
}
to
for(;;) // Or while(1)..., or do {...} while(1), etc.
{
if (!get_data(&my_data))
break;
process_data(my_data);
}
the former pattern can make it awkward to add logic around the data-fetch
code. C may not have any particularly idiomatic way of representing a
loop-and-a-half construct in cases where the code before the test won't
fit in an expression, but the second construct above is still reasonably
clean.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-29 13:27 -0800 |
| Message-ID | <kfn60m2whn7.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #99714 |
supercat@casperkitty.com writes: > On Friday, December 16, 2016 at 4:19:41 PM UTC-6, Malcolm McLean wrote: >> Now I had thought that the C while was robust to creating non- >> structured programs. But I think now it is not. But it's not quite >> clear to me which rule you are breaking and why. > > Conditional tests aren't allowed to have side-effects in the traditional > pattern, [...] Wrong.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-29 13:41 -0800 |
| Message-ID | <91224c12-a127-4a5d-b64a-67a2e0a6565e@googlegroups.com> |
| In reply to | #100492 |
On Thursday, December 29, 2016 at 9:27:16 PM UTC, Tim Rentsch wrote: > supercat@casperkitty.com writes: > > > On Friday, December 16, 2016 at 4:19:41 PM UTC-6, Malcolm McLean wrote: > >> Now I had thought that the C while was robust to creating non- > >> structured programs. But I think now it is not. But it's not quite > >> clear to me which rule you are breaking and why. > > > > Conditional tests aren't allowed to have side-effects in the traditional > > pattern, [...] > > Wrong. > I don't think so. We have boxes which do something, and control always enters at the top and comes out at the bottom, and in the box we have a bit of text saying what the box does. Now of course we can expand most boxes, unless that box is a single machine instruction. Then we also have diamonds. Control does not always enter from the top, it can also enter from the spare vertex, and there are two (always exactly two) control paths out. On the diamond we write the conditions of the test. But I'm not sure we can expand the diamonds, I think that is disallowed. Certainly, if we expand the diamonds, we've lost a primary property, because whilst the block has one point of entry and of exit, a diamond has two points of exit and possibly two points of entry. So a diamond is not a sub-program.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-29 13:57 -0800 |
| Message-ID | <lny3yyz9cq.fsf@kst-u.example.com> |
| In reply to | #100503 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, December 29, 2016 at 9:27:16 PM UTC, Tim Rentsch wrote:
>> supercat@casperkitty.com writes:
>> > On Friday, December 16, 2016 at 4:19:41 PM UTC-6, Malcolm McLean wrote:
>> >> Now I had thought that the C while was robust to creating non-
>> >> structured programs. But I think now it is not. But it's not quite
>> >> clear to me which rule you are breaking and why.
>> >
>> > Conditional tests aren't allowed to have side-effects in the traditional
>> > pattern, [...]
>>
>> Wrong.
>>
> I don't think so. We have boxes which do something, and control always
> enters at the top and comes out at the bottom, and in the box we have
> a bit of text saying what the box does. Now of course we can expand
> most boxes, unless that box is a single machine instruction. Then
> we also have diamonds. Control does not always enter from the top,
> it can also enter from the spare vertex, and there are two (always
> exactly two) control paths out. On the diamond we write the conditions
> of the test. But I'm not sure we can expand the diamonds, I think that
> is disallowed.
Disallowed by what or whom?
> Certainly, if we expand the diamonds, we've lost a
> primary property, because whilst the block has one point of entry
> and of exit, a diamond has two points of exit and possibly two points
> of entry. So a diamond is not a sub-program.
You are describing what *you* think of as structured programming, but
you're providing no basis for your claims about it.
Tim cited a source, Dijkstra's "Notes on Structured Programming".
What's your source? If you have none, perhaps you could call it
Malcolm-structured programming to avoid confusion.
--
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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-12-29 22:55 +0000 |
| Message-ID | <8737h69wg6.fsf@gmail.com> |
| In reply to | #100517 |
Keith Thompson <kst-u@mib.org> writes: > You are describing what *you* think of as structured programming, but > you're providing no basis for your claims about it. > > Tim cited a source, Dijkstra's "Notes on Structured Programming". > What's your source? If you have none, perhaps you could call it > Malcolm-structured programming to avoid confusion. Remember when this used to be a C language newsgroup? Good times. Do Not Feed The .... Whatever the Hell Malcolm Is.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-29 15:34 -0800 |
| Message-ID | <lnlguyz4v5.fsf@kst-u.example.com> |
| In reply to | #100551 |
Gareth Owen <gwowen@gmail.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> You are describing what *you* think of as structured programming, but
>> you're providing no basis for your claims about it.
>>
>> Tim cited a source, Dijkstra's "Notes on Structured Programming".
>> What's your source? If you have none, perhaps you could call it
>> Malcolm-structured programming to avoid confusion.
>
> Remember when this used to be a C language newsgroup?
>
> Good times.
>
> Do Not Feed The .... Whatever the Hell Malcolm Is.
Point taken -- but in this case Malcolm is actually talking about C
programming, such as the common C idiom of conditions with side effects.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-13 02:51 -0800 |
| Message-ID | <kfn7f5zqll0.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100503 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Thursday, December 29, 2016 at 9:27:16 PM UTC, Tim Rentsch wrote: >> supercat@casperkitty.com writes: >> >>> On Friday, December 16, 2016 at 4:19:41 PM UTC-6, Malcolm McLean wrote: >>>> Now I had thought that the C while was robust to creating non- >>>> structured programs. But I think now it is not. But it's not quite >>>> clear to me which rule you are breaking and why. >>> >>> Conditional tests aren't allowed to have side-effects in the >>> traditional pattern, [...] >> >> Wrong. > > I don't think so. We have boxes which do something, and control > always enters at the top and comes out at the bottom, [...] Yes, I know you have your own ideas about what certain words mean. My response is in reference to "the traditional pattern", which for structured programming may reasonably be taken as Dijkstra's monograph on the subject. That discussion admits the possibility that tests in if's and while's might have side effects.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-17 02:20 +0000 |
| Message-ID | <87fulnz479.fsf@bsb.me.uk> |
| In reply to | #99711 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, December 16, 2016 at 9:50:21 PM UTC, Ben Bacarisse wrote: >> Just a clarification... >> >> That's not a fruitful question, especially considering your last remark >> that I did not properly register: >> >> > I will admit you've got me puzzled. >> >> I expected you to say (or for me to out out) that both meet your rather >> sketchy definition but it's now clear to me that you know that more is >> needed. So a better questions is what is it about the differences that >> is so important to your notion of structured? I.e. why is one graph of >> boxes and lines OK and another not? >> > Blocks have to have one point of entry and of exit, and you can't > get round that rule by splitting a block and jumping into or out > of the connector line you have created. The code I showed: while (E, C) S; is a block with has one entry and one exit. In the paper that spawned the term, Dijkstra draws some of the block diagrams constructed from primitives. I can't be bothered with ASCII art so here they are drawn properly: http://www.bsb.me.uk/tmp/sp1.pdf Five of those six are straight from the paper using the same symbols and shapes. The sixth is the construct above showing its single entry and single exit. What is so beyond the pale about it? (To keep the form used in the paper, E is called S1, S is called S2 and C is the ? box.) There /is/ a problem with it, but it's that C is not flexible enough. You should be able to recursively replace the boxes in these diagrams with the dotted blocks -- that's the whole point of the single entry, single exit rule -- but in C you can't put arbitrary code where I put E in the example (S1 in the diagram). (Dijkstra should have used diamonds for the ? boxes because they can't be substituted in this way and that would make the distinction clearer.) > OTOH iteration is an allowed operation, and of course that means > entering the block either from the first pass or from a subsequent > one. So there must be a loop and hence a merge structure. > > Now I had thought that the C while was robust to creating non- > structured programs. But I think now it is not. But it's not quite > clear to me which rule you are breaking and why. You'd have to define some rules first. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-17 02:21 -0800 |
| Message-ID | <38f12ceb-ac88-4f03-86cf-b003dce3a479@googlegroups.com> |
| In reply to | #99719 |
On Saturday, December 17, 2016 at 2:20:50 AM UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> The code I showed:
>
> while (E, C) S;
>
> is a block with has one entry and one exit.
>
Yes, it holds to that rule.
>
> In the paper that spawned the term, Dijkstra draws some of the block
> diagrams constructed from primitives. I can't be bothered with ASCII
> art so here they are drawn properly:
>
> http://www.bsb.me.uk/tmp/sp1.pdf
>
> Five of those six are straight from the paper using the same symbols and
> shapes. The sixth is the construct above showing its single entry and
> single exit. What is so beyond the pale about it? (To keep the form
> used in the paper, E is called S1, S is called S2 and C is the ? box.)
>
> There /is/ a problem with it, but it's that C is not flexible enough.
> You should be able to recursively replace the boxes in these diagrams
> with the dotted blocks -- that's the whole point of the single entry,
> single exit rule -- but in C you can't put arbitrary code where I put E
> in the example (S1 in the diagram).
>
> (Dijkstra should have used diamonds for the ? boxes because they can't
> be substituted in this way and that would make the distinction clearer.)
>
> > OTOH iteration is an allowed operation, and of course that means
> > entering the block either from the first pass or from a subsequent
> > one. So there must be a loop and hence a merge structure.
> >
> > Now I had thought that the C while was robust to creating non-
> > structured programs. But I think now it is not. But it's not quite
> > clear to me which rule you are breaking and why.
>
> You'd have to define some rules first.
>
If you read the paper, Djikstra says
We have now seen three types of decomposition; we could
call them "concatenation", "selection" and "repetition"
respectively. The first two are understood by enumerative
reasoning, the last one by mathematical induction
.
The programs that can be written using the selection clauses
and the repetition clauses as only the means for sequencing
control, permit straightforward translation into a programming
language that is identical but for the fact that sequencing
control has to be expressed by jumps to labelled points.
The converse is not true. Alternatively: restricting ourselves
to the three mentioned types of decomposition leads to flowcharts
of a restricted topology compared with the flowcharts one can
make when arrows can be drawn from any block leading into any other.
Compared with that greater freedom, to restrict oneself to the
clauses presents itself as a sequencing discipline.
Why do I propose to adhere to this sequencing discipline ?
The justification for this decision can be presented in
many ways and let me try a number of them in the hope that
at least one of them will appeal to my readers.
So that's the answer. Djikstra's five primitives are meant to be
exhaustive. Now we need to understand on a deeper level why your
primitive is disallowed. Which in a sense I've done by using if ..
goto notation. But we need more than that.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-17 12:14 +0000 |
| Message-ID | <87wpeyycq7.fsf@bsb.me.uk> |
| In reply to | #99730 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, December 17, 2016 at 2:20:50 AM UTC, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> The code I showed: >> >> while (E, C) S; >> >> is a block with has one entry and one exit. >> > Yes, it holds to that rule. >> >> In the paper that spawned the term, Dijkstra draws some of the block >> diagrams constructed from primitives. I can't be bothered with ASCII >> art so here they are drawn properly: >> >> http://www.bsb.me.uk/tmp/sp1.pdf >> >> Five of those six are straight from the paper using the same symbols and >> shapes. The sixth is the construct above showing its single entry and >> single exit. What is so beyond the pale about it? (To keep the form >> used in the paper, E is called S1, S is called S2 and C is the ? box.) >> >> There /is/ a problem with it, but it's that C is not flexible enough. >> You should be able to recursively replace the boxes in these diagrams >> with the dotted blocks -- that's the whole point of the single entry, >> single exit rule -- but in C you can't put arbitrary code where I put E >> in the example (S1 in the diagram). >> >> (Dijkstra should have used diamonds for the ? boxes because they can't >> be substituted in this way and that would make the distinction clearer.) >> >> > OTOH iteration is an allowed operation, and of course that means >> > entering the block either from the first pass or from a subsequent >> > one. So there must be a loop and hence a merge structure. >> > >> > Now I had thought that the C while was robust to creating non- >> > structured programs. But I think now it is not. But it's not quite >> > clear to me which rule you are breaking and why. >> >> You'd have to define some rules first. >> > > If you read the paper, Djikstra says > > We have now seen three types of decomposition; we could > call them "concatenation", "selection" and "repetition" > respectively. The first two are understood by enumerative > reasoning, the last one by mathematical induction > . > The programs that can be written using the selection clauses > and the repetition clauses as only the means for sequencing > control, permit straightforward translation into a programming > language that is identical but for the fact that sequencing > control has to be expressed by jumps to labelled points. > > The converse is not true. Alternatively: restricting ourselves > to the three mentioned types of decomposition leads to flowcharts > of a restricted topology compared with the flowcharts one can > make when arrows can be drawn from any block leading into any other. > Compared with that greater freedom, to restrict oneself to the > clauses presents itself as a sequencing discipline. > > Why do I propose to adhere to this sequencing discipline ? > The justification for this decision can be presented in > many ways and let me try a number of them in the hope that > at least one of them will appeal to my readers. > > So that's the answer. Djikstra's five primitives are meant to be > exhaustive. But only two would be exhaustive[1]. In fact he gives six because he includes a multi-way selection. He's quite happy not to have a minimal set. Repetition is clearly important, but why two forms? One can be built from the other by either duplicating the test code or duplicating the statement code, just as the last form (the one in question) can be built by from a normal loop by duplicating some code. (Here, "duplicating" is not literal duplication -- you'd put it in a procedure if it were at all complex.) But notice how both of Dijkstra's loops are simply special cases of the last -- make S1 null to get a while loop and S2 null to get a do-while. It's just a combination both. If you want a minimal set of primitives, you could do worse than choose selection and the contended loop form. > Now we need to understand on a deeper level why your primitive is > disallowed. It's not disallowed, it's just not chosen by Dijkstra (or Hoare). And the reason is very simple -- its proof rule will be more complex than that for either of the simpler loops. Both Dijkstra and Hoare are primarily concerned with reasoning, formally, about code, so they want to use a set of primitives with the simplest possible proof rules, rather than just smallest number of primitives. They don't mind having an extra proof rule because it's simple. If you are not concerned with formal proofs, I don't see why you would not prefer to have only two primitives: choice and "my" repetition, and if you are concerned with formal proofs you wouldn't use C. Mind you, if you want to use the more general loop pattern a lot, you wouldn't opt for C either since C supports only some cases of it. <snip> [1] Formally, you don't even need two since a loop can be re-purposed to make a simple choice. But that's not the point here. We're talking about small (rather then formally minimal) sets of structuring primitives that are, none the less, practical to use. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-17 04:56 -0800 |
| Message-ID | <0c7b7ce2-1440-49bc-9061-a19363458a67@googlegroups.com> |
| In reply to | #99732 |
On Saturday, December 17, 2016 at 12:14:19 PM UTC, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > But notice how both of Dijkstra's loops are simply special cases of the > last -- make S1 null to get a while loop and S2 null to get a do-while. > It's just a combination both. If you want a minimal set of primitives, > you could do worse than choose selection and the contended loop form. > I think that's the mistake. Null is not a generalisable case with these diagrams. We can jump into or out of a null block happily enough. It's blocks which do something which create problems for us. And you can't have two branches from two blocks going into the same block. Only branches from diamonds to block or blocks to diamonds. (I'm still not sure about this. "Djikstra seems to say so and he must be right because he's Djikstra" is the lowest level of understanding).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-17 19:28 +0000 |
| Message-ID | <87h962xsmq.fsf@bsb.me.uk> |
| In reply to | #99733 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, December 17, 2016 at 12:14:19 PM UTC, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> > >> But notice how both of Dijkstra's loops are simply special cases of the >> last -- make S1 null to get a while loop and S2 null to get a do-while. >> It's just a combination both. If you want a minimal set of primitives, >> you could do worse than choose selection and the contended loop form. >> > I think that's the mistake. > Null is not a generalisable case with these diagrams. We can jump > into or out of a null block happily enough. It's blocks which do > something which create problems for us. I understand the words on their own, but that's about it. Structured programming has no jumps except within a fixed small set of primitives that describe how basic actions and, recursively, the diagrams themselves can be combined -- sequencing, choice and iteration. There is no prohibition on having a basic action which is "skip" or ";" -- the "if" diagram is just the "if/else" diagram with a "skip" action which is best drawn as a line. > And you can't have two branches from two blocks going into the same > block. Only branches from diamonds to block or blocks to diamonds. That would rule out having anything after an if/else. Or it would mean I don't follow. The latter is much more likely. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-12-17 22:51 +0000 |
| Message-ID | <slrn3vfso5bgcn.621.ike@iceland.freeshell.org> |
| In reply to | #99733 |
On 2016-12-17, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Saturday, December 17, 2016 at 12:14:19 PM UTC, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> > >> But notice how both of Dijkstra's loops are simply special cases of the >> last -- make S1 null to get a while loop and S2 null to get a do-while. >> It's just a combination both. If you want a minimal set of primitives, >> you could do worse than choose selection and the contended loop form. >> > I think that's the mistake. > Null is not a generalisable case with these diagrams. We can jump > into or out of a null block happily enough. It's blocks which do > something which create problems for us. > > And you can't have two branches from two blocks going into the same > block. Only branches from diamonds to block or blocks to diamonds. > > (I'm still not sure about this. "Djikstra seems to say so and he > must be right because he's Djikstra" is the lowest level of > understanding). It's Dijkstra, not Djikstra.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-12-17 11:45 -0600 |
| Message-ID | <o33th0$io9$1@dont-email.me> |
| In reply to | #99730 |
Malcolm McLean wrote: > On Saturday, December 17, 2016 at 2:20:50 AM UTC, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> The code I showed: >> >> while (E, C) S; >> >> is a block with has one entry and one exit. >> > Yes, it holds to that rule. >> >> In the paper that spawned the term, Dijkstra draws some of the block >> diagrams constructed from primitives. I can't be bothered with ASCII >> art so here they are drawn properly: >> >> http://www.bsb.me.uk/tmp/sp1.pdf >> >> Five of those six are straight from the paper using the same symbols and >> shapes. The sixth is the construct above showing its single entry and >> single exit. What is so beyond the pale about it? (To keep the form >> used in the paper, E is called S1, S is called S2 and C is the ? box.) >> >> There /is/ a problem with it, but it's that C is not flexible enough. >> You should be able to recursively replace the boxes in these diagrams >> with the dotted blocks -- that's the whole point of the single entry, >> single exit rule -- but in C you can't put arbitrary code where I put E >> in the example (S1 in the diagram). >> >> (Dijkstra should have used diamonds for the ? boxes because they can't >> be substituted in this way and that would make the distinction clearer.) >> >>> OTOH iteration is an allowed operation, and of course that means >>> entering the block either from the first pass or from a subsequent >>> one. So there must be a loop and hence a merge structure. >>> >>> Now I had thought that the C while was robust to creating non- >>> structured programs. But I think now it is not. But it's not quite >>> clear to me which rule you are breaking and why. >> >> You'd have to define some rules first. >> > > If you read the paper, Djikstra says > > We have now seen three types of decomposition; we could > call them "concatenation", "selection" and "repetition" > respectively. The first two are understood by enumerative > reasoning, the last one by mathematical induction > . > The programs that can be written using the selection clauses > and the repetition clauses as only the means for sequencing > control, permit straightforward translation into a programming > language that is identical but for the fact that sequencing > control has to be expressed by jumps to labelled points. > > The converse is not true. Alternatively: restricting ourselves > to the three mentioned types of decomposition leads to flowcharts > of a restricted topology compared with the flowcharts one can > make when arrows can be drawn from any block leading into any other. > Compared with that greater freedom, to restrict oneself to the > clauses presents itself as a sequencing discipline. > > Why do I propose to adhere to this sequencing discipline ? > The justification for this decision can be presented in > many ways and let me try a number of them in the hope that > at least one of them will appeal to my readers. > > So that's the answer. Djikstra's five primitives are meant to be > exhaustive. Now we need to understand on a deeper level why your > primitive is disallowed. Which in a sense I've done by using if .. > goto notation. But we need more than that. > > They aren't just *meant* to be exhaustive; there's a riff from "Godel, Escher, Bach" where he describes the languages Bloop and Floop ( bounded vs. free loops ) and indicates that there is a proof that "there is no higher level language than Floop" ). I take that to mean that it is exhaustive and this has been proven ( I have never taken the time to lay hands on that proof, though ). Of course the control structure that best-fits correctness thinking is the Finite State Machine, which is something you can build out of the mentioned primitives. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web