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 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-05 15:17 -0700 |
| Message-ID | <kfn7fo4v7d1.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #67358 |
David Brown <david.brown@hesbynett.no> writes:
> On 13/08/15 18:22, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>[snip]
>
> In particular, if you use an idiom yourself in your own code, and only
> you work with it (or you inform others of its meanings), then it is a
> matter of style even if makes no sense to everyone else. Clarity, and
> the meaning of code, is somewhat in the eye of the beholder, and a
> matter of style. (There are some regulars in this group that post code
> that appears as line noise to most of us, yet the authors think they
> have a good and clear style.) Of course it is usually best to have a
> style that is clear and understandable to as wide an audience as
> possible. [snip]
It strikes me that you are using "clear" here in a sense that
has some overtones of "familiar". For example, a line of code
like
x = 0, y = 0;
is just as clear (to someone who knows C) as the two lines
x = 0;
y = 0;
but someone might prefer the latter because it is more familiar.
Do you have any comments on this reaction?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-06 11:44 +0200 |
| Message-ID | <msh1qt$o50$1@dont-email.me> |
| In reply to | #69548 |
On 06/09/15 00:17, Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 13/08/15 18:22, Ben Bacarisse wrote: >>> David Brown <david.brown@hesbynett.no> writes: >> [snip] >> >> In particular, if you use an idiom yourself in your own code, and only >> you work with it (or you inform others of its meanings), then it is a >> matter of style even if makes no sense to everyone else. Clarity, and >> the meaning of code, is somewhat in the eye of the beholder, and a >> matter of style. (There are some regulars in this group that post code >> that appears as line noise to most of us, yet the authors think they >> have a good and clear style.) Of course it is usually best to have a >> style that is clear and understandable to as wide an audience as >> possible. [snip] > > It strikes me that you are using "clear" here in a sense that > has some overtones of "familiar". I thought it was pretty clear in my post that clarity follows closely from familiarity :-) > For example, a line of code like > > x = 0, y = 0; > > is just as clear (to someone who knows C) as the two lines > > x = 0; > y = 0; > > but someone might prefer the latter because it is more familiar. No, I would say that someone who sees "x = 0;\n y = 0;" as more familiar than "x = 0, y = 0;", would also see the former as clearer. I also take issue with your assumption that "x = 0, y = 0;" is clear at all, even to someone who is experienced with C. Many C programmers work to particular coding standards, especially if they are involved in secure programming or embedded programming. The expression "x = 0, y = 0;" breaks a number of common rules (making two assignments on one line, using the comma operator, relying on operator precedence) - as such, it simply has no place in secure or embedded programming and will thus be unfamiliar and unclear. > Do you have any comments on this reaction? >
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-08-14 20:56 -0400 |
| Message-ID | <D6wzx.1885$K21.782@fx18.iad> |
| In reply to | #67279 |
On 8/13/15 8:35 AM, Rick C. Hodgin wrote: > > These "hacks" as Ben calls them work correctly in Windows, Linux, and on > Microsoft's compilers and GCC for x86 and ARM, and I bet they work on > many other systems, most other systems even, and on many other hardware > forms. They don't work on all of them, and therein lies the issue I take > with that reality existing in the C /standard/. I believe that C should > account for those peculiar hardware forms, but they should be extensions, > and not part of the standard, because the standard should relate more > closely to physical hardware in its current semiconductor form, which is > the form which has existed since at least the 1980s in 32-bit form, and > back to the early 70s in 4-bit and larger forms. > > Best regards, > Rick C. Hodgin > And this is where you have the fundamental problem. Extension can NOT change the behavior of a valid program, it must still work according to the standard, therefore if the standard says all pointers are the same size, and extension can not say that they suddenly are not, as then the extension breaks valid programs. Thus, the base standard defines how the language works on ALL possible machines, and then extensions can add promises for particular systems, and machines that can make those promises won't have that extension. There is nothing wrong with deciding that you are only going to write you programs for systems that conform to a given extension, and if that extension has gone through a standardization process, you can even say you have programed to a standard, it just is Standard Extension-C not Standard C (unless of course you have agreed with a customer to provide a Standard C solution, but most programs need SOME extension or implementation defined behavior to do useful work). I will also point out that you seem to have blinders on as to the type of machines out there. There are STILL active processors that don't meet all your requirements for 'your standard' and in the 70s and 80s (which you mention) they were even somewhat common. (Except of course to someone who all the world was a PC).
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-14 18:09 -0700 |
| Message-ID | <d57927ae-20ac-4ad4-b82b-b232c745e0c9@googlegroups.com> |
| In reply to | #67440 |
On Friday, August 14, 2015 at 8:56:14 PM UTC-4, Richard Damon wrote: > On 8/13/15 8:35 AM, Rick C. Hodgin wrote: > > These "hacks" as Ben calls them work correctly in Windows, Linux, and on > > Microsoft's compilers and GCC for x86 and ARM, and I bet they work on > > many other systems, most other systems even, and on many other hardware > > forms. They don't work on all of them, and therein lies the issue I take > > with that reality existing in the C /standard/. I believe that C should > > account for those peculiar hardware forms, but they should be extensions, > > and not part of the standard, because the standard should relate more > > closely to physical hardware in its current semiconductor form, which is > > the form which has existed since at least the 1980s in 32-bit form, and > > back to the early 70s in 4-bit and larger forms. > > And this is where you have the fundamental problem. Extension can NOT > change the behavior of a valid program, it must still work according to > the standard, therefore if the standard says all pointers are the same > size, and extension can not say that they suddenly are not, as then the > extension breaks valid programs. My whole argument is and has been that the standard needs to change. > Thus, the base standard defines how the language works on ALL possible > machines, and then extensions can add promises for particular systems, > and machines that can make those promises won't have that extension. > > There is nothing wrong with deciding that you are only going to write > you programs for systems that conform to a given extension, and if that > extension has gone through a standardization process, you can even say > you have programed to a standard, it just is Standard Extension-C not > Standard C (unless of course you have agreed with a customer to provide > a Standard C solution, but most programs need SOME extension or > implementation defined behavior to do useful work). > > I will also point out that you seem to have blinders on as to the type > of machines out there. There are STILL active processors that don't meet > all your requirements for 'your standard' and in the 70s and 80s (which > you mention) they were even somewhat common. (Except of course to > someone who all the world was a PC). Not blinders, just focus. The C standard as it is today exists. There's no reason it has to be deleted from the world. But, in moving forward, the standard should speak to core architecture as standard, and atypical architecture as extensions. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-08-14 22:26 -0400 |
| Message-ID | <Trxzx.34$KQ.31@fx03.iad> |
| In reply to | #67441 |
On 8/14/15 9:09 PM, Rick C. Hodgin wrote: > On Friday, August 14, 2015 at 8:56:14 PM UTC-4, Richard Damon wrote: >> And this is where you have the fundamental problem. Extension can NOT >> change the behavior of a valid program, it must still work according to >> the standard, therefore if the standard says all pointers are the same >> size, and extension can not say that they suddenly are not, as then the >> extension breaks valid programs. > > My whole argument is and has been that the standard needs to change. > >> Thus, the base standard defines how the language works on ALL possible >> machines, and then extensions can add promises for particular systems, >> and machines that can make those promises won't have that extension. >> >> There is nothing wrong with deciding that you are only going to write >> you programs for systems that conform to a given extension, and if that >> extension has gone through a standardization process, you can even say >> you have programed to a standard, it just is Standard Extension-C not >> Standard C (unless of course you have agreed with a customer to provide >> a Standard C solution, but most programs need SOME extension or >> implementation defined behavior to do useful work). >> >> I will also point out that you seem to have blinders on as to the type >> of machines out there. There are STILL active processors that don't meet >> all your requirements for 'your standard' and in the 70s and 80s (which >> you mention) they were even somewhat common. (Except of course to >> someone who all the world was a PC). > > Not blinders, just focus. The C standard as it is today exists. There's > no reason it has to be deleted from the world. But, in moving forward, > the standard should speak to core architecture as standard, and atypical > architecture as extensions. > > Best regards, > Rick C. Hodgin > And this is where you have your fundamental flaw, and don't understand how standards work (Not just the C standard, but standards in general). An extension to a language should not take a working program and break it. An extension lets the PROGRAMMER do additional things in his program, not give the implementation Your concept of "Core C" makes a perfect extension to C, it add constraints to the implementation and allows the programmer to make more assumptions. Your concept for an "atypical architecture extension" fails the basic test of an extension.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-14 19:44 -0700 |
| Message-ID | <e6608a24-899b-443f-8515-d19fd2c0030e@googlegroups.com> |
| In reply to | #67442 |
On Friday, August 14, 2015 at 10:27:19 PM UTC-4, Richard Damon wrote: > On 8/14/15 9:09 PM, Rick C. Hodgin wrote: > > On Friday, August 14, 2015 at 8:56:14 PM UTC-4, Richard Damon wrote: > > >> And this is where you have the fundamental problem. Extension can NOT > >> change the behavior of a valid program, it must still work according to > >> the standard, therefore if the standard says all pointers are the same > >> size, and extension can not say that they suddenly are not, as then the > >> extension breaks valid programs. > > > > My whole argument is and has been that the standard needs to change. > > > >> Thus, the base standard defines how the language works on ALL possible > >> machines, and then extensions can add promises for particular systems, > >> and machines that can make those promises won't have that extension. > >> > >> There is nothing wrong with deciding that you are only going to write > >> you programs for systems that conform to a given extension, and if that > >> extension has gone through a standardization process, you can even say > >> you have programed to a standard, it just is Standard Extension-C not > >> Standard C (unless of course you have agreed with a customer to provide > >> a Standard C solution, but most programs need SOME extension or > >> implementation defined behavior to do useful work). > >> > >> I will also point out that you seem to have blinders on as to the type > >> of machines out there. There are STILL active processors that don't meet > >> all your requirements for 'your standard' and in the 70s and 80s (which > >> you mention) they were even somewhat common. (Except of course to > >> someone who all the world was a PC). > > > > Not blinders, just focus. The C standard as it is today exists. There's > > no reason it has to be deleted from the world. But, in moving forward, > > the standard should speak to core architecture as standard, and atypical > > architecture as extensions. > > > > Best regards, > > Rick C. Hodgin > > > > And this is where you have your fundamental flaw, and don't understand > how standards work (Not just the C standard, but standards in general). > An extension to a language should not take a working program and break > it. An extension lets the PROGRAMMER do additional things in his > program, not give the implementation I do recognize that, Richard. It's why I wrote, "The C standard as it is today exists. There's no reason it has to be deleted from the world." My point there is that everything that works today, written for the standard, can continue to operate as the standard as it exists today dictated. However, the new standard that would be created would change things, and new code written (or legacy code altered) for that standard would no longer operate as the prior code has. > Your concept of "Core C" makes a perfect extension to C, it add > constraints to the implementation and allows the programmer to make more > assumptions. Your concept for an "atypical architecture extension" fails > the basic test of an extension. I, of course, disagree. My proposal for Core C is a revamp, removing many of the things which the C standard today define, making the Core C definition much smaller. And then, beyond that small core that is much easier to understand, write a compiler for, etc., come the extensions, which are only enabled on those platforms and architectures which would require them. I look at things this way "Core C ----> Extensions ----> Universe". You and Ben look at things this way "Universe ----> Constraints ----> Core C". I view your view as exactly backwards. It mandates a greater amount of reading, knowledge, understanding from the get-go. It requires that a person know everything about the Universe that's allowed, and then on top of that know also what the constraints are which then redefine that Universe down to something smaller. My view starts with the smaller subset, less reading, less knowledge, less understanding from the get-go. It then requires that those who want to go into some obtuse architecture with traits which are defined as extensions outside of the standard, to then, and only then, learn those peculiarities. I honestly don't understand in the slightest how it is you and Ben look at things the way you do. I have no thought processes which operate as you indicate, and I would never advocate thought processes which go that way. In all areas of our life we start out with the broad strokes first, and then when we need to, or want to, and only then, do we then go deeper into the details. Many people are familiar with what calculus is. Not many people can integrate trigonometric functions. They understand the lesser amount of knowledge on the outside, and only those who have a need go deeper. Most people know that you must prepare and cook food before you eat it. And many people can follow directions and ingredients and create something that's not too bad. But not many people are master chefs who can assemble meals that people talk about (in a good way, that is). And so on. In any event ... I really don't care. I find it baffling, and somewhat interesting to discuss, but it's not a pressing issue for me. We've had these kinds of back-and-forth exchanges for ... well it seems like decades, but I think it's only months. :-) I'm working on RDC, and I'm defining my own standard, making my own tools, and Lord willing I will be able to complete them. At that point, it will be the market who decides which one is better. I'm content to be happy using the tools which make me happy. I just wish I had more time to devote to them. I really desire to contribute something robust, and as nice as I can make it. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-08-15 04:15 +0000 |
| Message-ID | <mqmec8$5om$1@speranza.aioe.org> |
| In reply to | #67444 |
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: (snip on new C standards) >> And this is where you have your fundamental flaw, and don't understand >> how standards work (Not just the C standard, but standards in general). >> An extension to a language should not take a working program and break >> it. An extension lets the PROGRAMMER do additional things in his >> program, not give the implementation > I do recognize that, Richard. It's why I wrote, "The C standard as it > is today exists. There's no reason it has to be deleted from the world." > My point there is that everything that works today, written for the > standard, can continue to operate as the standard as it exists today > dictated. However, the new standard that would be created would change > things, and new code written (or legacy code altered) for that standard > would no longer operate as the prior code has. It is possible, but extremely rare. If it is necessary, it is more usual to start a new standard, instead of modify a previous one. Note, for example, that C++ wasn't a new C standard, but a whole new language and standard. There are changes from C to C++ that invalidate valid C programs. (For example, ones using new as a variable name.) >> Your concept of "Core C" makes a perfect extension to C, it add >> constraints to the implementation and allows the programmer to make >> more assumptions. Your concept for an "atypical architecture >> extension" fails the basic test of an extension. > I, of course, disagree. My proposal for Core C is a revamp, removing > many of the things which the C standard today define, making the Core C > definition much smaller. And then, beyond that small core that is much > easier to understand, write a compiler for, etc., come the extensions, > which are only enabled on those platforms and architectures which would > require them. Again, it can be done, but should have a new name. > I look at things this way "Core C ----> Extensions ----> Universe". You > and Ben look at things this way "Universe ----> Constraints ----> Core C". > I view your view as exactly backwards. It mandates a greater amount of > reading, knowledge, understanding from the get-go. It requires that a > person know everything about the Universe that's allowed, and then on > top of that know also what the constraints are which then redefine that > Universe down to something smaller. There are a few features from Fortran 66 that have been removed from Fortran 2008, but pretty much haven't been given new meanings. Even though it isn't required, most compilers still support the old features. > My view starts with the smaller subset, less reading, less knowledge, > less understanding from the get-go. It then requires that those who > want to go into some obtuse architecture with traits which are defined > as extensions outside of the standard, to then, and only then, learn > those peculiarities. It has always been that C was fairly simple as high-level languages go, but yes, many features have been added over the years. Well, the other thing that has been done before is a subset, simpler version, of a language. Mostly that was when small machines weren't able to compile the full language. > I honestly don't understand in the slightest how it is you and Ben > look at things the way you do. I have no thought processes which > operate as you indicate, and I would never advocate thought processes > which go that way. In all areas of our life we start out with the > broad strokes first, and then when we need to, or want to, and only > then, do we then go deeper into the details. > Many people are familiar with what calculus is. Not many people can > integrate trigonometric functions. They understand the lesser amount > of knowledge on the outside, and only those who have a need go deeper. > Most people know that you must prepare and cook food before you eat > it. And many people can follow directions and ingredients and create > something that's not too bad. But not many people are master chefs > who can assemble meals that people talk about (in a good way, that is). (snip) -- glen
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-16 19:00 +0200 |
| Message-ID | <mqqfjf$hnv$1@speranza.aioe.org> |
| In reply to | #67445 |
On 15.08.2015 06:15, glen herrmannsfeldt wrote: > Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: [...] >> I, of course, disagree. My proposal for Core C is a revamp, removing >> many of the things which the C standard today define, making the Core C >> definition much smaller. And then, beyond that small core that is much >> easier to understand, write a compiler for, etc., come the extensions, >> which are only enabled on those platforms and architectures which would >> require them. > > Again, it can be done, but should have a new name. I was thinking about loops the other day, and was wondering, is it really necessary to have different loop constructs? I can't really think of any cases where while and do while can't be skipped. Then again, do and do while would probably be simpler to implement in a compiler. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-16 19:00 +0100 |
| Message-ID | <mqqj0d$hec$1@dont-email.me> |
| In reply to | #67532 |
On 16/08/2015 18:00, Morten W. Petersen wrote: > On 15.08.2015 06:15, glen herrmannsfeldt wrote: >> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > [...] >>> I, of course, disagree. My proposal for Core C is a revamp, removing >>> many of the things which the C standard today define, making the Core C >>> definition much smaller. And then, beyond that small core that is much >>> easier to understand, write a compiler for, etc., come the extensions, >>> which are only enabled on those platforms and architectures which would >>> require them. >> >> Again, it can be done, but should have a new name. > > I was thinking about loops the other day, and was wondering, is it > really necessary to have different loop constructs? > > I can't really think of any cases where while and do while can't > be skipped. Then again, do and do while would probably be > simpler to implement in a compiler. If you were to take 100 things about implementing a language and compiler, and ranked them by difficulty, then implementing while loops would be one of the simplest. There's no reason /not/ to have while loops. While everything you could possibly want to do could be done with a for-loop, you now have the problem that it is not immediately apparent exactly what kind of loop is being performed; is it an iterative loop, is it a while loop, is it a do-while? Some analysis is needed. Having a dedicated construct for these common kinds of loop solves that (and actually C could do with a few more dedicated kinds of loop). Otherwise, why even bother with a for-loop? A combination of 'if' and 'goto' will do the job just as well! What exactly is going to be saved anyway by eliminating 'while'? This is a couple of dozen lines of code in a compiler. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-16 20:20 +0200 |
| Message-ID | <mqqk8s$s7c$1@speranza.aioe.org> |
| In reply to | #67536 |
On 16.08.2015 20:00, Bartc wrote: > On 16/08/2015 18:00, Morten W. Petersen wrote: [...] >> I was thinking about loops the other day, and was wondering, is it >> really necessary to have different loop constructs? >> >> I can't really think of any cases where while and do while can't >> be skipped. Then again, do and do while would probably be >> simpler to implement in a compiler. [...] > There's no reason /not/ to have while loops. While everything you could > possibly want to do could be done with a for-loop, you now have the > problem that it is not immediately apparent exactly what kind of loop is > being performed; is it an iterative loop, is it a while loop, is it a > do-while? Some analysis is needed. > > Having a dedicated construct for these common kinds of loop solves that > (and actually C could do with a few more dedicated kinds of loop). > > Otherwise, why even bother with a for-loop? A combination of 'if' and > 'goto' will do the job just as well! > > What exactly is going to be saved anyway by eliminating 'while'? This is > a couple of dozen lines of code in a compiler. Simplifying the compiler and the code is one reason. OK, a loop isn't that a big of a deal. But, then you add on features to the compiler, such as optimization; then you need different sets of code for each loop construct. That's one example, I'm sure there are others as well. I guess one could strip away the loop as well, and simply use goto, but it would probably be a bad thing to not have any native loop types. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-16 17:18 -0700 |
| Message-ID | <ln37zi939i.fsf@kst-u.example.com> |
| In reply to | #67537 |
"Morten W. Petersen" <morphex@gmail.com> writes:
> On 16.08.2015 20:00, Bartc wrote:
[...]
>> What exactly is going to be saved anyway by eliminating 'while'? This is
>> a couple of dozen lines of code in a compiler.
>
> Simplifying the compiler and the code is one reason. OK, a loop isn't
> that a big of a deal.
>
> But, then you add on features to the compiler, such as optimization;
> then you need different sets of code for each loop construct. That's
> one example, I'm sure there are others as well.
The optimizer probably doesn't need to treat different kinds of loops
differently. Typically a loop construct in C source code is translated
into some internal intermediate form, and the optimizer works on that.
As long as the intermediate code accurately reflects the semantics of
the original loop, the optimizer doesn't have to care where it came
from. (Later optimization phases can work on object code.)
A compiler I once worked on (not for C) would internally transform this:
while (condition) {
statement;
}
into the equivalent of this:
if (condition) {
do {
statement;
while (condition);
}
Loop-invariant code (code that's inside the loop but only needs to be
executed once) can be "hoisted" outside the loop -- but if the loop body
is never executed, that can change the semantics. Transforming a while
loop to a loop whose body is always executed at least once gives the
optimizer a safe place to hoist it to.
> I guess one could strip away the loop as well, and simply use goto,
> but it would probably be a bad thing to not have any native loop types.
Making the compiler's job easier is not all that important. It has a
job to do; I'd much rather let it do that job for me than do it myself.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-16 23:03 +0100 |
| Message-ID | <mqr194$gik$1@dont-email.me> |
| In reply to | #67536 |
On 16/08/2015 19:00, Bartc wrote: > On 16/08/2015 18:00, Morten W. Petersen wrote: >> I can't really think of any cases where while and do while can't >> be skipped. > What exactly is going to be saved anyway by eliminating 'while'? This is > a couple of dozen lines of code in a compiler. I've taken one compiler project, and removed all references to 'while'. The new version was smaller by 37 lines (about 0.15%). So about three dozen lines rather than two. Conversely, adding extra new loop statements could also be a matter of a few dozen extra lines. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 00:52 +0200 |
| Message-ID | <mqr46l$u8v$1@speranza.aioe.org> |
| In reply to | #67546 |
On 17.08.2015 00:03, Bartc wrote: > On 16/08/2015 19:00, Bartc wrote: >> On 16/08/2015 18:00, Morten W. Petersen wrote: > >>> I can't really think of any cases where while and do while can't >>> be skipped. > >> What exactly is going to be saved anyway by eliminating 'while'? This is >> a couple of dozen lines of code in a compiler. > > I've taken one compiler project, and removed all references to 'while'. > The new version was smaller by 37 lines (about 0.15%). > > So about three dozen lines rather than two. > > Conversely, adding extra new loop statements could also be a matter of a > few dozen extra lines. OK, well I have no idea how your compiler works.. but lets say that while and do while are removed, and only for is left. That's less code to write, less code to maintain, less code to extend for example for optimization, less code to go through when debugging, less code to write when porting the compiler to a new architecture. It's also less programming concepts to learn and less things to keep in focus when programming something. I say this because I juggled around different loops on my first big project and messed up a bit on that. In general it is less complexity, less things that could go wrong on a fundamental part of the language. Maybe other parts of the language in a new suit could be trimmed as well, and that in sum these changes make a significant difference. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-17 00:29 +0100 |
| Message-ID | <mqr68p$ia$1@dont-email.me> |
| In reply to | #67547 |
On 16/08/2015 23:52, Morten W. Petersen wrote:
> On 17.08.2015 00:03, Bartc wrote:
>> I've taken one compiler project, and removed all references to 'while'.
>> The new version was smaller by 37 lines (about 0.15%).
>>
>> So about three dozen lines rather than two.
> OK, well I have no idea how your compiler works.. but lets say that
> while and do while are removed, and only for is left.
>
> That's less code to write, less code to maintain, less code to extend
> for example for optimization, less code to go through when debugging,
> less code to write when porting the compiler to a new architecture.
My point is really that, once all the support is in place for one kind
of loop, then adding new types requires very little extra effort.
> It's also less programming concepts to learn and less things to keep in
> focus when programming something. I say this because I juggled around
> different loops on my first big project and messed up a bit on that.
>
> In general it is less complexity, less things that could go wrong on
> a fundamental part of the language.
>
> Maybe other parts of the language in a new suit could be trimmed as
> well, and that in sum these changes make a significant difference.
Syntax is easy to add and has little cost. (Sometimes too easy and you
don't want to overdo it. But that's not going to happen with C as the
spec tells you what is allowed and what isn't. BTW how can you just get
rid of 'while' and still compile C code, or is this for a different
language?)
But look however at how the 'for'-loop was implemented in Algol 68. The
full syntax is something like this:
for <expr> from <expr> by <expr> to <expr> while <expr>
do
<loop body>
od
Most of the syntactical elements here are optional. So you can write
loops in a variety of ways:
for i from a to b do ... od # normal iterative loop
while x do ... od # while loop
to n do ... od # repeat n times
do ... od # infinite loop
Just one loop statement, but it can be used to write these different
kinds of loop. C's for-loop tries to do the same, but it falls short. So
a while-loop written with for is:
for (;x;) {...}
It looks nothing like a while-loop, unlike Algol 68's version, also
based on for, which /is/ a while loop. And to repeat N times, it's
for (i=N; i; --i) {...}
There's a lot going on there and it's not obvious, compared with:
i=N;
while (i--) {...}
I suggest that you keep 'while'.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 02:36 +0200 |
| Subject | A simpler version of C (was: Re: C pointer semantics with dynamically allocated struct) |
| Message-ID | <mqrab1$8vb$1@speranza.aioe.org> |
| In reply to | #67549 |
On 17.08.2015 01:29, Bartc wrote:
> On 16/08/2015 23:52, Morten W. Petersen wrote:
[...]
>> That's less code to write, less code to maintain, less code to extend
>> for example for optimization, less code to go through when debugging,
>> less code to write when porting the compiler to a new architecture.
>
> My point is really that, once all the support is in place for one kind
> of loop, then adding new types requires very little extra effort.
>
>> It's also less programming concepts to learn and less things to keep in
>> focus when programming something. I say this because I juggled around
>> different loops on my first big project and messed up a bit on that.
>>
>> In general it is less complexity, less things that could go wrong on
>> a fundamental part of the language.
>>
>> Maybe other parts of the language in a new suit could be trimmed as
>> well, and that in sum these changes make a significant difference.
>
> Syntax is easy to add and has little cost. (Sometimes too easy and you
> don't want to overdo it. But that's not going to happen with C as the
> spec tells you what is allowed and what isn't. BTW how can you just get
> rid of 'while' and still compile C code, or is this for a different
> language?)
Yes, that seems to be the main point now, that it is less things
to learn and remember. Knowing the for loop perfectly well in
different settings is complicated enough.
Some posts ago this thread got into changing the C standard, and
I don't see that happening so it'll have to be some variant of C,
called minimal-C perhaps?
I'm just discussing this because it is interesting, I don't have
any ambitions of creating something new. Not now anyway.
[...]
> Just one loop statement, but it can be used to write these different
> kinds of loop. C's for-loop tries to do the same, but it falls short. So
> a while-loop written with for is:
>
> for (;x;) {...}
>
> It looks nothing like a while-loop, unlike Algol 68's version, also
> based on for, which /is/ a while loop. And to repeat N times, it's
>
> for (i=N; i; --i) {...}
>
> There's a lot going on there and it's not obvious, compared with:
>
> i=N;
> while (i--) {...}
i = N;
for(;i--;) {...}
works as well.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-08-17 01:47 +0000 |
| Message-ID | <mqreg9$gb2$1@speranza.aioe.org> |
| In reply to | #67536 |
Bartc <bc@freeuk.com> wrote: > On 16/08/2015 18:00, Morten W. Petersen wrote: (snip) >> I was thinking about loops the other day, and was wondering, is it >> really necessary to have different loop constructs? >> I can't really think of any cases where while and do while can't >> be skipped. Then again, do and do while would probably be >> simpler to implement in a compiler. > If you were to take 100 things about implementing a language and > compiler, and ranked them by difficulty, then implementing while loops > would be one of the simplest. I pretty much never write while loops. If I have logic that would need one, I write the matching for loop instead. Too often when actually writing a while loop I later changed to for, so it is easier to start with for. > There's no reason /not/ to have while loops. While everything you could > possibly want to do could be done with a for-loop, you now have the > problem that it is not immediately apparent exactly what kind of loop is > being performed; is it an iterative loop, is it a while loop, is it a > do-while? Some analysis is needed. Well, it isn't anyway. You can iterate a while loop just the same. I know I have written for loops that had the increment inside the loop body, as it depended on some condition too hard to test otherwise. I believe also when I needed a continue that didn't increment, though often it would. But as always, write the most readable form. I have done: for(n=1; fgets( ... ) ; n++) ... so that n counts the lines, (well, fgetss) as another example. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-17 11:27 +0100 |
| Message-ID | <mqscrm$gce$1@dont-email.me> |
| In reply to | #67556 |
On 17/08/2015 02:47, glen herrmannsfeldt wrote:
> Bartc <bc@freeuk.com> wrote:
>> On 16/08/2015 18:00, Morten W. Petersen wrote:
>
> (snip)
>>> I was thinking about loops the other day, and was wondering, is it
>>> really necessary to have different loop constructs?
>
>>> I can't really think of any cases where while and do while can't
>>> be skipped. Then again, do and do while would probably be
>>> simpler to implement in a compiler.
>
>> If you were to take 100 things about implementing a language and
>> compiler, and ranked them by difficulty, then implementing while loops
>> would be one of the simplest.
>
> I pretty much never write while loops. If I have logic that would
> need one, I write the matching for loop instead.
That sounds rather perverse. How you thought about whether that makes it
easier or harder for the readers of your code?
I've just looked at some of my code and I use many hundreds of while
statements, each of which exactly represents what I'm trying to express.
Example:
while(a<b) a=a*2;
I can't really see that it helps matters by writing it as:
for (;a<b;a=a*2);
Here, the original intention has to be reconstructed in the mind of the
reader. And it's also now position dependent; change the phase of the
semicolons:
for (a<b;a=a*2;);
and it looks almost identical, it still compiles, but it's completely
wrong. This phase-checking is something else that needs to be done in
the mind of the reader.
> But as always, write the most readable form. I have done:
>
> for(n=1; fgets( ... ) ; n++) ...
>
> so that n counts the lines, (well, fgetss) as another example.
And this is a perfect example. It took me quite a few extra seconds to
establish that that this wasn't a normal interating loop (helped by your
comment and the context; encountered in normal code I wouldn't have
those cues).
This would not be necessary if written as:
nlines=0;
while (fgets()) {
++nlines;
....
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 12:40 +0200 |
| Message-ID | <mqsdmr$fo9$1@speranza.aioe.org> |
| In reply to | #67574 |
On 17.08.2015 12:27, Bartc wrote: > On 17/08/2015 02:47, glen herrmannsfeldt wrote: [...] > That sounds rather perverse. How you thought about whether that makes it > easier or harder for the readers of your code? > > I've just looked at some of my code and I use many hundreds of while > statements, each of which exactly represents what I'm trying to express. > Example: > > while(a<b) a=a*2; > > I can't really see that it helps matters by writing it as: > > for (;a<b;a=a*2); > > Here, the original intention has to be reconstructed in the mind of the > reader. And it's also now position dependent; change the phase of the > semicolons: > > for (a<b;a=a*2;); > > and it looks almost identical, it still compiles, but it's completely > wrong. This phase-checking is something else that needs to be done in > the mind of the reader. 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? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-17 12:07 +0100 |
| Message-ID | <mqsf72$od8$1@dont-email.me> |
| In reply to | #67575 |
On 17/08/2015 11:40, Morten W. Petersen wrote: > On 17.08.2015 12:27, Bartc wrote: >> On 17/08/2015 02:47, glen herrmannsfeldt wrote: > [...] >> That sounds rather perverse. How you thought about whether that makes it >> easier or harder for the readers of your code? >> >> I've just looked at some of my code and I use many hundreds of while >> statements, each of which exactly represents what I'm trying to express. >> Example: >> >> while(a<b) a=a*2; >> >> I can't really see that it helps matters by writing it as: >> >> for (;a<b;a=a*2); >> >> Here, the original intention has to be reconstructed in the mind of the >> reader. And it's also now position dependent; change the phase of the >> semicolons: >> >> for (a<b;a=a*2;); >> >> and it looks almost identical, it still compiles, but it's completely >> wrong. This phase-checking is something else that needs to be done in >> the mind of the reader. > > 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! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 13:36 +0200 |
| Message-ID | <mqsguo$n6t$1@speranza.aioe.org> |
| In reply to | #67577 |
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? C was created a long time ago, and there's been a lot of ground made in different areas, so if someone could start from scratch, or rather with full freedom, they could probably create a variant of C that is better suited for certain purposes. I guess you can say it would be at the opposite side of the spectrum of for example JIT technology, certainly worth exploring. -Morten
[toc] | [prev] | [next] | [standalone]
Page 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web