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 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-05-07 05:54 -0700 |
| Message-ID | <9d28b56d-2fa1-4dcc-a98f-4a7783208fac@googlegroups.com> |
| In reply to | #109423 |
W dniu niedziela, 7 maja 2017 14:18:30 UTC+2 użytkownik fir napisał:
> 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
yet maybe some fragment of some idea how to shorten coded
getting resizable full arrays are done (as it was explained) one coud add syntax for "add + resize"
something like
int outcome[];
for(int i=0; i<10; i++)
outcome[] += i;
where in older prospect it would need more like
int outcome_size = 0;
int outcome[outcome_size];
for(int i=0; i<10; i++)
{
outcome_size++;
resize outcome[outcome_size];
outcome[outcome_size-1] = i;
}
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-07 13:48 +0100 |
| Message-ID | <NIEPA.1357473$w46.1278400@fx39.am4> |
| In reply to | #109421 |
On 07/05/2017 13:04, fir wrote: > 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) This can be done as a macro: #define FOR(n) for(int i=0; i<(n); ++i) Nested FOR would be OK (each i is in a different scope), provided you don't need access to the loop index. Ie. just a repeat-N-times loop. > 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; You've lost me here; what does this mean? (That's not a good sign for a new language proposal!) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-05-07 06:13 -0700 |
| Message-ID | <a1137706-f88d-4714-9204-50d838d23404@googlegroups.com> |
| In reply to | #109424 |
W dniu niedziela, 7 maja 2017 14:48:52 UTC+2 użytkownik Bart napisał: > On 07/05/2017 13:04, fir wrote: > > > 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) > > This can be done as a macro: > > #define FOR(n) for(int i=0; i<(n); ++i) > > Nested FOR would be OK (each i is in a different scope), provided you > don't need access to the loop index. Ie. just a repeat-N-times loop. > > > > 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; > > You've lost me here; what does this mean? (That's not a good sign for a > new language proposal!) > i dont know, this is open question ;c (not meaning that answer to this is interesting, right now i dont see much usability that can be puttet here but i not 'investigated' it and i dont know) this is sorta touchinga problem like for(int i=0; i<strlen(s); i++) which i usually forgetting how it works (afair it calls strlen every turn which in this case is bad)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-07 15:10 +0200 |
| Message-ID | <oen65i$feh$1@dont-email.me> |
| In reply to | #109420 |
On 07/05/17 06:51, David Kleinecke wrote: > 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 > No, I believe you have (again) missed the point. The idea of "de gustibus" is a balance - "In matters of taste, there can be no disputes". It applies to arguments like emacs vs. vim, or which brace style is "best" in C, or if you should use underscores or camelCaps in identifiers. But in this case, there is one person (you) who has rather weird ideas about how to write and re-write C code - and everyone else who has expressed an opinion here, along with all the authors of C code easily available for examination, have a completely different opinion. Further, several people have given good reasons for using standard C formulations and types (the main point being that they are /standard/) and asked you for justification for your opinion - with no answer. This is not "de gustibus" - it's like a crackpot who claims people never actually went to the moon, and that his opinion that the moon is made of cheese is equally valid to anyone else's opinion. You are, of course, free to write C code however you want to - at least, when it is just for your own entertainment and hobby interest. But don't expect anyone else to see it as anything other than wrong and misguided - unless you can provide solid justification for /why/ you think your ideas lead to clearer or better code, or that it is an method that other people support.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2017-05-07 16:47 +0200 |
| Message-ID | <oenc1i$lng$1@gioia.aioe.org> |
| In reply to | #109427 |
On 5/7/2017 3:10 PM, David Brown wrote: > On 07/05/17 06:51, David Kleinecke wrote: >> QED >> > > No, I believe you have (again) missed the point. The idea of "de > gustibus" is a balance - "In matters of taste, there can be no > disputes". <snip> > This is not "de gustibus" - it's like a crackpot who claims people never > actually went to the moon, and that his opinion that the moon is made of > cheese is equally valid to anyone else's opinion. Excellent point on the real meaning of "de gustibus non disputandum est" - knowledge of Latin being way too much underestimated and misused nowadays. > > You are, of course, free to write C code however you want to - at least, > when it is just for your own entertainment and hobby interest. I would stress the point as /if/ "it is just for your own entertainment" Serious code, that is meant to run in some real life environment, should be just good. But > don't expect anyone else to see it as anything other than wrong and > misguided - unless you can provide solid justification for /why/ you > think your ideas lead to clearer or better code, or that it is an method > that other people support. > I would replace the /or/ into /and/ "that it is a method that other people support" Some practice is not to be considered good just because it may be commonly used by someone else, think e.g. of blind copy-paste from unverified sources on the net.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-07 21:08 +0200 |
| Message-ID | <oenr5g$odt$1@dont-email.me> |
| In reply to | #109430 |
On 07/05/17 16:47, Manfred wrote:
> On 5/7/2017 3:10 PM, David Brown wrote:
>> On 07/05/17 06:51, David Kleinecke wrote:
>>> QED
>>>
>>
>> No, I believe you have (again) missed the point. The idea of "de
>> gustibus" is a balance - "In matters of taste, there can be no
>> disputes".
> <snip>
>> This is not "de gustibus" - it's like a crackpot who claims people never
>> actually went to the moon, and that his opinion that the moon is made of
>> cheese is equally valid to anyone else's opinion.
> Excellent point on the real meaning of "de gustibus non disputandum est"
> - knowledge of Latin being way too much underestimated and misused
> nowadays.
My knowledge of Latin is poor, but my google-foo is top class :-)
>
>>
>> You are, of course, free to write C code however you want to - at least,
>> when it is just for your own entertainment and hobby interest.
> I would stress the point as /if/ "it is just for your own entertainment"
> Serious code, that is meant to run in some real life environment, should
> be just good.
Most professional programmers who have been in the job for a while have
had to deal with code written by some muppet that things their own
personal style of C is best. You know, code that begins with "#define
begin {", or "#define FOR(n) for(int i=0; i<(n); ++i)".
>
> But
>> don't expect anyone else to see it as anything other than wrong and
>> misguided - unless you can provide solid justification for /why/ you
>> think your ideas lead to clearer or better code, or that it is an method
>> that other people support.
>>
> I would replace the /or/ into /and/ "that it is a method that other
> people support"
> Some practice is not to be considered good just because it may be
> commonly used by someone else, think e.g. of blind copy-paste from
> unverified sources on the net.
I guess so. It turns out that millions of people /can/ be wrong :-)
But if significant numbers of people follow a particular style in C,
then you can at least argue popularity and familiarity as a benefit for it.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-07 21:54 +0100 |
| Message-ID | <LPLPA.747132$QJ4.658204@fx26.am4> |
| In reply to | #109444 |
On 07/05/2017 20:08, David Brown wrote:
> Most professional programmers who have been in the job for a while have
> had to deal with code written by some muppet that things their own
> personal style of C is best. You know, code that begins with "#define
> begin {", or "#define FOR(n) for(int i=0; i<(n); ++i)".
That last example looks suspiciously like the example macro I posted
earlier today (in response to a suggested N-times loop, as I assumed it
was).
I would no longer use such macros (I don't think language deficiencies
should be fixed with the CPP; it's not powerful enough anyway).
But examples such as those are fairly innocuous, so it's bit rich
looking down your nose at them. Not when you look at a lot of open
source code and it's so plastered with macros that you can't make head
or tail of it.
Here's a macro call in gcc.c I noticed:
PATFETCH(c);
What's PATFETCH? It's one of these:
# ifndef PATFETCH
# ifdef WCHAR
# define PATFETCH(c) \
do {if (p == pend) return REG_EEND; \
c = (UCHAR_T) *p++; \
if (translate && (c <= 0xff)) c = (UCHAR_T) translate[c]; \
} while (0)
# else /* BYTE */
# define PATFETCH(c) \
do {if (p == pend) return REG_EEND; \
c = (unsigned char) *p++; \
if (translate) c = (unsigned char) translate[c]; \
} while (0)
# endif /* WCHAR */
# endif
Any the wiser? Probably not!
There are any number examples of macro used to impose a style on code
which also serves to make it incomprehensible to everyone else. Is that
macro call defined as a function, variable, expression, another macro,
an attribute, a type, or just defined as nothing at all? You have to to
research every single one to get a picture of what a bit of code is
actually doing.
Please just give me the luxury of dealing only with a handful of macros
such as FOR!
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-08 00:59 +0200 |
| Message-ID | <oeo8m9$7ek$1@dont-email.me> |
| In reply to | #109447 |
On 07/05/17 22:54, bartc wrote:
> On 07/05/2017 20:08, David Brown wrote:
>
>> Most professional programmers who have been in the job for a while have
>> had to deal with code written by some muppet that things their own
>> personal style of C is best. You know, code that begins with "#define
>> begin {", or "#define FOR(n) for(int i=0; i<(n); ++i)".
>
> That last example looks suspiciously like the example macro I posted
> earlier today (in response to a suggested N-times loop, as I assumed it
> was).
>
Yes indeed. I don't think you were advocating its use - merely telling
the other poster that it was possible (which is fair enough).
> I would no longer use such macros (I don't think language deficiencies
> should be fixed with the CPP; it's not powerful enough anyway).
I don't think language "deficiencies" should be "fixed" except by
changes to the language, /modest/ implementation extensions, or simply
using a different language. If you want to use C, use C. If you want
to use something else, use that. There are enough programming languages
around to choose from if C does not suit your taste or your needs.
For example, if you don't like C's "for" loops, C++ allows alternatives
like "for (auto i : {1, 2, 3, 4, 5})". Or you can just pick a
completely different language.
>
> But examples such as those are fairly innocuous, so it's bit rich
> looking down your nose at them.
No, it is not "a bit rich". Just because there are worse misuses of the
pre-processor, does not mean that those two examples are bad!
> Not when you look at a lot of open
> source code and it's so plastered with macros that you can't make head
> or tail of it.
Lots of people write crap code. When it is published as open source,
everyone can see the crap code - rather than having it hidden away.
Nothing about being open source implies quality or lack of quality, or
good style or bad style. Without looking in detail, of course, it is
hard to guess if a macro is a good use of the preprocessor, or a bad misuse.
>
> Here's a macro call in gcc.c I noticed:
>
> PATFETCH(c);
>
> What's PATFETCH? It's one of these:
>
> # ifndef PATFETCH
> # ifdef WCHAR
> # define PATFETCH(c) \
> do {if (p == pend) return REG_EEND; \
> c = (UCHAR_T) *p++; \
> if (translate && (c <= 0xff)) c = (UCHAR_T) translate[c]; \
> } while (0)
> # else /* BYTE */
> # define PATFETCH(c) \
> do {if (p == pend) return REG_EEND; \
> c = (unsigned char) *p++; \
> if (translate) c = (unsigned char) translate[c]; \
> } while (0)
> # endif /* WCHAR */
> # endif
>
> Any the wiser? Probably not!
/I/ am none the wiser from that. But presumably someone has good reason
for the macro - or at least, /had/ a good reason when it was written.
These days, a functional macro like that would be best written as an
inline function - but that was not a possibility in gcc's early days
(and anyway, a C compiler usually has to be written in slightly old
language, to avoid chicken-and-egg issues).
>
> There are any number examples of macro used to impose a style on code
> which also serves to make it incomprehensible to everyone else. Is that
> macro call defined as a function, variable, expression, another macro,
> an attribute, a type, or just defined as nothing at all? You have to to
> research every single one to get a picture of what a bit of code is
> actually doing.
>
There is a /huge/ different between a macro that is doing something
/new/, and one that is giving a new name to standard features, or simply
hiding normal C code.
> Please just give me the luxury of dealing only with a handful of macros
> such as FOR!
>
Well, of course /you/ can use it. But I can tell you I'd hate to have
to see it in real code, and I'd consider it a mark of someone who does
not understand C.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-07 16:59 -0700 |
| Message-ID | <ceb4736b-862a-4006-85d6-f2b18b0e1d2d@googlegroups.com> |
| In reply to | #109448 |
On Sunday, May 7, 2017 at 3:59:33 PM UTC-7, David Brown wrote:
> On 07/05/17 22:54, bartc wrote:
> > On 07/05/2017 20:08, David Brown wrote:
> >
> >> Most professional programmers who have been in the job for a while have
> >> had to deal with code written by some muppet that things their own
> >> personal style of C is best. You know, code that begins with "#define
> >> begin {", or "#define FOR(n) for(int i=0; i<(n); ++i)".
> >
> > That last example looks suspiciously like the example macro I posted
> > earlier today (in response to a suggested N-times loop, as I assumed it
> > was).
> >
>
> Yes indeed. I don't think you were advocating its use - merely telling
> the other poster that it was possible (which is fair enough).
>
> > I would no longer use such macros (I don't think language deficiencies
> > should be fixed with the CPP; it's not powerful enough anyway).
>
> I don't think language "deficiencies" should be "fixed" except by
> changes to the language, /modest/ implementation extensions, or simply
> using a different language. If you want to use C, use C. If you want
> to use something else, use that. There are enough programming languages
> around to choose from if C does not suit your taste or your needs.
>
> For example, if you don't like C's "for" loops, C++ allows alternatives
> like "for (auto i : {1, 2, 3, 4, 5})". Or you can just pick a
> completely different language.
>
> >
> > But examples such as those are fairly innocuous, so it's bit rich
> > looking down your nose at them.
>
> No, it is not "a bit rich". Just because there are worse misuses of the
> pre-processor, does not mean that those two examples are bad!
>
> > Not when you look at a lot of open
> > source code and it's so plastered with macros that you can't make head
> > or tail of it.
>
> Lots of people write crap code. When it is published as open source,
> everyone can see the crap code - rather than having it hidden away.
> Nothing about being open source implies quality or lack of quality, or
> good style or bad style. Without looking in detail, of course, it is
> hard to guess if a macro is a good use of the preprocessor, or a bad misuse.
>
> >
> > Here's a macro call in gcc.c I noticed:
> >
> > PATFETCH(c);
> >
> > What's PATFETCH? It's one of these:
> >
> > # ifndef PATFETCH
> > # ifdef WCHAR
> > # define PATFETCH(c) \
> > do {if (p == pend) return REG_EEND; \
> > c = (UCHAR_T) *p++; \
> > if (translate && (c <= 0xff)) c = (UCHAR_T) translate[c]; \
> > } while (0)
> > # else /* BYTE */
> > # define PATFETCH(c) \
> > do {if (p == pend) return REG_EEND; \
> > c = (unsigned char) *p++; \
> > if (translate) c = (unsigned char) translate[c]; \
> > } while (0)
> > # endif /* WCHAR */
> > # endif
> >
> > Any the wiser? Probably not!
>
> /I/ am none the wiser from that. But presumably someone has good reason
> for the macro - or at least, /had/ a good reason when it was written.
> These days, a functional macro like that would be best written as an
> inline function - but that was not a possibility in gcc's early days
> (and anyway, a C compiler usually has to be written in slightly old
> language, to avoid chicken-and-egg issues).
>
> >
> > There are any number examples of macro used to impose a style on code
> > which also serves to make it incomprehensible to everyone else. Is that
> > macro call defined as a function, variable, expression, another macro,
> > an attribute, a type, or just defined as nothing at all? You have to to
> > research every single one to get a picture of what a bit of code is
> > actually doing.
> >
>
> There is a /huge/ different between a macro that is doing something
> /new/, and one that is giving a new name to standard features, or simply
> hiding normal C code.
>
> > Please just give me the luxury of dealing only with a handful of macros
> > such as FOR!
> >
>
> Well, of course /you/ can use it. But I can tell you I'd hate to have
> to see it in real code, and I'd consider it a mark of someone who does
> not understand C.
I think your point about inline functions deserves to
be underlined. It is (obviously?) the way to go.
I think even the C89 standard would allow a compiler that
inlined all the static subroutines in a unit. These days of
lots of memory makes that quite feasible. Note that that way
there is no need for an "inline" keyword. Has anybody done
that?
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-07 22:28 -0500 |
| Message-ID | <t1pvgc1487ecbcesd5ra96lgp5bj8qu0lk@4ax.com> |
| In reply to | #109449 |
On Sun, 7 May 2017 16:59:11 -0700 (PDT), David Kleinecke
<dkleinecke@gmail.com> wrote:
>On Sunday, May 7, 2017 at 3:59:33 PM UTC-7, David Brown wrote:
>> On 07/05/17 22:54, bartc wrote:
>> > On 07/05/2017 20:08, David Brown wrote:
>> >
>> >> Most professional programmers who have been in the job for a while have
>> >> had to deal with code written by some muppet that things their own
>> >> personal style of C is best. You know, code that begins with "#define
>> >> begin {", or "#define FOR(n) for(int i=0; i<(n); ++i)".
>> >
>> > That last example looks suspiciously like the example macro I posted
>> > earlier today (in response to a suggested N-times loop, as I assumed it
>> > was).
>> >
>>
>> Yes indeed. I don't think you were advocating its use - merely telling
>> the other poster that it was possible (which is fair enough).
>>
>> > I would no longer use such macros (I don't think language deficiencies
>> > should be fixed with the CPP; it's not powerful enough anyway).
>>
>> I don't think language "deficiencies" should be "fixed" except by
>> changes to the language, /modest/ implementation extensions, or simply
>> using a different language. If you want to use C, use C. If you want
>> to use something else, use that. There are enough programming languages
>> around to choose from if C does not suit your taste or your needs.
>>
>> For example, if you don't like C's "for" loops, C++ allows alternatives
>> like "for (auto i : {1, 2, 3, 4, 5})". Or you can just pick a
>> completely different language.
>>
>> >
>> > But examples such as those are fairly innocuous, so it's bit rich
>> > looking down your nose at them.
>>
>> No, it is not "a bit rich". Just because there are worse misuses of the
>> pre-processor, does not mean that those two examples are bad!
>>
>> > Not when you look at a lot of open
>> > source code and it's so plastered with macros that you can't make head
>> > or tail of it.
>>
>> Lots of people write crap code. When it is published as open source,
>> everyone can see the crap code - rather than having it hidden away.
>> Nothing about being open source implies quality or lack of quality, or
>> good style or bad style. Without looking in detail, of course, it is
>> hard to guess if a macro is a good use of the preprocessor, or a bad misuse.
>>
>> >
>> > Here's a macro call in gcc.c I noticed:
>> >
>> > PATFETCH(c);
>> >
>> > What's PATFETCH? It's one of these:
>> >
>> > # ifndef PATFETCH
>> > # ifdef WCHAR
>> > # define PATFETCH(c) \
>> > do {if (p == pend) return REG_EEND; \
>> > c = (UCHAR_T) *p++; \
>> > if (translate && (c <= 0xff)) c = (UCHAR_T) translate[c]; \
>> > } while (0)
>> > # else /* BYTE */
>> > # define PATFETCH(c) \
>> > do {if (p == pend) return REG_EEND; \
>> > c = (unsigned char) *p++; \
>> > if (translate) c = (unsigned char) translate[c]; \
>> > } while (0)
>> > # endif /* WCHAR */
>> > # endif
>> >
>> > Any the wiser? Probably not!
>>
>> /I/ am none the wiser from that. But presumably someone has good reason
>> for the macro - or at least, /had/ a good reason when it was written.
>> These days, a functional macro like that would be best written as an
>> inline function - but that was not a possibility in gcc's early days
>> (and anyway, a C compiler usually has to be written in slightly old
>> language, to avoid chicken-and-egg issues).
>>
>> >
>> > There are any number examples of macro used to impose a style on code
>> > which also serves to make it incomprehensible to everyone else. Is that
>> > macro call defined as a function, variable, expression, another macro,
>> > an attribute, a type, or just defined as nothing at all? You have to to
>> > research every single one to get a picture of what a bit of code is
>> > actually doing.
>> >
>>
>> There is a /huge/ different between a macro that is doing something
>> /new/, and one that is giving a new name to standard features, or simply
>> hiding normal C code.
>>
>> > Please just give me the luxury of dealing only with a handful of macros
>> > such as FOR!
>> >
>>
>> Well, of course /you/ can use it. But I can tell you I'd hate to have
>> to see it in real code, and I'd consider it a mark of someone who does
>> not understand C.
>
>I think your point about inline functions deserves to
>be underlined. It is (obviously?) the way to go.
>
>I think even the C89 standard would allow a compiler that
>inlined all the static subroutines in a unit. These days of
>lots of memory makes that quite feasible. Note that that way
>there is no need for an "inline" keyword. Has anybody done
>that?
All static functions? No, that would probably be silly. But many
compilers will inline functions based on various heuristics, whether
or not they're declared as static or inline. If it's not static the
compiler will likely have to generate an out-of-line version as well
(in case someone calls it), and inline really just gets treated as a
hint (not unlike "register", although in many implementations register
has no effect other than preventing you from taking the address of the
object). LTCG makes that work even better, as things can be inlined
across translation units. FWIW, compilers can't inline all functions
marked "inline" either - for example, they cannot do so for in general
for recursive functions.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-08 10:16 +0200 |
| Message-ID | <oep9af$fli$1@dont-email.me> |
| In reply to | #109449 |
On 08/05/17 01:59, David Kleinecke wrote: > On Sunday, May 7, 2017 at 3:59:33 PM UTC-7, David Brown wrote: <snip> >> /I/ am none the wiser from that. But presumably someone has good reason >> for the macro - or at least, /had/ a good reason when it was written. >> These days, a functional macro like that would be best written as an >> inline function - but that was not a possibility in gcc's early days >> (and anyway, a C compiler usually has to be written in slightly old >> language, to avoid chicken-and-egg issues). <snip> > > I think your point about inline functions deserves to > be underlined. It is (obviously?) the way to go. Inline functions are usually a better choice than functional macros when you can use them. Not every piece of code /can/ use inline functions - people still write to the C89 standard. > > I think even the C89 standard would allow a compiler that > inlined all the static subroutines in a unit. Compilers are free to optimise code in many interesting ways. > These days of > lots of memory makes that quite feasible. Note that that way > there is no need for an "inline" keyword. Has anybody done > that? > Modern compilers will usually automatically inline static functions that are only ever used once, since that is almost always a win for code speed (finding reasons why it might not be a win is left as an exercise for the reader). Inlining other static functions may or may not help - good compilers have increasingly more sophisticated algorithms to determine this. With higher optimisation settings, compilers are usually better at figuring out this sort of thing than programmers, and the "inline" hint is mostly ignored.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-05-08 02:41 -0700 |
| Message-ID | <92d4ace5-6b5a-4fc9-903d-01b77a46cef9@googlegroups.com> |
| In reply to | #109448 |
On Sunday, May 7, 2017 at 11:59:33 PM UTC+1, David Brown wrote: > > Lots of people write crap code. When it is published as open source, > everyone can see the crap code - rather than having it hidden away. > Nothing about being open source implies quality or lack of quality, or > good style or bad style. Without looking in detail, of course, it is > hard to guess if a macro is a good use of the preprocessor, or a bad misuse. > A programmer working for a company can be fired if he fails to follow house style. If you're not treated the code as an asset, you don't have that discipline. Having said that, there's plenty of bad practice everywhere. I've done academic, games and embedded programming (only a bit of embedded), but what I've never done is take a job with one of the software giants like Microsoft or Adobe.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-05-08 07:36 -0700 |
| Message-ID | <2085d77f-513c-48f6-ad88-d55d79b17aef@googlegroups.com> |
| In reply to | #109479 |
W dniu poniedziałek, 8 maja 2017 11:41:28 UTC+2 użytkownik Malcolm McLean napisał: > On Sunday, May 7, 2017 at 11:59:33 PM UTC+1, David Brown wrote: > > > > Lots of people write crap code. When it is published as open source, > > everyone can see the crap code - rather than having it hidden away. > > Nothing about being open source implies quality or lack of quality, or > > good style or bad style. Without looking in detail, of course, it is > > hard to guess if a macro is a good use of the preprocessor, or a bad misuse. > > i would like to see examples what is that 'crap code' (right now it sounds more to me as a name that uses a 'crap talker' less the good definition (as problem here is more deep and less vulgar imo) [check for example some more previous notes ehen i wrote that a bit bad code is in my opinion for some reasons better than better one] > A programmer working for a company can be fired if he fails to follow house > style. If you're not treated the code as an asset, you don't have that discipline. > > Having said that, there's plenty of bad practice everywhere. I've done academic, > games and embedded programming (only a bit of embedded), but what > I've never done is take a job with one of the software giants like Microsoft or > Adobe.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-05-09 10:06 +0000 |
| Message-ID | <59119412.843046@news.xs4all.nl> |
| In reply to | #109444 |
David Brown <david.brown@hesbynett.no> wrote: > On 07/05/17 16:47, Manfred wrote: > > On 5/7/2017 3:10 PM, David Brown wrote: > >> No, I believe you have (again) missed the point. The idea of "de > >> gustibus" is a balance - "In matters of taste, there can be no > >> disputes". > >> This is not "de gustibus" - it's like a crackpot who claims people never > >> actually went to the moon, and that his opinion that the moon is made of > >> cheese is equally valid to anyone else's opinion. > > Excellent point on the real meaning of "de gustibus non disputandum est" > > - knowledge of Latin being way too much underestimated and misused > > nowadays. > > My knowledge of Latin is poor, but my google-foo is top class :-) Whereas my knowledge of Latin is just a little (sic!) better, so I can tell you that the correct meaning isn't that taste _cannot_ be disputed but that it _should not_ be. Which is similar, but not quite the same. Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-09 14:03 +0200 |
| Message-ID | <oesb10$u6v$1@dont-email.me> |
| In reply to | #109570 |
On 09/05/17 12:06, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> On 07/05/17 16:47, Manfred wrote: >>> On 5/7/2017 3:10 PM, David Brown wrote: > >>>> No, I believe you have (again) missed the point. The idea of "de >>>> gustibus" is a balance - "In matters of taste, there can be no >>>> disputes". > >>>> This is not "de gustibus" - it's like a crackpot who claims people never >>>> actually went to the moon, and that his opinion that the moon is made of >>>> cheese is equally valid to anyone else's opinion. > >>> Excellent point on the real meaning of "de gustibus non disputandum est" >>> - knowledge of Latin being way too much underestimated and misused >>> nowadays. >> >> My knowledge of Latin is poor, but my google-foo is top class :-) > > Whereas my knowledge of Latin is just a little (sic!) better, so I can > tell you that the correct meaning isn't that taste _cannot_ be disputed > but that it _should not_ be. Which is similar, but not quite the same. > Your Latin beats mine by a long way here - thank you for the correction! I have very little knowledge of the tenses here, and can't tell the difference between "should not be corrected", "can not be corrected", "was not corrected", or any other combination.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2017-05-09 19:41 +0200 |
| Message-ID | <oesv0u$iva$1@gioia.aioe.org> |
| In reply to | #109579 |
On 5/9/2017 2:03 PM, David Brown wrote: > On 09/05/17 12:06, Richard Bos wrote: >> David Brown <david.brown@hesbynett.no> wrote: >> >>> On 07/05/17 16:47, Manfred wrote: >>>> On 5/7/2017 3:10 PM, David Brown wrote: >> >>>>> No, I believe you have (again) missed the point. The idea of "de >>>>> gustibus" is a balance - "In matters of taste, there can be no >>>>> disputes". >> >>>>> This is not "de gustibus" - it's like a crackpot who claims people never >>>>> actually went to the moon, and that his opinion that the moon is made of >>>>> cheese is equally valid to anyone else's opinion. >> >>>> Excellent point on the real meaning of "de gustibus non disputandum est" >>>> - knowledge of Latin being way too much underestimated and misused >>>> nowadays. >>> >>> My knowledge of Latin is poor, but my google-foo is top class :-) >> >> Whereas my knowledge of Latin is just a little (sic!) better, so I can >> tell you that the correct meaning isn't that taste _cannot_ be disputed >> but that it _should not_ be. Which is similar, but not quite the same. >> > > Your Latin beats mine by a long way here - thank you for the correction! > I have very little knowledge of the tenses here, and can't tell the > difference between "should not be corrected", "can not be corrected", > "was not corrected", or any other combination. > This is going off-topic, but my taste suggests a bit of a follow-up... The literal translation is: about taste (it) is not to be disputed Which in modern languages translates as /should not/ so I am in line with Richard Bos here. I also think that in fact the baseline meaning does not substantially differ from the initial wording from David Brown (there can be no disputes) - obviously one /can/ dispute whether chocolate tastes better than cream, but still there is no point in doing that. Back to the point of the value of Latin, I happened to study it during my high-school time. And, despite the mainstream opinion that would classify it as outdated and a waste of time, I considered it very useful for my education for two main reasons: 1) It is a very structured language, with strict syntactic rules (especially classic Latin) whose study is an excellent exercise of logical thinking. 2) It is the foundation of many European languages (with the notable exceptions of Hungarian and Finnish, besides Greek), and analyzing the roots of modern languages and how they have evolved gives some hint, in my perception, of how the (representation of) human knowledge has evolved in time.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-09 21:35 +0200 |
| Message-ID | <oet5g7$v4q$1@dont-email.me> |
| In reply to | #109611 |
On 09/05/17 19:41, Manfred wrote: > On 5/9/2017 2:03 PM, David Brown wrote: >> On 09/05/17 12:06, Richard Bos wrote: >>> David Brown <david.brown@hesbynett.no> wrote: >>> >>>> On 07/05/17 16:47, Manfred wrote: >>>>> On 5/7/2017 3:10 PM, David Brown wrote: >>> >>>>>> No, I believe you have (again) missed the point. The idea of "de >>>>>> gustibus" is a balance - "In matters of taste, there can be no >>>>>> disputes". >>> >>>>>> This is not "de gustibus" - it's like a crackpot who claims people >>>>>> never >>>>>> actually went to the moon, and that his opinion that the moon is >>>>>> made of >>>>>> cheese is equally valid to anyone else's opinion. >>> >>>>> Excellent point on the real meaning of "de gustibus non disputandum >>>>> est" >>>>> - knowledge of Latin being way too much underestimated and misused >>>>> nowadays. >>>> >>>> My knowledge of Latin is poor, but my google-foo is top class :-) >>> >>> Whereas my knowledge of Latin is just a little (sic!) better, so I can >>> tell you that the correct meaning isn't that taste _cannot_ be disputed >>> but that it _should not_ be. Which is similar, but not quite the same. >>> >> >> Your Latin beats mine by a long way here - thank you for the correction! >> I have very little knowledge of the tenses here, and can't tell the >> difference between "should not be corrected", "can not be corrected", >> "was not corrected", or any other combination. >> > > This is going off-topic, but my taste suggests a bit of a follow-up... > > The literal translation is: about taste (it) is not to be disputed > Which in modern languages translates as /should not/ so I am in line > with Richard Bos here. Very interesting, thanks. > I also think that in fact the baseline meaning does not substantially > differ from the initial wording from David Brown (there can be no > disputes) - obviously one /can/ dispute whether chocolate tastes better > than cream, but still there is no point in doing that. Agreed, there is no point in disputing the fact that chocolate tastes better :-) > > Back to the point of the value of Latin, I happened to study it during > my high-school time. And, despite the mainstream opinion that would > classify it as outdated and a waste of time, I considered it very useful > for my education for two main reasons: > 1) It is a very structured language, with strict syntactic rules > (especially classic Latin) whose study is an excellent exercise of > logical thinking. Due to unfortunate timing when moving house, and therefore school, I missed out on learning Latin. But I agree with you here - it is training in logical thinking and in learning. It is a little like maths in school - for many people, the maths they learn at school goes way beyond what the ever need in later life (programmers are an exception, perhaps). But the training in logical thought, attention to detail and problem solving is important. > 2) It is the foundation of many European languages (with the notable > exceptions of Hungarian and Finnish, besides Greek), and analyzing the > roots of modern languages and how they have evolved gives some hint, in > my perception, of how the (representation of) human knowledge has > evolved in time. > Latin is not the foundation for Germanic languages, nor the Slavic languages, which are the other two major language groups in Europe. There are many other languages that are significantly different from any of these - whether they are "notable" is, of course de gustibus.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-05-09 20:25 +0000 |
| Message-ID | <591224e7.142125@news.xs4all.nl> |
| In reply to | #109622 |
David Brown <david.brown@hesbynett.no> wrote: > On 09/05/17 19:41, Manfred wrote: > > Back to the point of the value of Latin, I happened to study it during > > my high-school time. And, despite the mainstream opinion that would > > classify it as outdated and a waste of time, I considered it very useful > > for my education for two main reasons: > > 1) It is a very structured language, with strict syntactic rules > > (especially classic Latin) whose study is an excellent exercise of > > logical thinking. > > Due to unfortunate timing when moving house, and therefore school, I > missed out on learning Latin. But I agree with you here - it is > training in logical thinking and in learning. It is a little like maths > in school - for many people, the maths they learn at school goes way > beyond what the ever need in later life (programmers are an exception, > perhaps). But the training in logical thought, attention to detail and > problem solving is important. Don't forget metre! Learning to scan dactylic hexameter _properly_ is great for diction. Alas, it's not as useful in writing C, which cares little for rhythm... > > 2) It is the foundation of many European languages (with the notable > > exceptions of Hungarian and Finnish, besides Greek), and analyzing the > > roots of modern languages and how they have evolved gives some hint, in > > my perception, of how the (representation of) human knowledge has > > evolved in time. > > Latin is not the foundation for Germanic languages, nor the Slavic > languages, which are the other two major language groups in Europe. > There are many other languages that are significantly different from any > of these - whether they are "notable" is, of course de gustibus. True, but all Indo-European languages are at least somewhat related, and learning one extra is always useful for better understanding the others. Fenno-Ugric and Basque, not so much. (Much as learning Fortran might help you understand C better, and v.v.; but Prolog or APL, not really.) Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-10 14:48 +0200 |
| Message-ID | <oev21d$55h$1@dont-email.me> |
| In reply to | #109627 |
On 09/05/17 22:25, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> On 09/05/17 19:41, Manfred wrote: > >>> Back to the point of the value of Latin, I happened to study it during >>> my high-school time. And, despite the mainstream opinion that would >>> classify it as outdated and a waste of time, I considered it very useful >>> for my education for two main reasons: >>> 1) It is a very structured language, with strict syntactic rules >>> (especially classic Latin) whose study is an excellent exercise of >>> logical thinking. >> >> Due to unfortunate timing when moving house, and therefore school, I >> missed out on learning Latin. But I agree with you here - it is >> training in logical thinking and in learning. It is a little like maths >> in school - for many people, the maths they learn at school goes way >> beyond what the ever need in later life (programmers are an exception, >> perhaps). But the training in logical thought, attention to detail and >> problem solving is important. > > Don't forget metre! Learning to scan dactylic hexameter _properly_ is > great for diction. Alas, it's not as useful in writing C, which cares > little for rhythm... > >>> 2) It is the foundation of many European languages (with the notable >>> exceptions of Hungarian and Finnish, besides Greek), and analyzing the >>> roots of modern languages and how they have evolved gives some hint, in >>> my perception, of how the (representation of) human knowledge has >>> evolved in time. >> >> Latin is not the foundation for Germanic languages, nor the Slavic >> languages, which are the other two major language groups in Europe. >> There are many other languages that are significantly different from any >> of these - whether they are "notable" is, of course de gustibus. > > True, but all Indo-European languages are at least somewhat related, and > learning one extra is always useful for better understanding the others. Absolutely - but Indo-European is a step up in the language tree. Germanic, Romantic, and Slavic languages are all descendent from earlier common Indo-European languages. (Yes, I know it's not really a tree - more a web of interconnections.) The point is, Latin is a cousin of German - it is not the foundation for it. > Fenno-Ugric and Basque, not so much. (Much as learning Fortran might > help you understand C better, and v.v.; but Prolog or APL, not really.) > Indeed. I seem to remember reading that the path containing Finnish and Hungarian (and Estonian and the Sami languages of Northern Scandinavia and Russia) has vague connections with Mongolian and even Korean. I don't think anyone has figured out where Basque comes from.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-05-10 14:23 +0100 |
| Message-ID | <oev41i$bgn$1@dont-email.me> |
| In reply to | #109662 |
On 10/05/17 13:48, David Brown wrote: <snip> > > Indeed. I seem to remember reading that the path containing Finnish and > Hungarian (and Estonian and the Sami languages of Northern Scandinavia > and Russia) has vague connections with Mongolian and even Korean. I > don't think anyone has figured out where Basque comes from. Thank heaven for search engines. Basque available at Simply Be, J D Williams, and figleaves.com. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web