Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #107910 > unrolled thread
| Started by | Peabody <waybackNO584SPAM44@yahoo.com> |
|---|---|
| First post | 2017-04-08 22:59 -0500 |
| Last post | 2017-04-26 11:09 -0700 |
| Articles | 20 on this page of 187 — 30 participants |
Back to article view | Back to comp.lang.c
And they say C is obscure Peabody <waybackNO584SPAM44@yahoo.com> - 2017-04-08 22:59 -0500
Re: And they say C is obscure Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-04-08 22:17 -0600
Re: And they say C is obscure Peabody <waybackNO584SPAM44@yahoo.com> - 2017-04-09 07:42 -0500
Re: And they say C is obscure Barry Schwarz <schwarzb@dqel.com> - 2017-04-09 07:46 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-04-09 16:47 +0200
Re: And they say C is obscure James Kuyper <jameskuyper@verizon.net> - 2017-04-09 14:42 -0400
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-09 13:25 -0700
Re: And they say C is obscure James Kuyper <jameskuyper@verizon.net> - 2017-04-09 22:56 -0400
Re: And they say C is obscure Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-04-09 15:18 -0600
Re: And they say C is obscure Ken Brody <kenbrody@spamcop.net> - 2017-04-10 12:57 -0400
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-10 14:46 +0000
Re: And they say C is obscure luser droog <luser.droog@gmail.com> - 2017-04-09 07:26 -0700
Re: And they say C is obscure James Kuyper <jameskuyper@verizon.net> - 2017-04-09 14:18 -0400
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-09 20:53 +0100
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-09 13:52 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-04-14 11:48 +0000
Re: And they say C is obscure Ken Brody <kenbrody@spamcop.net> - 2017-04-14 13:36 -0400
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-04-20 13:24 +0000
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-20 08:05 -0700
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-20 15:32 +0000
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-20 09:48 -0700
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-20 18:00 +0000
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-20 11:34 -0700
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-20 18:41 +0000
Re: And they say C is obscure Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-04-09 13:18 -0700
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-09 14:03 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-09 22:56 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-04-10 09:12 +0200
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-10 08:22 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-10 18:28 +0100
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-10 17:49 +0000
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-10 11:50 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-10 20:33 +0100
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-10 13:06 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-10 21:48 +0100
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-10 22:15 +0100
Re: And they say C is obscure Michael Barry <barrym95838@yahoo.com> - 2017-04-10 18:46 -0700
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-10 21:46 +0000
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-10 23:09 +0100
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-11 12:40 +0000
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-11 14:15 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 10:13 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-26 10:38 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-10 15:23 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-04-14 11:51 +0000
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-14 13:14 +0100
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-14 10:42 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-14 19:04 +0100
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-14 21:43 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 11:02 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-26 19:05 +0100
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-26 12:02 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-26 21:55 +0100
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-27 00:15 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:23 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-14 18:12 +0100
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-14 18:37 +0100
Re: And they say C is obscure GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-11 00:03 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-04-10 14:10 -0700
Re: And they say C is obscure mark.bluemel@gmail.com - 2017-04-11 08:41 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-11 08:58 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-04-11 09:06 -0700
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-11 16:46 +0000
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-11 19:02 +0100
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-04-14 11:59 +0000
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 10:59 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-27 21:40 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 05:17 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 12:50 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 01:20 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-05 12:37 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-06 00:16 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-06 11:49 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-06 13:16 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-06 14:10 -0700
Re: And they say C is obscure Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-05-06 20:23 -0600
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-06 21:51 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-07 05:04 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-07 05:09 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-07 05:18 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-07 05:54 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-05-07 13:48 +0100
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-07 06:13 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-07 15:10 +0200
Re: And they say C is obscure Manfred <noname@invalid.add> - 2017-05-07 16:47 +0200
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-07 21:08 +0200
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-05-07 21:54 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-08 00:59 +0200
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-07 16:59 -0700
Re: And they say C is obscure Robert Wessel <robertwessel2@yahoo.com> - 2017-05-07 22:28 -0500
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-08 10:16 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-08 02:41 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-08 07:36 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-09 10:06 +0000
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-09 14:03 +0200
Re: And they say C is obscure Manfred <noname@invalid.add> - 2017-05-09 19:41 +0200
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-09 21:35 +0200
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-09 20:25 +0000
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-10 14:48 +0200
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-10 14:23 +0100
Re: And they say C is obscure Manfred <noname@invalid.add> - 2017-05-10 21:31 +0200
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-05-10 12:45 -0700
Re: And they say C is obscure "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-10 16:49 -0400
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-07 08:56 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-08 09:54 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-08 17:32 -0700
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-05-08 18:26 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-09 02:28 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-09 10:15 +0000
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-09 05:53 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-05-09 14:15 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-09 06:55 -0700
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-09 14:43 +0100
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-09 23:07 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-10 15:32 +0200
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-10 11:39 +0000
Re: And they say C is obscure mark.bluemel@gmail.com - 2017-05-09 06:21 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-11 03:00 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-05-09 18:20 +0100
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-05-10 10:06 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-10 11:11 -0700
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-10 12:45 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-10 05:33 -0700
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-10 13:41 +0100
Re: And they say C is obscure Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-10 09:32 -0400
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-10 14:51 +0100
Re: And they say C is obscure Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-10 10:54 -0400
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-10 17:36 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-10 09:28 -0700
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-10 19:12 +0100
Re: And they say C is obscure me <crisdunbar@gmail.com> - 2017-05-10 11:53 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-10 22:19 +0200
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-05-11 07:36 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-11 00:39 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-11 13:30 +0200
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-11 13:17 +0100
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-11 13:37 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-12 10:39 +0200
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-13 09:34 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-13 09:48 -0700
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-13 19:48 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-13 14:01 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-13 15:23 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-14 03:14 -0700
[OT] Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-14 12:18 +0100
Re: [OT] Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-14 13:28 +0100
Re: [OT] Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-14 15:56 +0200
Re: [OT] Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-14 16:56 +0100
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-14 02:03 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-14 03:08 -0700
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-14 13:44 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-14 16:13 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-14 08:04 -0700
Re: And they say C is obscure luser droog <luser.droog@gmail.com> - 2017-05-14 08:52 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-14 09:16 -0700
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-14 17:48 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 14:11 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-14 22:57 +0200
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-05-14 14:10 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-14 15:51 +0200
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 14:04 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-11 07:45 -0700
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-11 16:45 +0100
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-05-11 19:58 +0100
Re: And they say C is obscure Ike Naar <ike@iceland.freeshell.org> - 2017-05-11 22:15 +0000
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-11 23:24 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-12 10:50 +0200
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-12 09:57 +0100
Re: And they say C is obscure Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-10 16:31 -0400
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-10 07:50 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-05-10 09:00 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-11 03:03 -0700
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-05-11 09:02 -0700
Re: And they say C is obscure Manfred <noname@invalid.add> - 2017-05-12 18:34 +0200
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-12 18:47 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-13 09:03 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-09 10:11 +0000
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-09 08:28 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-09 09:40 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-09 20:26 +0000
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-10 00:20 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-08 09:01 -0700
Re: And they say C is obscure John Bode <jfbode1029@gmail.com> - 2017-04-11 09:15 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-11 09:29 -0700
Re: And they say C is obscure Manfred <noname@invalid.add> - 2017-04-13 16:00 +0200
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 19:45 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 11:09 -0700
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-11 08:58 -0700 |
| Message-ID | <6691f455-9b73-49a0-a4e4-955f3c13252d@googlegroups.com> |
| In reply to | #108043 |
On Tuesday, April 11, 2017 at 10:41:37 AM UTC-5, mark.b...@gmail.com wrote:
> So you'd rather it wasn't able to be used to (for example) traverse
> a linked list - chacun a son gout, I suppose.
Many languages have a form of iteration loop which is expressly restricted
to code where the control variable will iterate through a pre-determined
sequence of values. In C, the code:
for (int i=0; i<20; i++)
can either mark the start of a loop in which "i" will iterate sequentially
through the values 0..19, or it might mark the start of a looping construct
where "i" ends up getting changed to an arbitrary sequence of values. Having
a construct which would tell someone reading the code "This variable will
proceed through these values without deviation" without them having to search
for anything that might modify the variable would be helpful. Perhaps C
could add a special rule which would say that if a variable is declared as
"const" within the first clause of a "for" header, that qualifier would
become effective only once the loop body had begun, so that
for (const int i=0; i<20; i++) {...}
would say that within the first pass of the loop "i" would be treated as a
const int equal to 0, within the second pass, it would be treated as a const
int equal to 1, etc. and a compiler would be free to perform strength
reduction involving "i" even if e.g. a program did something like:
writeData(myStream, &i, sizeof i);
which would otherwise compel a compiler to assume that "i" might have been
modified by that or any subsequent outside function calls.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-04-11 09:06 -0700 |
| Message-ID | <a8573a5c-6766-418b-b8f0-e3092c3c6834@googlegroups.com> |
| In reply to | #108043 |
On Tuesday, April 11, 2017 at 4:41:37 PM UTC+1, mark.b...@gmail.com wrote: > On Monday, 10 April 2017 22:10:50 UTC+1, Malcolm McLean wrote: > > > If C's for had the form > > > > for(counter = init_value to end_value, step increment) > > > > like Basic then you would always have a concept of "the loop's > > counting variable" which is the main purpose of a for loop. > > So you'd rather it wasn't able to be used to (for example) traverse > a linked list - chacun a son gout, I suppose. > Ideally you'd have a rule that a for loop must be of the form for(i=0;i<N;i++) (with only i, ii, iii, iv allowed as counting variables) except in the case of iterating over a linked list for(ptr = head; ptr != NULL; ptr = ptr->next) but no compiler can enforce that. However we know that the Basic form form for var = 1 to N step 2 works reasonably well. And it forces you to have a loop counter.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-04-11 16:46 +0000 |
| Message-ID | <kL7HA.157$7O5.41@fx36.iad> |
| In reply to | #108045 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >On Tuesday, April 11, 2017 at 4:41:37 PM UTC+1, mark.b...@gmail.com wrote: >> On Monday, 10 April 2017 22:10:50 UTC+1, Malcolm McLean wrote: >> >> > If C's for had the form >> > >> > for(counter = init_value to end_value, step increment) >> > >> > like Basic then you would always have a concept of "the loop's >> > counting variable" which is the main purpose of a for loop. >> >> So you'd rather it wasn't able to be used to (for example) traverse >> a linked list - chacun a son gout, I suppose. >> >Ideally you'd have a rule that a for loop must be of the form Ideally? As per whose ideals? > >for(i=0;i<N;i++)
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-04-11 19:02 +0100 |
| Message-ID | <87zifmn7pu.fsf@gmail.com> |
| In reply to | #108053 |
scott@slp53.sl.home (Scott Lurndal) writes: >>Ideally you'd have a rule that a for loop must be of the form > > Ideally? As per whose ideals? Malcolm is incapable of distinguishing between his preferences and Platonic ideals. Its kind of his thing.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-14 11:59 +0000 |
| Message-ID | <58f0b7ed.7689531@news.xs4all.nl> |
| In reply to | #108043 |
mark.bluemel@gmail.com wrote: > On Monday, 10 April 2017 22:10:50 UTC+1, Malcolm McLean wrote: > > > If C's for had the form > > > > for(counter = init_value to end_value, step increment) > > > > like Basic then you would always have a concept of "the loop's > > counting variable" which is the main purpose of a for loop. > > So you'd rather it wasn't able to be used to (for example) traverse > a linked list - chacun a son gout, I suppose. Of course not! No, we'd have a special FORLIST statement that allowed you to traverse linked lists. And a FORFILE to allow us to easily and quickly run through the characters in a file. And a FORTREE to run through a tree - there would be special syntax, of course, to allow pre-, post- and in-order traversal, of course, _and_ a special keyword to specify the kind of tree. And a FOREACH. And a FOR2D and a FOR3D. It would all, of course, be much less complicated than C. And you'd still be f*@#&d if you wanted to loop through the data you get from a database connection. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-04-26 10:59 -0700 |
| Message-ID | <kfnvapr3v8g.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #108004 |
bartc <bc@freeuk.com> writes:
> On 10/04/2017 16:22, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>
>>> Here's a nice selection from sample code:
>>>
>>> [examples]
>>
>> It isn't, and IMHO it shouldn't be, up to the standard to restrict
>> what kinds of expressions can appear in a for loop header. It's up
>> to each programmer.
>>
>> The vast majority of C for loops I've seen are reasonably
>> straightforward.
>
> I took a large file of C code at random. I went to line 123,000 and
> searched for the next for-loop which was:
>
> for(i = 0; handler_info[i].name != NULL; i++)
>
> Explain to why that can't be written more clearly as a while-loop,
> [...]
Most loops follow the same general pattern:
there is a simple initialization, to establish the loop
invariant for the base case;
there is a simple test to be performed at the start of each
iteration, to see if all cases have been covered;
there is general code in the loop body that "enlarges" the
loop invariant from the already covered cases to include an
additional case; and
there is a fairly simple update to advance the program state
that shows which cases have been covered.
A for() loop in C recognizes this general pattern, providing
slots for the three simple items, leaving the one larger case for
the body of the loop. One advantage to writing the loop shown
above as a for() loop is to establish that it is following the
common general pattern, and to make it easy to pick those out.
Using while() doesn't do that. Of course that isn't the only
consideration, and other factors (including personal preference)
may tip the decision one way or the other. The point is the
two choices here (ie, between for() and while()) each have their
own plusses and minuses - it isn't all one or all the other.
> In fact, explain to me what the purpose of 'while' is as hardly
> anyone seems to use it!
That's silly. I think most code uses for() loops more often than
while() loops, but certainly while() is used extensively (I
measured while() as roughly 1/3 as often as for() on the average,
over several millions lines of various open-source C projects).
Most loops are easily written as for() loops precisely because
the for() statement was chosen to accommodate the general pattern
that most loops fall into. The reason for having while() is to
deal with loops that do /not/ fall into that pattern. But there
aren't as many of those, so we expect to see it less often.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-27 21:40 +0100 |
| Message-ID | <1HsMA.38105$mr5.3385@fx36.am4> |
| In reply to | #108549 |
On 26/04/2017 18:59, Tim Rentsch wrote:
> bartc <bc@freeuk.com> writes:
>> In fact, explain to me what the purpose of 'while' is as hardly
>> anyone seems to use it!
>
> That's silly. I think most code uses for() loops more often than
> while() loops, but certainly while() is used extensively (I
> measured while() as roughly 1/3 as often as for() on the average,
> over several millions lines of various open-source C projects).
On my current project, the C source has 60 'for' statements and 150
'while' statements. But this is a program that only ever uses 'for' to
iterate over A to B.
The advantage (for me when I look at my own code), is I know instantly
that a for is a[n iterative] for, and not a while masquerading as a for,
or some other kind of beast entirely.
> Most loops are easily written as for() loops
Including all while loops:
while (cond) {}
is equivalent to:
for (;cond;) {}
Both use exactly the same number of characters. Hence my remark that
while isn't really needed, especially considering my observation that
what ought to be while loops are often written as for-loops anyway.
precisely because
> the for() statement was chosen to accommodate the general pattern
> that most loops fall into. The reason for having while() is to
> deal with loops that do /not/ fall into that pattern.
No, for the reason above. The reason /ought/ to be so that obvious
while-loops are written as whiles, and it is then clear at a glance what
we're dealing with. But that very often doesn't happen.
On 26/04/2017 19:02, Tim Rentsch wrote:
> bartc <bc@freeuk.com> writes:
>
>> [...] people here can continue to delude themselves that C's 'for' is
>> superior in all ways to those of any other language.
>
> No one here is saying that, nor do they think it. What is
> the point of misrepresenting that?
No? See:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>> The C for loop is too flexible. [...]
TR:
> What Malcolm means is that the C for loop is too flexible for
> someone who is as brilliant as he is. For those of us who aren't
> in his league, the flexibility of for() in C is seen as being
> more an advantage than it is a disadvantage.
Plus other comments (from others) along the lines of, Those who
criticise C's 'for' or find elaborate uses of it hard to understand,
ought to stick to Basic.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-02 05:17 -0700 |
| Message-ID | <kfn1ss7zc5a.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #108624 |
bartc <bc@freeuk.com> writes:
> On 26/04/2017 18:59, Tim Rentsch wrote:
>> bartc <bc@freeuk.com> writes:
>>
>>> In fact, explain to me what the purpose of 'while' is as hardly
>>> anyone seems to use it!
>>
>> That's silly. I think most code uses for() loops more often than
>> while() loops, but certainly while() is used extensively (I
>> measured while() as roughly 1/3 as often as for() on the average,
>> over several millions lines of various open-source C projects).
>
> On my current project, the C source has 60 'for' statements and 150
> while' statements. But this is a program that only ever uses 'for' to
> iterate over A to B.
>
> The advantage (for me when I look at my own code), is I know instantly
> that a for is a[n iterative] for, and not a while masquerading as a
> for, or some other kind of beast entirely.
>
>> Most loops are easily written as for() loops
>
> Including all while loops:
>
> while (cond) {}
>
> is equivalent to:
>
> for (;cond;) {}
>
> Both use exactly the same number of characters. Hence my remark that
> while isn't really needed, especially considering my observation that
> what ought to be while loops are often written as for-loops anyway.
>
> precisely because
>
>> the for() statement was chosen to accommodate the general pattern
>> that most loops fall into. The reason for having while() is to
>> deal with loops that do /not/ fall into that pattern.
>
> No, for the reason above. The reason /ought/ to be so that obvious
> while-loops are written as whiles, and it is then clear at a glance
> what we're dealing with. But that very often doesn't happen.
We are talking about different things here. What I am talking
about is some C language constructs (in particular for(), and
also while() as most C programmers see them. If you want to see
these constructs differently that's up to you, but it isn't what
I was talking about.
> On 26/04/2017 19:02, Tim Rentsch wrote:
>
>> bartc <bc@freeuk.com> writes:
>>
>>> [...] people here can continue to delude themselves that C's 'for' is
>>> superior in all ways to those of any other language.
>>
>> No one here is saying that, nor do they think it. What is
>> the point of misrepresenting that?
>
> No? See:
>
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>> The C for loop is too flexible. [...]
>
> TR:
>
>> What Malcolm means is that the C for loop is too flexible for
>> someone who is as brilliant as he is. For those of us who aren't
>> in his league, the flexibility of for() in C is seen as being
>> more an advantage than it is a disadvantage.
What I did say is that the flexibility of for() in C is seen [ie,
by myself, and many other C programmers] as being more an
advantage than it is a disadvantage. What I did /not/ say that C's
'for' is superior in all ways to those of any other language. I
hope you understand that those two statements are quite different.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-03 12:50 -0700 |
| Message-ID | <6ae9b3ed-f560-4261-a430-76cbff8c7d9f@googlegroups.com> |
| In reply to | #109022 |
On Tuesday, May 2, 2017 at 5:17:14 AM UTC-7, Tim Rentsch wrote:
> bartc <bc@freeuk.com> writes:
>
> > On 26/04/2017 18:59, Tim Rentsch wrote:
> >> bartc <bc@freeuk.com> writes:
> >>
> >>> In fact, explain to me what the purpose of 'while' is as hardly
> >>> anyone seems to use it!
> >>
> >> That's silly. I think most code uses for() loops more often than
> >> while() loops, but certainly while() is used extensively (I
> >> measured while() as roughly 1/3 as often as for() on the average,
> >> over several millions lines of various open-source C projects).
> >
> > On my current project, the C source has 60 'for' statements and 150
> > while' statements. But this is a program that only ever uses 'for' to
> > iterate over A to B.
> >
> > The advantage (for me when I look at my own code), is I know instantly
> > that a for is a[n iterative] for, and not a while masquerading as a
> > for, or some other kind of beast entirely.
> >
> >> Most loops are easily written as for() loops
> >
> > Including all while loops:
> >
> > while (cond) {}
> >
> > is equivalent to:
> >
> > for (;cond;) {}
> >
> > Both use exactly the same number of characters. Hence my remark that
> > while isn't really needed, especially considering my observation that
> > what ought to be while loops are often written as for-loops anyway.
> >
> > precisely because
> >
> >> the for() statement was chosen to accommodate the general pattern
> >> that most loops fall into. The reason for having while() is to
> >> deal with loops that do /not/ fall into that pattern.
> >
> > No, for the reason above. The reason /ought/ to be so that obvious
> > while-loops are written as whiles, and it is then clear at a glance
> > what we're dealing with. But that very often doesn't happen.
>
> We are talking about different things here. What I am talking
> about is some C language constructs (in particular for(), and
> also while() as most C programmers see them. If you want to see
> these constructs differently that's up to you, but it isn't what
> I was talking about.
>
> > On 26/04/2017 19:02, Tim Rentsch wrote:
> >
> >> bartc <bc@freeuk.com> writes:
> >>
> >>> [...] people here can continue to delude themselves that C's 'for' is
> >>> superior in all ways to those of any other language.
> >>
> >> No one here is saying that, nor do they think it. What is
> >> the point of misrepresenting that?
> >
> > No? See:
> >
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >>
> >>> The C for loop is too flexible. [...]
> >
> > TR:
> >
> >> What Malcolm means is that the C for loop is too flexible for
> >> someone who is as brilliant as he is. For those of us who aren't
> >> in his league, the flexibility of for() in C is seen as being
> >> more an advantage than it is a disadvantage.
>
> What I did say is that the flexibility of for() in C is seen [ie,
> by myself, and many other C programmers] as being more an
> advantage than it is a disadvantage. What I did /not/ say that C's
> 'for' is superior in all ways to those of any other language. I
> hope you understand that those two statements are quite different.
For years know I have been editing all the "for" out of the
source code I am editing. I have yet to see an example where
changing all the "for" to "while" makes anything more obscure.
My objection to "for" is esthetic. The business with two semi-
colons seems to me too non-C-like to tolerate.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-05 01:20 -0700 |
| Message-ID | <kfn7f1vyasf.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #109134 |
David Kleinecke <dkleinecke@gmail.com> writes: > On Tuesday, May 2, 2017 at 5:17:14 AM UTC-7, Tim Rentsch wrote: >> [...contrasting uses of for() and while()...] > > For years know I have been editing all the "for" out of the > source code I am editing. I have yet to see an example where > changing all the "for" to "while" makes anything more obscure. Interesting perception, but not one that is shared by the vast majority of C developers.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-05 12:37 -0700 |
| Message-ID | <0e562728-eeaf-4028-bb43-ed1f7502922e@googlegroups.com> |
| In reply to | #109301 |
On Friday, May 5, 2017 at 1:20:55 AM UTC-7, Tim Rentsch wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > > On Tuesday, May 2, 2017 at 5:17:14 AM UTC-7, Tim Rentsch wrote: > >> [...contrasting uses of for() and while()...] > > > > For years know I have been editing all the "for" out of the > > source code I am editing. I have yet to see an example where > > changing all the "for" to "while" makes anything more obscure. > > Interesting perception, but not one that is shared by the > vast majority of C developers. De gustibus.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-06 00:16 -0700 |
| Message-ID | <kfnmvaqv4jb.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #109371 |
David Kleinecke <dkleinecke@gmail.com> writes: > On Friday, May 5, 2017 at 1:20:55 AM UTC-7, Tim Rentsch wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: >> >>> On Tuesday, May 2, 2017 at 5:17:14 AM UTC-7, Tim Rentsch wrote: >>>> [...contrasting uses of for() and while()...] >>> >>> For years know I have been editing all the "for" out of the >>> source code I am editing. I have yet to see an example where >>> changing all the "for" to "while" makes anything more obscure. >> >> Interesting perception, but not one that is shared by the >> vast majority of C developers. > > De gustibus. Yes, I expect they would say much the same about you. There are at the very least tens of thousands of C developers who see for() as providing advantages over while() in some contexts. Not all of those people are stupid.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-06 11:49 -0700 |
| Message-ID | <5597f232-de91-40e5-9b62-b4c8c8850173@googlegroups.com> |
| In reply to | #109392 |
On Saturday, May 6, 2017 at 12:16:36 AM UTC-7, Tim Rentsch wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > > On Friday, May 5, 2017 at 1:20:55 AM UTC-7, Tim Rentsch wrote: > >> David Kleinecke <dkleinecke@gmail.com> writes: > >> > >>> On Tuesday, May 2, 2017 at 5:17:14 AM UTC-7, Tim Rentsch wrote: > >>>> [...contrasting uses of for() and while()...] > >>> > >>> For years know I have been editing all the "for" out of the > >>> source code I am editing. I have yet to see an example where > >>> changing all the "for" to "while" makes anything more obscure. > >> > >> Interesting perception, but not one that is shared by the > >> vast majority of C developers. > > > > De gustibus. > > Yes, I expect they would say much the same about you. > > There are at the very least tens of thousands of C developers who > see for() as providing advantages over while() in some contexts. > Not all of those people are stupid. De gustibus once again. The gist of "de gustibus" is that neither side (or none of the sides) is wrong, stupid or misguided.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-05-06 13:16 -0700 |
| Message-ID | <27e22247-2611-4d4b-80ea-0fa371935fcf@googlegroups.com> |
| In reply to | #109401 |
On Saturday, May 6, 2017 at 7:49:30 PM UTC+1, David Kleinecke wrote: > > De gustibus once again. The gist of "de gustibus" is > that neither side (or none of the sides) is wrong, stupid > or misguided. > My sister is a philosopher. She says of Scotch whisky "why value smoothness, why not value fire?" I can't quite get together a response to that, but I'm not convinced.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-06 14:10 -0700 |
| Message-ID | <8e8694de-e232-4172-ad3a-c20414b42510@googlegroups.com> |
| In reply to | #109408 |
On Saturday, May 6, 2017 at 1:16:23 PM UTC-7, Malcolm McLean wrote: > On Saturday, May 6, 2017 at 7:49:30 PM UTC+1, David Kleinecke wrote: > > > > De gustibus once again. The gist of "de gustibus" is > > that neither side (or none of the sides) is wrong, stupid > > or misguided. > > > My sister is a philosopher. She says of Scotch whisky "why value smoothness, > why not value fire?" I can't quite get together a response to that, but > I'm not convinced. The trick is to agree to disagree without in any way down- valorizing the other guy's opinions. For example, I read your "but I'm not convinced." as containing a nuance that you agreeing would make your sister's opinion somehow more "true" than it was before you agreed.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2017-05-06 20:23 -0600 |
| Message-ID | <1btw4xtnf1.fsf@pfeifferfamily.net> |
| In reply to | #109401 |
David Kleinecke <dkleinecke@gmail.com> writes: > On Saturday, May 6, 2017 at 12:16:36 AM UTC-7, Tim Rentsch wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: >> >> > On Friday, May 5, 2017 at 1:20:55 AM UTC-7, Tim Rentsch wrote: >> >> David Kleinecke <dkleinecke@gmail.com> writes: >> >> >> >>> On Tuesday, May 2, 2017 at 5:17:14 AM UTC-7, Tim Rentsch wrote: >> >>>> [...contrasting uses of for() and while()...] >> >>> >> >>> For years know I have been editing all the "for" out of the >> >>> source code I am editing. I have yet to see an example where >> >>> changing all the "for" to "while" makes anything more obscure. >> >> >> >> Interesting perception, but not one that is shared by the >> >> vast majority of C developers. >> > >> > De gustibus. >> >> Yes, I expect they would say much the same about you. >> >> There are at the very least tens of thousands of C developers who >> see for() as providing advantages over while() in some contexts. >> Not all of those people are stupid. > > De gustibus once again. The gist of "de gustibus" is > that neither side (or none of the sides) is wrong, stupid > or misguided. Yes, but there are many, many C programmers including me who regard your side of the debate as being, indeed, wrong and misguided (you are clearly not stupid).
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-06 21:51 -0700 |
| Message-ID | <c49a7f80-5709-4888-80c3-ef1b40f93d75@googlegroups.com> |
| In reply to | #109417 |
On Saturday, May 6, 2017 at 7:23:53 PM UTC-7, Joe Pfeiffer wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > > On Saturday, May 6, 2017 at 12:16:36 AM UTC-7, Tim Rentsch wrote: > >> David Kleinecke <dkleinecke@gmail.com> writes: > >> > >> > On Friday, May 5, 2017 at 1:20:55 AM UTC-7, Tim Rentsch wrote: > >> >> David Kleinecke <dkleinecke@gmail.com> writes: > >> >> > >> >>> On Tuesday, May 2, 2017 at 5:17:14 AM UTC-7, Tim Rentsch wrote: > >> >>>> [...contrasting uses of for() and while()...] > >> >>> > >> >>> For years know I have been editing all the "for" out of the > >> >>> source code I am editing. I have yet to see an example where > >> >>> changing all the "for" to "while" makes anything more obscure. > >> >> > >> >> Interesting perception, but not one that is shared by the > >> >> vast majority of C developers. > >> > > >> > De gustibus. > >> > >> Yes, I expect they would say much the same about you. > >> > >> There are at the very least tens of thousands of C developers who > >> see for() as providing advantages over while() in some contexts. > >> Not all of those people are stupid. > > > > De gustibus once again. The gist of "de gustibus" is > > that neither side (or none of the sides) is wrong, stupid > > or misguided. > > Yes, but there are many, many C programmers including me who regard > your side of the debate as being, indeed, wrong and misguided (you are > clearly not stupid). QED
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-05-07 05:04 -0700 |
| Message-ID | <e48956e3-0c7b-4eaf-85a8-1e4bfc8e9581@googlegroups.com> |
| In reply to | #109420 |
W dniu niedziela, 7 maja 2017 06:52:03 UTC+2 użytkownik David Kleinecke napisał:
> On Saturday, May 6, 2017 at 7:23:53 PM UTC-7, Joe Pfeiffer wrote:
> > David Kleinecke <dkleinecke@gmail.com> writes:
> >
> > > On Saturday, May 6, 2017 at 12:16:36 AM UTC-7, Tim Rentsch wrote:
> > >> David Kleinecke <dkleinecke@gmail.com> writes:
> > >>
> > >> > On Friday, May 5, 2017 at 1:20:55 AM UTC-7, Tim Rentsch wrote:
> > >> >> David Kleinecke <dkleinecke@gmail.com> writes:
> > >> >>
> > >> >>> On Tuesday, May 2, 2017 at 5:17:14 AM UTC-7, Tim Rentsch wrote:
> > >> >>>> [...contrasting uses of for() and while()...]
> > >> >>>
> > >> >>> For years know I have been editing all the "for" out of the
> > >> >>> source code I am editing. I have yet to see an example where
> > >> >>> changing all the "for" to "while" makes anything more obscure.
> > >> >>
> > >> >> Interesting perception, but not one that is shared by the
> > >> >> vast majority of C developers.
> > >> >
> > >> > De gustibus.
> > >>
> > >> Yes, I expect they would say much the same about you.
> > >>
> > >> There are at the very least tens of thousands of C developers who
> > >> see for() as providing advantages over while() in some contexts.
> > >> Not all of those people are stupid.
> > >
> > > De gustibus once again. The gist of "de gustibus" is
> > > that neither side (or none of the sides) is wrong, stupid
> > > or misguided.
> >
> > Yes, but there are many, many C programmers including me who regard
> > your side of the debate as being, indeed, wrong and misguided (you are
> > clearly not stupid).
>
> QED
c has praiseworthy attitude to make c codes as short as it could (though i think many holes in this attitude do appear, some intentional some maybe not intentional - it would be good to rethink that and enumerate them but it is a pice of work.. )
if so the reasonable/compromisable step would be imo to furn
for(int i=0; i<222; i++)
into
for(222) //with default i, (j,k if nested)
(as an additional form not repalcement maybe)
its shorter it also os some kind of
abstraction (its easier to think on fors in such form, abstract from machinery for
example thinking how to implement
int a = 100;
for(a) a += rand()%20;
one also can think on such extended
fors:
for(1,2,3,5,7,11,13, 200..300, 299..-200)
where i will be 1 then 2 then .. then 200 then 201.. then 202 etc
also could go in whole pack of abstract fors
non_sequential_for(100) {} //the expresion my be called non sequential order for given i's - but say cannot be called in paralel
sequential_for(100) {} //must be sequential
paralel_for()//may be parralel
and possibly more
(i was writing already on that though
maybe now i see a bit more clear that pack of such built in fors could be good idea)
dont remember the details now
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-05-07 05:09 -0700 |
| Message-ID | <de8d9e98-1ef3-436e-8614-0f64a534d597@googlegroups.com> |
| In reply to | #109421 |
W dniu niedziela, 7 maja 2017 14:04:57 UTC+2 użytkownik fir napisał:
> W dniu niedziela, 7 maja 2017 06:52:03 UTC+2 użytkownik David Kleinecke napisał:
> > On Saturday, May 6, 2017 at 7:23:53 PM UTC-7, Joe Pfeiffer wrote:
> > > David Kleinecke <dkleinecke@gmail.com> writes:
> > >
> > > > On Saturday, May 6, 2017 at 12:16:36 AM UTC-7, Tim Rentsch wrote:
> > > >> David Kleinecke <dkleinecke@gmail.com> writes:
> > > >>
> > > >> > On Friday, May 5, 2017 at 1:20:55 AM UTC-7, Tim Rentsch wrote:
> > > >> >> David Kleinecke <dkleinecke@gmail.com> writes:
> > > >> >>
> > > >> >>> On Tuesday, May 2, 2017 at 5:17:14 AM UTC-7, Tim Rentsch wrote:
> > > >> >>>> [...contrasting uses of for() and while()...]
> > > >> >>>
> > > >> >>> For years know I have been editing all the "for" out of the
> > > >> >>> source code I am editing. I have yet to see an example where
> > > >> >>> changing all the "for" to "while" makes anything more obscure.
> > > >> >>
> > > >> >> Interesting perception, but not one that is shared by the
> > > >> >> vast majority of C developers.
> > > >> >
> > > >> > De gustibus.
> > > >>
> > > >> Yes, I expect they would say much the same about you.
> > > >>
> > > >> There are at the very least tens of thousands of C developers who
> > > >> see for() as providing advantages over while() in some contexts.
> > > >> Not all of those people are stupid.
> > > >
> > > > De gustibus once again. The gist of "de gustibus" is
> > > > that neither side (or none of the sides) is wrong, stupid
> > > > or misguided.
> > >
> > > Yes, but there are many, many C programmers including me who regard
> > > your side of the debate as being, indeed, wrong and misguided (you are
> > > clearly not stupid).
> >
> > QED
>
> c has praiseworthy attitude to make c codes as short as it could (though i think many holes in this attitude do appear, some intentional some maybe not intentional - it would be good to rethink that and enumerate them but it is a pice of work.. )
>
> if so the reasonable/compromisable step would be imo to furn
>
> for(int i=0; i<222; i++)
> into
>
> for(222) //with default i, (j,k if nested)
>
> (as an additional form not repalcement maybe)
>
> its shorter it also os some kind of
> abstraction (its easier to think on fors in such form, abstract from machinery for
> example thinking how to implement
>
> int a = 100;
> for(a) a += rand()%20;
>
> one also can think on such extended
> fors:
>
> for(1,2,3,5,7,11,13, 200..300, 299..-200)
>
> where i will be 1 then 2 then .. then 200 then 201.. then 202 etc
>
> also could go in whole pack of abstract fors
>
> non_sequential_for(100) {} //the expresion my be called non sequential order for given i's - but say cannot be called in paralel
>
> sequential_for(100) {} //must be sequential
>
> paralel_for()//may be parralel
>
> and possibly more
> (i was writing already on that though
> maybe now i see a bit more clear that pack of such built in fors could be good idea)
> dont remember the details now
as to whiles one could said that if for
take numbers of repeats while could take
conditions
for(100)
while(a<100)
which make spearate constructs.. though one could try to blend it into one, though separation also could be good idea
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-05-07 05:18 -0700 |
| Message-ID | <6ddf79ce-3511-460b-8c4c-903474c4d3b6@googlegroups.com> |
| In reply to | #109422 |
W dniu niedziela, 7 maja 2017 14:09:53 UTC+2 użytkownik fir napisał:
> W dniu niedziela, 7 maja 2017 14:04:57 UTC+2 użytkownik fir napisał:
> > W dniu niedziela, 7 maja 2017 06:52:03 UTC+2 użytkownik David Kleinecke napisał:
> > > On Saturday, May 6, 2017 at 7:23:53 PM UTC-7, Joe Pfeiffer wrote:
> > > > David Kleinecke <dkleinecke@gmail.com> writes:
> > > >
> > > > > On Saturday, May 6, 2017 at 12:16:36 AM UTC-7, Tim Rentsch wrote:
> > > > >> David Kleinecke <dkleinecke@gmail.com> writes:
> > > > >>
> > > > >> > On Friday, May 5, 2017 at 1:20:55 AM UTC-7, Tim Rentsch wrote:
> > > > >> >> David Kleinecke <dkleinecke@gmail.com> writes:
> > > > >> >>
> > > > >> >>> On Tuesday, May 2, 2017 at 5:17:14 AM UTC-7, Tim Rentsch wrote:
> > > > >> >>>> [...contrasting uses of for() and while()...]
> > > > >> >>>
> > > > >> >>> For years know I have been editing all the "for" out of the
> > > > >> >>> source code I am editing. I have yet to see an example where
> > > > >> >>> changing all the "for" to "while" makes anything more obscure.
> > > > >> >>
> > > > >> >> Interesting perception, but not one that is shared by the
> > > > >> >> vast majority of C developers.
> > > > >> >
> > > > >> > De gustibus.
> > > > >>
> > > > >> Yes, I expect they would say much the same about you.
> > > > >>
> > > > >> There are at the very least tens of thousands of C developers who
> > > > >> see for() as providing advantages over while() in some contexts.
> > > > >> Not all of those people are stupid.
> > > > >
> > > > > De gustibus once again. The gist of "de gustibus" is
> > > > > that neither side (or none of the sides) is wrong, stupid
> > > > > or misguided.
> > > >
> > > > Yes, but there are many, many C programmers including me who regard
> > > > your side of the debate as being, indeed, wrong and misguided (you are
> > > > clearly not stupid).
> > >
> > > QED
> >
> > c has praiseworthy attitude to make c codes as short as it could (though i think many holes in this attitude do appear, some intentional some maybe not intentional - it would be good to rethink that and enumerate them but it is a pice of work.. )
> >
> > if so the reasonable/compromisable step would be imo to furn
> >
> > for(int i=0; i<222; i++)
> > into
> >
> > for(222) //with default i, (j,k if nested)
> >
> > (as an additional form not repalcement maybe)
> >
> > its shorter it also os some kind of
> > abstraction (its easier to think on fors in such form, abstract from machinery for
> > example thinking how to implement
> >
> > int a = 100;
> > for(a) a += rand()%20;
> >
> > one also can think on such extended
> > fors:
> >
> > for(1,2,3,5,7,11,13, 200..300, 299..-200)
> >
> > where i will be 1 then 2 then .. then 200 then 201.. then 202 etc
> >
> > also could go in whole pack of abstract fors
> >
> > non_sequential_for(100) {} //the expresion my be called non sequential order for given i's - but say cannot be called in paralel
> >
> > sequential_for(100) {} //must be sequential
> >
> > paralel_for()//may be parralel
> >
> > and possibly more
> > (i was writing already on that though
> > maybe now i see a bit more clear that pack of such built in fors could be good idea)
> > dont remember the details now
>
> as to whiles one could said that if for
> take numbers of repeats while could take
> conditions
>
> for(100)
>
> while(a<100)
>
> which make spearate constructs.. though one could try to blend it into one, though separation also could be good idea
one could also try to distinguish (say but some speparate names) while() that
checks the condition on every 'turn' against the one that checks it only on entry once, but hard to say if that would be usable or not really
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web