Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #67120 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-08-11 20:48 +0200 |
| Last post | 2015-08-12 11:13 +0200 |
| Articles | 20 on this page of 231 — 23 participants |
Back to article view | Back to comp.lang.c
C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-11 20:48 +0200
Re: C pointer semantics with dynamically allocated struct Melzzzzz <mel@zzzzz.com> - 2015-08-11 20:59 +0200
Re: C pointer semantics with dynamically allocated struct Melzzzzz <mel@zzzzz.com> - 2015-08-11 21:03 +0200
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-08-11 15:32 -0400
Re: C pointer semantics with dynamically allocated struct jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-11 21:03 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-11 21:47 +0200
Re: C pointer semantics with dynamically allocated struct jt@toerring.de (Jens Thoms Toerring) - 2015-08-11 19:14 +0000
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-11 21:50 +0200
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-08-11 16:12 -0400
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-11 22:45 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 03:08 +0100
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-11 20:24 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-11 21:51 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-11 13:32 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-11 13:36 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-11 22:57 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-11 23:23 +0200
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-11 16:47 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-11 23:46 +0000
Re: C pointer semantics with dynamically allocated struct morphex@gmail.com (Morten W. Petersen) - 2015-08-12 02:05 +0200
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-11 17:16 -0700
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 01:11 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-11 17:35 -0700
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 01:51 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 03:02 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-11 19:50 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-11 20:09 -0700
Music and programming (was: Re: C pointer semantics with dynamically allocated struct) "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 11:54 +0200
Re: Music and programming (was: Re: C pointer semantics with dynamically allocated struct) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 03:35 -0700
Re: Music and programming "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 13:00 +0200
Re: Music and programming Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 11:46 +0100
Re: Music and programming "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 13:06 +0200
Re: Music and programming Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 13:08 +0100
Re: Music and programming raltbos@xs4all.nl (Richard Bos) - 2015-08-12 12:18 +0000
Re: Music and programming "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 14:26 +0200
Re: Music and programming Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 13:36 +0100
Re: Music and programming "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 15:13 +0200
Re: Music and programming David Brown <david.brown@hesbynett.no> - 2015-08-12 16:10 +0200
Re: C pointer semantics with dynamically allocated struct crisdunbar@gmail.com - 2015-08-13 15:47 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 04:52 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 05:01 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 05:10 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-12 09:17 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 02:56 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 04:07 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 03:45 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 12:10 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 11:39 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 13:41 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 04:59 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 14:16 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 06:37 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 15:34 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 08:17 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 08:38 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 17:19 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 09:52 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 22:40 +0100
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-13 13:31 +0200
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-08-14 20:39 -0400
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 13:03 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 14:16 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-09-06 11:19 +0200
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 18:15 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-09-07 09:13 +0200
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-08-12 08:07 -0400
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 14:08 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 10:24 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 20:45 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-13 04:19 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 13:18 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-16 15:43 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-16 21:32 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 12:00 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-17 15:50 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 22:28 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-18 01:34 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-19 08:40 +0200
Re: C pointer semantics with dynamically allocated struct luser droog <luser.droog@gmail.com> - 2015-08-12 13:35 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 15:01 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 11:39 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-09-06 11:24 +0200
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 18:09 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 10:17 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 20:58 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 19:59 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-13 13:47 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 05:35 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-13 15:59 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 07:57 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-13 17:46 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 09:15 -0700
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 17:21 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 09:26 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 19:40 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 11:43 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 21:30 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 14:56 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-14 08:51 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 00:03 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 17:22 +0100
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-14 09:09 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 11:19 +0100
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-14 13:07 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 19:19 +0100
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-08-14 14:32 -0400
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-16 16:52 +0200
Re: C pointer semantics with dynamically allocated struct Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-08-16 18:34 +0000
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-17 07:48 +0200
Re: C pointer semantics with dynamically allocated struct Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-08-18 18:08 +0000
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-19 09:36 +0200
Re: C pointer semantics with dynamically allocated struct David Thompson <dave.thompson2@verizon.net> - 2015-08-30 03:03 -0400
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-30 16:59 +0200
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-30 20:12 +0000
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 14:36 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 12:39 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 07:56 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 17:09 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 11:38 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 20:31 +0100
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 15:17 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-09-06 11:44 +0200
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-08-14 20:56 -0400
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 18:09 -0700
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-08-14 22:26 -0400
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 19:44 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-15 04:15 +0000
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-16 19:00 +0200
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-16 19:00 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-16 20:20 +0200
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-16 17:18 -0700
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-16 23:03 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 00:52 +0200
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-17 00:29 +0100
A simpler version of C (was: Re: C pointer semantics with dynamically allocated struct) "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 02:36 +0200
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 01:47 +0000
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-17 11:27 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 12:40 +0200
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-17 12:07 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 13:36 +0200
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-17 13:14 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 14:09 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-17 05:23 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 14:35 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-17 05:45 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 14:58 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-17 06:23 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 15:30 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-17 06:46 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 15:47 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-17 06:56 -0700
Re: C pointer semantics with dynamically allocated struct fir <profesor.fir@gmail.com> - 2015-08-17 08:57 -0700
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-08-17 15:37 +0100
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-17 15:03 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 15:12 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-17 16:15 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 16:45 +0200
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-17 15:58 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 22:11 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-17 22:24 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 22:31 +0200
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-17 15:04 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 23:41 +0200
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-17 17:58 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-17 14:53 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-17 16:58 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 22:16 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-18 01:31 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-19 08:51 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-19 09:56 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-20 08:52 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-20 10:09 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-20 12:48 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-20 13:00 +0200
Re: C pointer semantics with dynamically allocated struct Ike Naar <ike@iceland.freeshell.org> - 2015-08-20 13:53 +0000
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-20 16:36 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-20 07:39 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-20 09:09 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-20 09:08 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-21 10:15 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-21 02:17 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-21 14:23 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-21 15:44 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-21 14:59 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-21 07:03 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-23 21:50 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-21 16:25 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-21 07:34 -0700
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-21 20:44 +0100
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:10 +0000
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 20:08 +0000
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-17 09:33 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 22:20 +0200
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-08-17 17:28 -0400
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-17 16:42 -0700
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-08-17 19:39 -0400
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-17 16:15 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-18 00:19 +0100
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-08-17 08:32 -0400
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-17 18:02 +0100
Re: C pointer semantics with dynamically allocated struct Rosario19 <Ros@invalid.invalid> - 2015-08-22 08:25 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-17 14:46 +0200
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-17 09:45 -0700
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-17 18:55 +0100
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-17 12:11 -0700
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-17 23:07 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-17 15:13 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 22:56 +0000
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 20:04 +0000
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 14:46 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 07:33 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-13 16:39 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 19:20 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 11:55 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 21:11 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 15:15 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-14 09:29 +0200
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-08-14 08:01 -0400
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-14 14:46 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-16 19:14 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-17 08:01 +0200
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-08-12 23:30 -0400
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 12:45 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-09-05 16:11 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 22:32 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 13:21 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-12 09:22 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-11 19:43 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-11 22:52 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-11 16:01 -0700
Re: C pointer semantics with dynamically allocated struct Rosario19 <Ros@invalid.invalid> - 2015-08-12 11:13 +0200
Page 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-17 13:14 +0100 |
| Message-ID | <mqsj45$67m$1@dont-email.me> |
| In reply to | #67580 |
On 17/08/2015 12:36, Morten W. Petersen wrote: > On 17.08.2015 13:07, Bartc wrote: >> On 17/08/2015 11:40, Morten W. Petersen wrote: > [...] >>> Misplaced commas, semicolons etc. are something that can pop up in code, >>> is it better to learn how to avoid, spot and handle those or be >>> "nannied" with a loop construct that is a bit easier on the eyes? >> >> That is also an odd attitude. So we go out of our way to eliminate a >> construct that makes code easier to read, involves less typing and is >> less error-prone, for what reason exactly? >> >> Because 'real programmers' ought to be able to cope without it? >> >> Maybe we should all give up and start writing assembly code again! > > Hehe. :) > > Yes, well there are assemblers out there that probably are closer > to C than simple Assembly is. > > What I'm thinking is that if someone wants to create a, lets call > it dialect of C, that has a slimmer syntax, then why not? I've created a number of languages that do the same sort of things as C. They are not dialects because they were designed independently and have different syntax anyway. Still, there are a number of features that C has, that I haven't bothered with. A few of them are: * Macros with parameters * 'const' attribute * Assignments such as 'a+=b' within expressions * Function prototypes * Struct tag names * Separate namespaces for typedefs and labels (and apparently other identifiers too) * C's open 'for' statement (mine is a strictly iterative one). * Block scopes * So many operator precedences (I have less than half) There are also many complicated bits of C which are tricky to implement (certainly more so than 'while') and for which I use different approaches (C's convoluted type-specifiers for example, or mixing up variable declarations with function definitions, both of which make it harder to read the code too). To create a slimmed down version of C without all the fiddly bits, and not caring about backwards compatibility, is an admirable aim. But I wouldn't start by getting rid of truly useful (and easy-to-implement) stuff such as while-statements! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 14:09 +0200 |
| Message-ID | <mqsitu$riv$1@speranza.aioe.org> |
| In reply to | #67577 |
On 17.08.2015 13:34, Stefan Ram wrote: > Bartc <bc@freeuk.com> writes: >> That is also an odd attitude. So we go out of our way to eliminate a >> construct that makes code easier to read, involves less typing and is >> less error-prone, for what reason exactly? > > In my C courses, there always is too little time. So, I was > thinking about how to simplify C. I came up with an omission > of »for«, because one already can program all loops with > »while« alone, and »for« is just an abbreviation. > > But soon I observed that, whenever I wanted to show how to > solve an exercise with a loop, I first typed »for«. Then, I > remembered that so far I only had introduced »while« and > edited that »for« to »while«. > > Eventually, I learned that I seem to have a strong > preference for using »for« instead of while in many cases, > so I thought that there must be something about »for« that > appeals to my mind. So, I though that the participiants > might like »for«, too, and that I should re-integrate »for« > into the course. > > However, sometimes there is so little time, that the course > just ends with »while«. But I try to also teach »for«, whenever > this is possible, soon after the introduction of »while«. A while loop is simpler than a for loop, so if one is going for a very simple approach, just having a while loop is the right choice, and maybe it is also the best choice overall as it is simply one test and a segment of regular code. However, as you say, the for loop comes naturally; if that's because the brain thinks that's right or because for is a common way programming is taught I don't know. -Morten
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-17 05:23 -0700 |
| Message-ID | <79d68564-6e2e-447d-a73b-7b19d4e8bc66@googlegroups.com> |
| In reply to | #67582 |
On Monday, August 17, 2015 at 8:09:50 AM UTC-4, Morten W. Petersen wrote: > A while loop is simpler than a for loop, so if one is going > for a very simple approach, just having a while loop is the > right choice, and maybe it is also the best choice overall > as it is simply one test and a segment of regular code. I don't understand your thinking here, Morten. For a compiler, the loops are all basically the same, they are just different in syntax. So internally, you're really only creating one loop, and then applying a few flags you cue from source code syntax to determine how to enter the loop, and exit it. Why would you want to limit a developer's thinking to conform to the way your one loop operated? Why not give them multiple tools and let them think how they need to, and you do the little bit of extra work to setup the flags/cues based on however they do it? Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 14:35 +0200 |
| Message-ID | <mqske6$v37$1@speranza.aioe.org> |
| In reply to | #67584 |
On 17.08.2015 14:23, Rick C. Hodgin wrote: > On Monday, August 17, 2015 at 8:09:50 AM UTC-4, Morten W. Petersen wrote: >> A while loop is simpler than a for loop, so if one is going >> for a very simple approach, just having a while loop is the >> right choice, and maybe it is also the best choice overall >> as it is simply one test and a segment of regular code. > > I don't understand your thinking here, Morten. For a compiler, the > loops are all basically the same, they are just different in syntax. > So internally, you're really only creating one loop, and then applying > a few flags you cue from source code syntax to determine how to enter > the loop, and exit it. > > Why would you want to limit a developer's thinking to conform to the > way your one loop operated? Why not give them multiple tools and let > them think how they need to, and you do the little bit of extra work > to setup the flags/cues based on however they do it? Well, you can construct a for-like loop using while, can't you? Bartc illustrates what I was thinking as well, that one can take a minimalistic approach to a language in the message with message ID <mqsj45$67m$1@dont-email.me>. Macros with parameters for example, why not have a compiler that must support inline? No more complicated macro implementations for compiler writers, no more headaches for developers. The underlying point here is that the simpler a language is, the more time can be spent in other areas, such as how well the compiler optimizes. It will also be less complex so that all other tasks should receive more focus and attention. This way, it would also be easier for developers to take a holistic view of the language/compiler as well, which might bring new results that probably wouldn't have been found in a more complex system. Another cool thing could be that when a function recurses, the function must be tail-call optimizable or the compilation will fail. If the language was a strict subset of C for example, one could at every turn compare the code that a compiler in the new language compiles to for example code that gcc with -O3 creates. That way, one can say and document that it is indeed faster when it does become faster. -Morten
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-17 05:45 -0700 |
| Message-ID | <13a3df55-dfc0-4929-9cb3-20c06657ceb9@googlegroups.com> |
| In reply to | #67586 |
On Monday, August 17, 2015 at 8:35:35 AM UTC-4, Morten W. Petersen wrote: > On 17.08.2015 14:23, Rick C. Hodgin wrote: > > On Monday, August 17, 2015 at 8:09:50 AM UTC-4, Morten W. Petersen wrote: > >> A while loop is simpler than a for loop, so if one is going > >> for a very simple approach, just having a while loop is the > >> right choice, and maybe it is also the best choice overall > >> as it is simply one test and a segment of regular code. > > > > I don't understand your thinking here, Morten. For a compiler, the > > loops are all basically the same, they are just different in syntax. > > So internally, you're really only creating one loop, and then applying > > a few flags you cue from source code syntax to determine how to enter > > the loop, and exit it. > > > > Why would you want to limit a developer's thinking to conform to the > > way your one loop operated? Why not give them multiple tools and let > > them think how they need to, and you do the little bit of extra work > > to setup the flags/cues based on however they do it? > > Well, you can construct a for-like loop using while, can't you? Yes, but I think in for loops. Or I think in while loops. Or I think in do loops. Or I think in other constructs, like until loops, etc. Why impose a barrier on the thousands of user's thinking process when the extra work required for you (as the one-time compiler writer) is minimal? I actually see that thinking as a very selfish endeavor. Rather than give other people the tools they need to thrive, you're going to limit them to that which you pre-determine they need. > Bartc illustrates what I was thinking as well, that one can take a > minimalistic approach to a language in the message with message ID > <mqsj45$67m$1@dont-email.me>. > > Macros with parameters for example, why not have a compiler that > must support inline? No more complicated macro implementations for > compiler writers, no more headaches for developers. Macros aren't complicated. They're mechanical. I would rather have the compiler support features which allow the editor to send it the code and have it expand the macro out to its completed form so that the user can see that either in a popup or window nearby, or have the translated macro actually shown in source code unless some kind of "reveal codes" feature is enabled, which then shows the raw macro before it's translated. I really think you're missing the boat here... You should target people, and not simple designs. Give people what they need to do their work in thought, and not the limits of mechanics available to them. People should not have to alter their thought processes to accommodate design limitations. God made them a particular way, and they think a particular way for a reason. Give them the ability to thrive in their creation, and not hamper them by trying to force them into a one-size-fits-all box that's not a native fit to their creation. > The underlying point here is that the simpler a language is, > the more time can be spent in other areas, such as how well > the compiler optimizes. It will also be less complex so that > all other tasks should receive more focus and attention. This > way, it would also be easier for developers to take a holistic view > of the language/compiler as well, which might bring new results > that probably wouldn't have been found in a more complex system. > > Another cool thing could be that when a function recurses, the > function must be tail-call optimizable or the compilation will > fail. > > If the language was a strict subset of C for example, one could > at every turn compare the code that a compiler in the new language > compiles to for example code that gcc with -O3 creates. That way, > one can say and document that it is indeed faster when it does > become faster. > > -Morten Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 14:58 +0200 |
| Message-ID | <mqsloj$2f8$1@speranza.aioe.org> |
| In reply to | #67587 |
On 17.08.2015 14:45, Rick C. Hodgin wrote: > On Monday, August 17, 2015 at 8:35:35 AM UTC-4, Morten W. Petersen wrote: [...] >> Macros with parameters for example, why not have a compiler that >> must support inline? No more complicated macro implementations for >> compiler writers, no more headaches for developers. > > Macros aren't complicated. They're mechanical. I would rather have > the compiler support features which allow the editor to send it the > code and have it expand the macro out to its completed form so that > the user can see that either in a popup or window nearby, or have > the translated macro actually shown in source code unless some kind > of "reveal codes" feature is enabled, which then shows the raw macro > before it's translated. Or someone could plug in any templating language they desire, if they need to do simple search-and-replace for example. First translate template strings using a separate tool, then compile. > I really think you're missing the boat here... You should target > people, and not simple designs. Give people what they need to do > their work in thought, and not the limits of mechanics available > to them. > > People should not have to alter their thought processes to accommodate > design limitations. God made them a particular way, and they think > a particular way for a reason. Give them the ability to thrive in > their creation, and not hamper them by trying to force them into a > one-size-fits-all box that's not a native fit to their creation. Hm, well lets keep religion out of this, I think going in that direction could take away the point of this discussion. Nobody is forcing anyone to use something, it will be a choice one can make. And choice is good. -Morten
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-17 06:23 -0700 |
| Message-ID | <dce65075-2cf3-4ffb-8dc2-5461e189b08c@googlegroups.com> |
| In reply to | #67589 |
On Monday, August 17, 2015 at 8:58:11 AM UTC-4, Morten W. Petersen wrote:
> On 17.08.2015 14:45, Rick C. Hodgin wrote:
> > I really think you're missing the boat here... You should target
> > people, and not simple designs. Give people what they need to do
> > their work in thought, and not the limits of mechanics available
> > to them.
> >
> > People should not have to alter their thought processes to accommodate
> > design limitations. God made them a particular way, and they think
> > a particular way for a reason. Give them the ability to thrive in
> > their creation, and not hamper them by trying to force them into a
> > one-size-fits-all box that's not a native fit to their creation.
>
> Hm, well lets keep religion out of this, I think going in that
> direction could take away the point of this discussion.
We must begin at fundamentals if we want to build anything that
will last.
http://biblehub.com/psalms/14-1.htm
"To the chief Musician, A Psalm of David. The fool hath said
in his heart, There is no God. They are corrupt, they have
done abominable works, there is none that doeth good."
If you start out by denying God, it is a recipe for disaster, Morten.
And that disaster will accompany you forward, and in all things, even
to your grave and the hereafter.
Look at this and tell me this is the result of random evolutionary
processes:
http://globe-views.com/dcim/dreams/peacock/peacock-01.jpg
http://media1.santabanta.com/full1/Birds/Peacocks/peacocks-5a.jpg
And these ... gorgeous creations made by a creator:
http://www.desibucket.com/db2/01/25529/25529.jpg
http://goodnewsplanet.com/wp-content/uploads/2013/04/creatures_1.jpg
http://goodnewsplanet.com/wp-content/uploads/2013/04/creatures_9.jpg
http://goodnewsplanet.com/wp-content/uploads/2013/04/creatures_12.jpg
http://goodnewsplanet.com/wp-content/uploads/2013/04/creatures_14.jpg
http://goodnewsplanet.com/wp-content/uploads/2013/04/creatures_21.jpg
http://goodnewsplanet.com/wp-content/uploads/2013/04/creatures_24.jpg
http://goodnewsplanet.com/wp-content/uploads/2013/04/creatures_25.jpg
http://goodnewsplanet.com/wp-content/uploads/2013/04/creatures_26.jpg
http://goodnewsplanet.com/wp-content/uploads/2013/04/creatures_27.jpg
... and more
-----
And if you do believe in God, why leave Him out of those things you
would create here in this world, after all He is the creator of all
things (including you)? He is the Master Builder, able to best our
best collective offering as a people, were we to all work with
singular focus and purpose.
> Nobody is forcing anyone to use something, it will be a choice
> one can make. And choice is good.
There are bad choices, Morten. We are living in a world that was
the result of a choice being given, and a bad choice being made.
I wish you well in your endeavors, but I caution you: begin with
God and proceed out from there. It is the only way to assure you
are on the right path, because if you involve God and your heart
is truly purposed on honoring and serving Him with your creation,
He is there with you, and He will personally assure that your path
is the right one, for His own name's sake.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 15:30 +0200 |
| Message-ID | <mqsnlj$70q$1@speranza.aioe.org> |
| In reply to | #67592 |
On 17.08.2015 15:23, Rick C. Hodgin wrote: > On Monday, August 17, 2015 at 8:58:11 AM UTC-4, Morten W. Petersen wrote: >> On 17.08.2015 14:45, Rick C. Hodgin wrote: >>> I really think you're missing the boat here... You should target >>> people, and not simple designs. Give people what they need to do >>> their work in thought, and not the limits of mechanics available >>> to them. >>> >>> People should not have to alter their thought processes to accommodate >>> design limitations. God made them a particular way, and they think >>> a particular way for a reason. Give them the ability to thrive in >>> their creation, and not hamper them by trying to force them into a >>> one-size-fits-all box that's not a native fit to their creation. >> >> Hm, well lets keep religion out of this, I think going in that >> direction could take away the point of this discussion. > > We must begin at fundamentals if we want to build anything that > will last. > > http://biblehub.com/psalms/14-1.htm > "To the chief Musician, A Psalm of David. The fool hath said > in his heart, There is no God. They are corrupt, they have > done abominable works, there is none that doeth good." > > If you start out by denying God, it is a recipe for disaster, Morten. > And that disaster will accompany you forward, and in all things, even > to your grave and the hereafter. If there is something after death, I'll see that when I get there. If there isn't anything, I won't care. I consider myself an agnostic, and seeing how things are I can accept that there is some greater scheme I don't understand. So it would be nice if there is something else, but if it isn't, then that's OK too, even if it is sad and kind of a hell to accept. -Morten
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-17 06:46 -0700 |
| Message-ID | <0b7353df-9b09-457b-8953-04e343b43fd2@googlegroups.com> |
| In reply to | #67593 |
On Monday, August 17, 2015 at 9:30:43 AM UTC-4, Morten W. Petersen wrote: > I consider myself an agnostic, and seeing how things are I can accept > that there is some greater scheme I don't understand. So it would be > nice if there is something else, but if it isn't, then that's OK too, > even if it is sad and kind of a hell to accept. I can tell you that there is an enemy of God, the same one that lied to Adam and Eve in the Garden of Eden, causing them to make the first bad choice, the one which has had ramifications to this planet, and all life therein ever since (including us), at work in this world. That enemy is an enemy of God, and very powerful. He is deceitful and deceptive. He is constantly espousing alternate ideas which, by their very assemblage, removes God from His proper role as creator, and the source of life. If you want to know what there is out there, and remove the doubts or questions you have about who we are, then look to Jesus Christ. We've all heard the tales of how Hell is waiting, and unless we come to accept God He will throw us in there. But it's not like that, and that tale you hear is one that the enemy of God has created, flipping things around in so doing, and casting some negativity on God when there is none there. Because of sin's existence in this world, we have all sinned. And because God is holy He demands a perfect, sinless existence. He has proclaimed that the wages of sin is death, meaning if you sin one time you will die. And for an eternal being that cannot die in the sense we here on Earth understand death, there is only one "death," and that is to be put away in Hell forever where we will not exert any influence on the rest of God's creation. And this is where you can learn about the true nature of God, through learning about Jesus Christ... God demands perfection. None of us are perfect. But God has made a way for us to be made perfect in His sight. By sending Jesus Christ to die on the cross, God made a way to transfer our sins from us to Him. In that way, the demands of His Justice (that the wages of sin is death) are upheld, while we are then freed from sin, made perfect, made spotless by His death, so that we can enter into Heaven, being restored to the purpose God originally had in creation before sin entered in. Jesus gives us eternal life. It's why He came, and it's what His name literally means: "Jesus" means "God who saves [from Judgement, and Hell]." His name means this in the same way the name "Shoemaker" means "one who makes shoes." The enemy would have us look at God as some mean ogre, when in fact we can see God's love expressed through His Son, Jesus. God sent Him here to save those who would believe upon Him, and receive His free gift of eternal life. And all any of us, worldwide, for all people everywhere on the planet, have to do is receive Him, accept His sacrifice and atoning death in our place, and He will give us new life (the "born again" nature Christians talk about). God is not far from any of us. In fact, He stands at the door of our soul and knocks. We need only listen for Him, and then open the door for Him to come in and sup with us, and us with Him. It is only our holding on to sin which prevents us from coming to God. And it is only our holding on to sin which will send our souls to Hell, which is the system God prescribed for those who will not follow He who is Truth (God Himself). I pray this makes sense to you, Morten, and to the other people on this list. There is an enemy of God at work against each of us trying to prevent us from coming to salvation by believing the lie of that enemy, rather than the truth of God. But by putting your sights on seeking the truth, and doing so with a purposeful heart honestly desiring to know the truth, you will find it. You will find Him, and you will come to Him, repent of your sin, ask forgiveness, and be saved. It is available to all people no matter your past. It begins by seeking the truth honestly. And God already knows whether you will do this or not, which is why I'm here writing these words today ... because they will not fall on deaf ears, but they will be heard because that which He speaks in this world is the power of God, and it is the power unto life eternal through salvation by His Son, Jesus. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 15:47 +0200 |
| Message-ID | <mqsols$966$1@speranza.aioe.org> |
| In reply to | #67594 |
On 17.08.2015 15:46, Rick C. Hodgin wrote: [...] FYI I won't reply to any more of this. -Morten
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-17 06:56 -0700 |
| Message-ID | <7f4f9cc6-6f57-4c30-a8e6-a4282dc81dd3@googlegroups.com> |
| In reply to | #67595 |
On Monday, August 17, 2015 at 9:47:54 AM UTC-4, Morten W. Petersen wrote: > On 17.08.2015 15:46, Rick C. Hodgin wrote: > [...] > > FYI I won't reply to any more of this. You don't have to respond. But I do advise you to read it. You will find answers to the questions you have if you pursue what I'm talking about, and all of the doubts you have about who we are, why are we here, what it all means, will be removed. The spirit of God is the spirit of Power, and of Love, and of a sound mind. When His Holy Spirit is sought, and our will aligns with His will (which is what the Holy Spirit guides our thinking and life toward), then there are no limits, Morten. The enemy of God would have you believe otherwise, but that enemy is a fallen foe, defeated completely by the death of Jesus Christ at the cross, and His resurrection from the grave. He no longer holds any power over death, and his only weapon is to deceive us into believing the lie so that we will not come to Jesus, we will not ask forgiveness, and we will not be saved. That enemy has come to kill, steal, and destroy. But it is God who is life, and seeks to prosper, empower, thrive, and uphold His creation, which is why His offer of salvation is extended to all people everywhere, no matter your past, no matter your sin, no matter your former beliefs. All will be forgiven if you will call upon His name. Take care, Morten. A new life upon this Earth awaits you ... if you'll receive it. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-08-17 08:57 -0700 |
| Message-ID | <0ef525a0-cf29-4006-bd0c-5dff3d117d15@googlegroups.com> |
| In reply to | #67596 |
W dniu poniedziałek, 17 sierpnia 2015 15:56:55 UTC+2 użytkownik Rick C. Hodgin napisał: > On Monday, August 17, 2015 at 9:47:54 AM UTC-4, Morten W. Petersen wrote: > > On 17.08.2015 15:46, Rick C. Hodgin wrote: > > [...] > > > > FYI I won't reply to any more of this. > > You don't have to respond. But I do advise you to read it. You will > find answers to the questions you have if you pursue what I'm talking > about, and all of the doubts you have about who we are, why are we > here, what it all means, will be removed. > > The spirit of God is the spirit of Power, and of Love, and of a sound > mind. When His Holy Spirit is sought, and our will aligns with His > will (which is what the Holy Spirit guides our thinking and life > toward), then there are no limits, Morten. > > The enemy of God would have you believe otherwise, but that enemy is > a fallen foe, defeated completely by the death of Jesus Christ at the > cross, and His resurrection from the grave. He no longer holds any > power over death, and his only weapon is to deceive us into believing > the lie so that we will not come to Jesus, we will not ask forgiveness, > and we will not be saved. > > That enemy has come to kill, steal, and destroy. But it is God who is > life, and seeks to prosper, empower, thrive, and uphold His creation, > which is why His offer of salvation is extended to all people everywhere, > no matter your past, no matter your sin, no matter your former beliefs. > All will be forgiven if you will call upon His name. > > Take care, Morten. A new life upon this Earth awaits you ... if you'll > receive it. > every man has a choice to go towards intelligence which is somewhat related to deepnes and complexity of thought, or to simpletonism and shallownes of thought (like common troll insulters) in reality intelligence is somewhat coupled with 'goodnnes' - the nature of this coupling is not fully clear to me but i must say that morality usually drove up my intelligence more than anything
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-08-17 15:37 +0100 |
| Message-ID | <skmAx.162208$7R2.5353@fx03.am4> |
| In reply to | #67595 |
On 17/08/2015 14:47, Morten W. Petersen wrote: > On 17.08.2015 15:46, Rick C. Hodgin wrote: > [...] > > FYI I won't reply to any more of this. Thank you. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-17 15:03 +0200 |
| Message-ID | <mqsm0i$hfs$1@dont-email.me> |
| In reply to | #67586 |
On 17/08/15 14:35, Morten W. Petersen wrote: > On 17.08.2015 14:23, Rick C. Hodgin wrote: >> On Monday, August 17, 2015 at 8:09:50 AM UTC-4, Morten W. Petersen wrote: >>> A while loop is simpler than a for loop, so if one is going >>> for a very simple approach, just having a while loop is the >>> right choice, and maybe it is also the best choice overall >>> as it is simply one test and a segment of regular code. >> >> I don't understand your thinking here, Morten. For a compiler, the >> loops are all basically the same, they are just different in syntax. >> So internally, you're really only creating one loop, and then applying >> a few flags you cue from source code syntax to determine how to enter >> the loop, and exit it. >> >> Why would you want to limit a developer's thinking to conform to the >> way your one loop operated? Why not give them multiple tools and let >> them think how they need to, and you do the little bit of extra work >> to setup the flags/cues based on however they do it? > > Well, you can construct a for-like loop using while, can't you? > Yes, but sometimes a "while" loop is simpler and clearer than the corresponding "for" loop, and vice versa. When you are picking features for a language (whether you are designing a language, writing compiler extensions, teaching a language, or merely using it), you want a balance between having enough features to clearly express what you want to say, without having so many features that it is hard to learn everything. Thus C has a "+" operator, even though it is unnecessary - you can use "- -" in most circumstances. But it does not have an operator for calculating integer powers, even though it might occasionally be useful. And thus C has "while" loops and "for" loops, but not "until" loops or "repeat" loops. > Bartc illustrates what I was thinking as well, that one can take a > minimalistic approach to a language in the message with message ID > <mqsj45$67m$1@dont-email.me>. > > Macros with parameters for example, why not have a compiler that > must support inline? No more complicated macro implementations for > compiler writers, no more headaches for developers. Compilers that support C99 or above /must/ support the inline directive (though they don't have to actually inline the code). And so programmers can often use inline functions rather than function-like macros because they are clearer, safer, and lead to more useful warnings and error messages when mistakes are made. And programmers still have function-like macros for cases where they can't use inline functions. Again, these are two related tools with their pros and cons, that can sometimes be substituted for each other - but the language is better when both are available. > > The underlying point here is that the simpler a language is, > the more time can be spent in other areas, such as how well > the compiler optimizes. As someone pointed out, who cares how difficult the task is for the compiler? It is the /programmer/, the /user/, that is in focus. And as someone else pointed out, these issues are peanuts to the compiler anyway, and pretty much negligible in the grand picture of compiler development. Making a language /reasonably/ simple is a good goal - making it too simple is not. It is a balance. (And that balance varies according to language, and according to the needs and uses of the language.) > It will also be less complex so that > all other tasks should receive more focus and attention. This > way, it would also be easier for developers to take a holistic view > of the language/compiler as well, which might bring new results > that probably wouldn't have been found in a more complex system. So we should all be using something like a Turing machine that is optimised to run /really/ fast? That is where your argument ends up. > > Another cool thing could be that when a function recurses, the > function must be tail-call optimizable or the compilation will > fail. Why would that be "cool"? Arbitrarily restricting the programmer, and forcing ugly and error prone alternatives to naturally recursive tasks (such as many tree and graph algorithms) is not "cool". > > If the language was a strict subset of C for example, one could > at every turn compare the code that a compiler in the new language > compiles to for example code that gcc with -O3 creates. That way, > one can say and document that it is indeed faster when it does > become faster. > There is absolutely /no/ reason to suppose that a compiler would generate faster code by removing these features. C (and C++) have always made a point that features, and especially new features, should be as close to zero overhead as possible - i.e., the existence of a feature should not affect the efficiency of code that does not use the feature. Thus when C99 introduced "inline", there was no added cost for programs that did not use it. Removing features does not make the code, or compilers, faster or simpler.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 15:12 +0200 |
| Message-ID | <mqsmjf$4g3$1@speranza.aioe.org> |
| In reply to | #67590 |
On 17.08.2015 15:03, David Brown wrote: > On 17/08/15 14:35, Morten W. Petersen wrote: [...] >> Well, you can construct a for-like loop using while, can't you? >> > > Yes, but sometimes a "while" loop is simpler and clearer than the > corresponding "for" loop, and vice versa. > > When you are picking features for a language (whether you are designing > a language, writing compiler extensions, teaching a language, or merely > using it), you want a balance between having enough features to clearly > express what you want to say, without having so many features that it is > hard to learn everything. > > Thus C has a "+" operator, even though it is unnecessary - you can use > "- -" in most circumstances. But it does not have an operator for > calculating integer powers, even though it might occasionally be useful. > > And thus C has "while" loops and "for" loops, but not "until" loops or > "repeat" loops. Yes, and these are choices that were made a long, long time ago, when our galaxy was in a very different place than what it is now. >> Bartc illustrates what I was thinking as well, that one can take a >> minimalistic approach to a language in the message with message ID >> <mqsj45$67m$1@dont-email.me>. >> >> Macros with parameters for example, why not have a compiler that >> must support inline? No more complicated macro implementations for >> compiler writers, no more headaches for developers. > > Compilers that support C99 or above /must/ support the inline directive > (though they don't have to actually inline the code). And so > programmers can often use inline functions rather than function-like > macros because they are clearer, safer, and lead to more useful warnings > and error messages when mistakes are made. And programmers still have > function-like macros for cases where they can't use inline functions. > > Again, these are two related tools with their pros and cons, that can > sometimes be substituted for each other - but the language is better > when both are available. Your opinion is that the language is better. Probably because you know it well and are accustomed to it. >> The underlying point here is that the simpler a language is, >> the more time can be spent in other areas, such as how well >> the compiler optimizes. > > As someone pointed out, who cares how difficult the task is for the > compiler? It is the /programmer/, the /user/, that is in focus. And as > someone else pointed out, these issues are peanuts to the compiler > anyway, and pretty much negligible in the grand picture of compiler > development. > > Making a language /reasonably/ simple is a good goal - making it too > simple is not. It is a balance. (And that balance varies according to > language, and according to the needs and uses of the language.) It depends on what one is going for. There is an operating system with a browser and everything that has been written in Assembly. >> It will also be less complex so that >> all other tasks should receive more focus and attention. This >> way, it would also be easier for developers to take a holistic view >> of the language/compiler as well, which might bring new results >> that probably wouldn't have been found in a more complex system. > > So we should all be using something like a Turing machine that is > optimised to run /really/ fast? That is where your argument ends up. Well it's not going to be Assembly, which is the fastest one can make a program go without using JIT etc. I think that was obvious from what has been said earlier in this thread. -Morten
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-17 16:15 +0200 |
| Message-ID | <mqsq70$25n$1@dont-email.me> |
| In reply to | #67591 |
On 17/08/15 15:12, Morten W. Petersen wrote:
> On 17.08.2015 15:03, David Brown wrote:
>> On 17/08/15 14:35, Morten W. Petersen wrote:
> [...]
>>> Well, you can construct a for-like loop using while, can't you?
>>>
>>
>> Yes, but sometimes a "while" loop is simpler and clearer than the
>> corresponding "for" loop, and vice versa.
>>
>> When you are picking features for a language (whether you are designing
>> a language, writing compiler extensions, teaching a language, or merely
>> using it), you want a balance between having enough features to clearly
>> express what you want to say, without having so many features that it is
>> hard to learn everything.
>>
>> Thus C has a "+" operator, even though it is unnecessary - you can use
>> "- -" in most circumstances. But it does not have an operator for
>> calculating integer powers, even though it might occasionally be useful.
>>
>> And thus C has "while" loops and "for" loops, but not "until" loops or
>> "repeat" loops.
>
> Yes, and these are choices that were made a long, long time ago, when
> our galaxy was in a very different place than what it is now.
Our galaxy is not /that/ different from when C started out. Some things
have changed, others have not. And for imperative programming, it is
common to need a few sorts of loops - loop until something happens, loop
while something is true, and enumerate over a range.
The first two are "while" loops in C - "do {} while (!x)" and "while (x)
{ }", and the third type is expressed most clearly with "for". This is
common practice on a range of imperative programming languages, with
some degree of variation (some languages have "repeat ... until ()", and
it's arguably a matter of taste whether such loops should have positive
or negative logic on the condition).
The "for" loop is a common construct in imperative languages - again,
with variations. It is typically used to iterate over a range or over a
structure.
Just because these choices were made a long time ago, does not mean that
they are bad - or that anything better is available to replace them. If
you were designing a new imperative language from scratch, you might
make slightly different choices - such as "repeat/until" - but the
principle would probably remain the same. (And you would probably
remove some of the messy possibilities that C's for construction
provides.) Your aim is to make it convenient for the programmer to
write simple and clear code.
(There are, of course, other ways to structure repetition - recursion,
list comprehension, etc.)
>
>>> Bartc illustrates what I was thinking as well, that one can take a
>>> minimalistic approach to a language in the message with message ID
>>> <mqsj45$67m$1@dont-email.me>.
>>>
>>> Macros with parameters for example, why not have a compiler that
>>> must support inline? No more complicated macro implementations for
>>> compiler writers, no more headaches for developers.
>>
>> Compilers that support C99 or above /must/ support the inline directive
>> (though they don't have to actually inline the code). And so
>> programmers can often use inline functions rather than function-like
>> macros because they are clearer, safer, and lead to more useful warnings
>> and error messages when mistakes are made. And programmers still have
>> function-like macros for cases where they can't use inline functions.
>>
>> Again, these are two related tools with their pros and cons, that can
>> sometimes be substituted for each other - but the language is better
>> when both are available.
>
> Your opinion is that the language is better. Probably because you
> know it well and are accustomed to it.
First, it should be obvious that there are things that can be done with
parametrised macros that cannot be done using inline functions. (They
could obviously be handled by a different pre-processor than C's
standard pre-processor, and C++'s templates, overloading, constexpr,
etc., can cover a much wider range than plain inline C functions. But
we are looking at C here.)
Secondly, it should be equally obvious that - as long as you are using
C99 or above, and have a half-decent compiler - "static inline"
functions are often clearer than function-like macros, and are easier to
write in a safe manner (i.e., lower chance of errors, and higher chance
of errors being spotted helpfully by tools). And they are just as
efficient in object code.
Arguably a "perfect" compiler could handle all the inlining decisions
automatically, and there would be no need for "inline". But perfect
compilers are hard to come by.
So yes, my opinion is that the language is better for having both inline
functions and macros.
>
>>> The underlying point here is that the simpler a language is,
>>> the more time can be spent in other areas, such as how well
>>> the compiler optimizes.
>>
>> As someone pointed out, who cares how difficult the task is for the
>> compiler? It is the /programmer/, the /user/, that is in focus. And as
>> someone else pointed out, these issues are peanuts to the compiler
>> anyway, and pretty much negligible in the grand picture of compiler
>> development.
>>
>> Making a language /reasonably/ simple is a good goal - making it too
>> simple is not. It is a balance. (And that balance varies according to
>> language, and according to the needs and uses of the language.)
>
> It depends on what one is going for. There is an operating system
> with a browser and everything that has been written in Assembly.
And how many users does it have?
Of course there is a need for a wide range of different programming
languages - and conversely, one can write a wide range of software in
any particular language one chooses.
But that does not mean that any given language design decision is a good
one for some usage! There are plenty of esoteric and bizarre
programming languages in existence, with particular emphases such as a
minimal set of features or expressions. And there are good reasons why
these are for fun or theoretic interest only.
>
>>> It will also be less complex so that
>>> all other tasks should receive more focus and attention. This
>>> way, it would also be easier for developers to take a holistic view
>>> of the language/compiler as well, which might bring new results
>>> that probably wouldn't have been found in a more complex system.
>>
>> So we should all be using something like a Turing machine that is
>> optimised to run /really/ fast? That is where your argument ends up.
>
> Well it's not going to be Assembly, which is the fastest one can
> make a program go without using JIT etc. I think that was obvious
> from what has been said earlier in this thread.
>
Certainly assembly (on bigger processors, at least) is seldom a simple
language to work with.
Personally, I cannot see any benefit in a low-level language that is
somehow "smaller" than C. There are (AFAIK) no features in C that add
cost, so generated code would not be smaller and faster by removing
features of C. On the contrary, there could easily be features /added/
to C to allow better exploitation of hardware.
Of course this does not mean that I think all the design decisions of C
were good. If I were making a C-like language, I would make some
changes - such as greater restrictions on the underlying hardware and
data representation (as a better fit to the hardware of today), and
omitting features that have a reputation for leading to obscure or
error-prone code (such as the use of assignments as expressions).
But I would keep "for" and "while" loops !
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 16:45 +0200 |
| Message-ID | <mqss16$h9c$1@speranza.aioe.org> |
| In reply to | #67597 |
On 17.08.2015 16:15, David Brown wrote: > On 17/08/15 15:12, Morten W. Petersen wrote: [...] >> Your opinion is that the language is better. Probably because you >> know it well and are accustomed to it. > > First, it should be obvious that there are things that can be done with > parametrised macros that cannot be done using inline functions. (They > could obviously be handled by a different pre-processor than C's > standard pre-processor, and C++'s templates, overloading, constexpr, > etc., can cover a much wider range than plain inline C functions. But > we are looking at C here.) > > Secondly, it should be equally obvious that - as long as you are using > C99 or above, and have a half-decent compiler - "static inline" > functions are often clearer than function-like macros, and are easier to > write in a safe manner (i.e., lower chance of errors, and higher chance > of errors being spotted helpfully by tools). And they are just as > efficient in object code. > > Arguably a "perfect" compiler could handle all the inlining decisions > automatically, and there would be no need for "inline". But perfect > compilers are hard to come by. > > > So yes, my opinion is that the language is better for having both inline > functions and macros. Is there something in C that can't be done using for example a configure() function call with other function calls before main? [...] >> It depends on what one is going for. There is an operating system >> with a browser and everything that has been written in Assembly. > > And how many users does it have? I don't know. A 1.0 version was released this year. > Of course there is a need for a wide range of different programming > languages - and conversely, one can write a wide range of software in > any particular language one chooses. > > But that does not mean that any given language design decision is a good > one for some usage! There are plenty of esoteric and bizarre > programming languages in existence, with particular emphases such as a > minimal set of features or expressions. And there are good reasons why > these are for fun or theoretic interest only. Yes, yes, did you read something that didn't agree with this? [...] >> Well it's not going to be Assembly, which is the fastest one can >> make a program go without using JIT etc. I think that was obvious >> from what has been said earlier in this thread. >> > > Certainly assembly (on bigger processors, at least) is seldom a simple > language to work with. > > Personally, I cannot see any benefit in a low-level language that is > somehow "smaller" than C. There are (AFAIK) no features in C that add > cost, so generated code would not be smaller and faster by removing > features of C. On the contrary, there could easily be features /added/ > to C to allow better exploitation of hardware. > > Of course this does not mean that I think all the design decisions of C > were good. If I were making a C-like language, I would make some > changes - such as greater restrictions on the underlying hardware and > data representation (as a better fit to the hardware of today), and > omitting features that have a reputation for leading to obscure or > error-prone code (such as the use of assignments as expressions). > > But I would keep "for" and "while" loops ! Learning curve is one thing. The size of the code base of the compiler is another. Your ideal language would have for and while yes, which seems like a softer compromise than for example a variant that is supposed to be slim. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-17 15:58 +0100 |
| Message-ID | <mqssnb$cmf$1@dont-email.me> |
| In reply to | #67599 |
On 17/08/2015 15:45, Morten W. Petersen wrote: > On 17.08.2015 16:15, David Brown wrote: >> But I would keep "for" and "while" loops ! > > Learning curve is one thing. The size of the code base of the compiler > is another. If necessary 'while' can be added like this: #define While(cond) for (;(cond);) One line of code in a standard header. Your argument that it bloats the code-base doesn't stack up! > Your ideal language would have for and while yes, which seems like a > softer compromise than for example a variant that is supposed to be > slim. There are some language constructs that are near universal and that everyone will understand. 'while' is one of them. 'for' not quite so much, especially C's version where 'for(;cond;)' might be puzzling to many. And if it's not puzzling, it's ugly. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 22:11 +0200 |
| Message-ID | <mqtf4j$uek$1@speranza.aioe.org> |
| In reply to | #67601 |
On 17.08.2015 16:58, Bartc wrote: > On 17/08/2015 15:45, Morten W. Petersen wrote: >> On 17.08.2015 16:15, David Brown wrote: > >>> But I would keep "for" and "while" loops ! >> >> Learning curve is one thing. The size of the code base of the compiler >> is another. > > If necessary 'while' can be added like this: > > #define While(cond) for (;(cond);) > > One line of code in a standard header. > > Your argument that it bloats the code-base doesn't stack up! > >> Your ideal language would have for and while yes, which seems like a >> softer compromise than for example a variant that is supposed to be >> slim. > > There are some language constructs that are near universal and that > everyone will understand. 'while' is one of them. > > 'for' not quite so much, especially C's version where 'for(;cond;)' > might be puzzling to many. And if it's not puzzling, it's ugly. OK. Well while looks like a good candidate for the looping then, as a for-like loop can be built with it. The while loop simply jumps back and forth and checks one condition, the rest can be treated and optimized like regular code. -Morten
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-17 22:24 +0200 |
| Message-ID | <mqtfq0$1k2$1@dont-email.me> |
| In reply to | #67622 |
On 17/08/15 22:11, Morten W. Petersen wrote:
> On 17.08.2015 16:58, Bartc wrote:
>> On 17/08/2015 15:45, Morten W. Petersen wrote:
>>> On 17.08.2015 16:15, David Brown wrote:
>>
>>>> But I would keep "for" and "while" loops !
>>>
>>> Learning curve is one thing. The size of the code base of the compiler
>>> is another.
>>
>> If necessary 'while' can be added like this:
>>
>> #define While(cond) for (;(cond);)
>>
>> One line of code in a standard header.
>>
>> Your argument that it bloats the code-base doesn't stack up!
>>
>>> Your ideal language would have for and while yes, which seems like a
>>> softer compromise than for example a variant that is supposed to be
>>> slim.
>>
>> There are some language constructs that are near universal and that
>> everyone will understand. 'while' is one of them.
>>
>> 'for' not quite so much, especially C's version where 'for(;cond;)'
>> might be puzzling to many. And if it's not puzzling, it's ugly.
>
> OK. Well while looks like a good candidate for the looping
> then, as a for-like loop can be built with it.
>
> The while loop simply jumps back and forth and checks one
> condition, the rest can be treated and optimized like
> regular code.
>
I agree with Bart that C allows "for" loops that are ugly, can be
puzzling or unclear, and can easily have hard-to-spot errors. "for
(;(cond);)" is an example.
But most "for" loops are simple counters:
for (i = 0; i < 10; i++) { ... }
That's clear and simple, and not significantly different from the for
loops found in most imperative languages.
Changing that to:
i = 0;
while (i < 10) {
...
i++;
}
does not make the program clearer or neater, it does not reduce the risk
of errors or misunderstanding, it does not make the code faster, and it
does not make the compiler simpler, clearer or faster. It gives no
benefits whatsoever - except to reduce the language by a single keyword,
and help those poor souls that get paid per Kloc.
[toc] | [prev] | [next] | [standalone]
Page 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web