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 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 22:31 +0200 |
| Message-ID | <mqtga7$17e$2@speranza.aioe.org> |
| In reply to | #67626 |
On 17.08.2015 22:24, David Brown wrote:
[...]
> 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.
It is one of the things that can be removed to reduce complexity and
the learning curve of developing a program.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-17 15:04 -0700 |
| Message-ID | <lna8tp6079.fsf@kst-u.example.com> |
| In reply to | #67630 |
"Morten W. Petersen" <morphex@gmail.com> writes:
> On 17.08.2015 22:24, David Brown wrote:
> [...]
>> 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.
>
> It is one of the things that can be removed to reduce complexity and
> the learning curve of developing a program.
Removing the for loop would not reduce the learning curve of developing
a program. It would instead remove some very small burden from the
compiler developer and place it on the programmer.
If I want a loop to run 10 times, setting i to the values 0 through 9 in
sequence, a for loop lets me express that intent more clearly than the
equivalent while loop, and it's easier and less error-prone to write.
That benefit is more than worth the minor cost of (a) defining it in the
language and (b) implementing it in compilers. (One could certainly
argue that C's for loop should have been designed differently; that's a
different manner than omitting it entirely.)
--
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 | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 23:41 +0200 |
| Message-ID | <mqtkes$avr$1@speranza.aioe.org> |
| In reply to | #67635 |
On 18.08.2015 00:04, Keith Thompson wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: [...] >> It is one of the things that can be removed to reduce complexity and >> the learning curve of developing a program. > > Removing the for loop would not reduce the learning curve of developing > a program. It would instead remove some very small burden from the > compiler developer and place it on the programmer. > > If I want a loop to run 10 times, setting i to the values 0 through 9 in > sequence, a for loop lets me express that intent more clearly than the > equivalent while loop, and it's easier and less error-prone to write. > That benefit is more than worth the minor cost of (a) defining it in the > language and (b) implementing it in compilers. (One could certainly > argue that C's for loop should have been designed differently; that's a > different manner than omitting it entirely.) It's a different loop type to learn.. I think that's a valid point and take it your opinion is that it is better to have more loop types and that's fair enough. My guess is that you've grown accustomed to these different loop types and find it hard to change habits and use just one. And that's fair enough too. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-17 17:58 -0700 |
| Message-ID | <lnsi7h4dla.fsf@kst-u.example.com> |
| In reply to | #67638 |
"Morten W. Petersen" <morphex@gmail.com> writes:
> On 18.08.2015 00:04, Keith Thompson wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
> [...]
>>> It is one of the things that can be removed to reduce complexity and
>>> the learning curve of developing a program.
>>
>> Removing the for loop would not reduce the learning curve of developing
>> a program. It would instead remove some very small burden from the
>> compiler developer and place it on the programmer.
>>
>> If I want a loop to run 10 times, setting i to the values 0 through 9 in
>> sequence, a for loop lets me express that intent more clearly than the
>> equivalent while loop, and it's easier and less error-prone to write.
>> That benefit is more than worth the minor cost of (a) defining it in the
>> language and (b) implementing it in compilers. (One could certainly
>> argue that C's for loop should have been designed differently; that's a
>> different manner than omitting it entirely.)
>
> It's a different loop type to learn.. I think that's a valid point and
> take it your opinion is that it is better to have more loop types and
> that's fair enough.
>
> My guess is that you've grown accustomed to these different loop types
> and find it hard to change habits and use just one. And that's fair
> enough too.
It's certainly true that I've grown accustomed to having several
different kinds of loops. I'm familiar with several programming
languages; all of them have both while loops and some kind of for
loops (some like C's, some that strictly iterate over a discrete
range, some that iterate over the elements of a data structure).
I can never be completely certain that I'm being objective, but I
really do think that having at least a "while" loop that executes
as long as a condition is true *and* a "for" loop that iterates
over a range is worthwhile. You *could* get by with just one
or the other (assuming the for loop is sufficiently flexible),
but each expresses a different conceptual intent. Being able to
express my intent in a programming language without too much added
boilerplate is A Good Thing. And the burden of learning one more
looping construct is minor compared to learning an entire language.
--
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 | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-17 14:53 -0700 |
| Message-ID | <3ebd5e8e-1c7c-4ca3-b276-eba85756e306@googlegroups.com> |
| In reply to | #67635 |
Keith Thompson wrote:
> If I want a loop to run 10 times, setting i to the values 0 through
> 9 in sequence...
This reminds me of the joke:
The Top 10 things I hate most about C:
#9 ...
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-17 16:58 +0200 |
| Message-ID | <mqssng$cn7$1@dont-email.me> |
| In reply to | #67599 |
On 17/08/15 16:45, Morten W. Petersen wrote: > 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? I'm sorry, I can't figure out what you mean here. > > [...] >>> 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? I suppose not - except that from your posts, I get the impression you think C has too many features (such as unnecessarily having "while" and "for"), and that you think it would be better if it were reduced. I disagree with that idea. But perhaps the discussion has strayed a bit from that - and if we are losing track, we should simply skip this point. > > [...] >>> 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. > It has already been shown (by someone who has written compilers) that keeping "for" and "while" makes a negligible difference to the compiler. It has also been pointed out that internally, compilers usually change all loops into some internal format - so we are talking about a small change to the front-end parser of the compiler. I fully agree with the idea of keeping things fairly simple, but useful low-cost features are good to have.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 22:16 +0200 |
| Message-ID | <mqtff6$vdk$1@speranza.aioe.org> |
| In reply to | #67602 |
On 17.08.2015 16:58, David Brown wrote: > On 17/08/15 16:45, Morten W. Petersen wrote: >> 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? > > I'm sorry, I can't figure out what you mean here. Well, you have ifdef, define and so on which have some logic in them and aren't simple string replacements that change things before the code is compiled. All of these can be built to behave like a struct, so that one basically calls different functions and change variables instead of define macros. [...] >>> 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? > > I suppose not - except that from your posts, I get the impression you > think C has too many features (such as unnecessarily having "while" and > "for"), and that you think it would be better if it were reduced. I > disagree with that idea. But perhaps the discussion has strayed a bit > from that - and if we are losing track, we should simply skip this point. I think C is great. The discussion about a variant of C came out of comments on changing the C language. I think it is hard to get something changed in the C language, so if one is so inclined, one can create a variant that works exactly the way one wants. >>> 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. >> > > It has already been shown (by someone who has written compilers) that > keeping "for" and "while" makes a negligible difference to the compiler. > It has also been pointed out that internally, compilers usually change > all loops into some internal format - so we are talking about a small > change to the front-end parser of the compiler. > > I fully agree with the idea of keeping things fairly simple, but useful > low-cost features are good to have. Yes, I agreed that the code size wasn't a big deal, then it is about the learning curve. If the new variant is a strict subset of C code except for the macro bit, then "upgrading" to C or C++ isn't a big step. If anything, a slim, simplified variant of C could serve as a recruitment channel for C. -Morten
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-18 01:31 +0200 |
| Message-ID | <mqtqpp$frq$1@dont-email.me> |
| In reply to | #67624 |
On 17/08/15 22:16, Morten W. Petersen wrote: > On 17.08.2015 16:58, David Brown wrote: >> On 17/08/15 16:45, Morten W. Petersen wrote: >>> 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? >> >> I'm sorry, I can't figure out what you mean here. > > Well, you have ifdef, define and so on which have some logic > in them and aren't simple string replacements that change > things before the code is compiled. > > All of these can be built to behave like a struct, so that > one basically calls different functions and change variables > instead of define macros. > I still don't really understand what you mean. Are you trying to suggest that conditional compilation (such as by #ifdef) can be replaced by structs in some way? Certainly /some/ cases could be, I suppose - probably at significant cost in terms of messy source code and inefficient object code. But it is certainly not the general case. > [...] >>>> 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? >> >> I suppose not - except that from your posts, I get the impression you >> think C has too many features (such as unnecessarily having "while" and >> "for"), and that you think it would be better if it were reduced. I >> disagree with that idea. But perhaps the discussion has strayed a bit >> from that - and if we are losing track, we should simply skip this point. > > I think C is great. The discussion about a variant of C came out > of comments on changing the C language. > > I think it is hard to get something changed in the C language, so > if one is so inclined, one can create a variant that works exactly > the way one wants. Absolutely - and there is no harm in that. There is also no harm in discussing what one might want in an "ideal C" (although be aware that some people think it is off-topic in this newsgroup) - as long as it is clear that we are talking about a variant of C of some sort, and there is no real hope of influencing the /real/ C standards significantly! You also have to be ready to justify your opinions and ideas when you want to make changes - as far as I can see in the debate about dropping one of "for" or "while", you have made an effort, but failed to win over the crowd. > >>>> 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. >>> >> >> It has already been shown (by someone who has written compilers) that >> keeping "for" and "while" makes a negligible difference to the compiler. >> It has also been pointed out that internally, compilers usually change >> all loops into some internal format - so we are talking about a small >> change to the front-end parser of the compiler. >> >> I fully agree with the idea of keeping things fairly simple, but useful >> low-cost features are good to have. > > Yes, I agreed that the code size wasn't a big deal, then it is > about the learning curve. It is (IMHO, of course) easier to learn two loop keywords "for" and "while" than to learn idioms such as "for (; (cond) ;)" or the extra code needed to make an counter loop using "while". Too many features and keywords, especially if they are essential to many programs, makes a language hard to learn. But equally, too /few/ features and keywords will make it hard to learn for actually writing programs. Again, I refer you to examples of languages which have taken minimalism to the extreme, such as: <https://en.wikipedia.org/wiki/Brainfuck> With "only eight simple commands and an instruction pointer", it is not particularly hard to learn the "keywords" and syntax - yet it is immensely difficult to learn to use it sensibly. And you can look through the archives of this newsgroup for people who think C would be improved by dropping all control structures except a single "if (cond) goto " macro - and then try to learn their variant of C. > > If the new variant is a strict subset of C code except for the > macro bit, then "upgrading" to C or C++ isn't a big step. > > If anything, a slim, simplified variant of C could serve as a > recruitment channel for C. > This would make sense if C had too many features, and removing them actually made the language easier to learn - but that is not the case. (Arguably C99 and C11 added new features that made the language harder to learn, and it is best to "remove" them by sticking to ANSI/C89/C90. I say "arguably" because I don't agree with that idea, but some people do.) Removing such basic features as "for" loops will make the language harder, and lead potential C learners to see it as too limited.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-19 08:51 +0200 |
| Message-ID | <mr1925$2ul$1@speranza.aioe.org> |
| In reply to | #67656 |
On 18.08.2015 01:31, David Brown wrote: > On 17/08/15 22:16, Morten W. Petersen wrote: [...] >> Well, you have ifdef, define and so on which have some logic >> in them and aren't simple string replacements that change >> things before the code is compiled. >> >> All of these can be built to behave like a struct, so that >> one basically calls different functions and change variables >> instead of define macros. >> > > I still don't really understand what you mean. Are you trying to > suggest that conditional compilation (such as by #ifdef) can be replaced > by structs in some way? Certainly /some/ cases could be, I suppose - > probably at significant cost in terms of messy source code and > inefficient object code. But it is certainly not the general case. Well lets say that one can define a configure() function before main in a source code file. That configure() statement is compiled and run before the rest of the compilation, and different compiler settings, defines and so on can be accessed via variables, and struct variables for different configuration areas seem like a good way to organize the variables. [...] >> I think C is great. The discussion about a variant of C came out >> of comments on changing the C language. >> >> I think it is hard to get something changed in the C language, so >> if one is so inclined, one can create a variant that works exactly >> the way one wants. > > Absolutely - and there is no harm in that. There is also no harm in > discussing what one might want in an "ideal C" (although be aware that > some people think it is off-topic in this newsgroup) - as long as it is > clear that we are talking about a variant of C of some sort, and there > is no real hope of influencing the /real/ C standards significantly! You > also have to be ready to justify your opinions and ideas when you want > to make changes - as far as I can see in the debate about dropping one > of "for" or "while", you have made an effort, but failed to win over the > crowd. Hehe. :) Yes, well the loop thing is one little bit, and some of the points made in that discussion can be applied to other parts of the language as well. As for being off-topic, I can't think of any better place to discuss a slimmed down variant of C than comp.lang.c. The amount of details and discussions around the subject of loops shows that people are interested and have a lot of knowledge. >> If the new variant is a strict subset of C code except for the >> macro bit, then "upgrading" to C or C++ isn't a big step. >> >> If anything, a slim, simplified variant of C could serve as a >> recruitment channel for C. >> > > This would make sense if C had too many features, and removing them > actually made the language easier to learn - but that is not the case. > > (Arguably C99 and C11 added new features that made the language harder > to learn, and it is best to "remove" them by sticking to ANSI/C89/C90. I > say "arguably" because I don't agree with that idea, but some people do.) > > Removing such basic features as "for" loops will make the language > harder, and lead potential C learners to see it as too limited. Well a potential C learner will know that there is the option of upgrading to C and that the new variant is slimmed down. There are more things than loops that can be changed/slimmed down, and its just not about learning but also code base size. Replacing macros with actual C code is another option. -Morten
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-19 09:56 +0200 |
| Message-ID | <mr1cnm$d5s$1@dont-email.me> |
| In reply to | #67784 |
On 19/08/15 08:51, Morten W. Petersen wrote: > On 18.08.2015 01:31, David Brown wrote: >> On 17/08/15 22:16, Morten W. Petersen wrote: > [...] >>> Well, you have ifdef, define and so on which have some logic >>> in them and aren't simple string replacements that change >>> things before the code is compiled. >>> >>> All of these can be built to behave like a struct, so that >>> one basically calls different functions and change variables >>> instead of define macros. >>> >> >> I still don't really understand what you mean. Are you trying to >> suggest that conditional compilation (such as by #ifdef) can be replaced >> by structs in some way? Certainly /some/ cases could be, I suppose - >> probably at significant cost in terms of messy source code and >> inefficient object code. But it is certainly not the general case. > > Well lets say that one can define a configure() function before main > in a source code file. > > That configure() statement is compiled and run before the rest of > the compilation, and different compiler settings, defines and so > on can be accessed via variables, and struct variables for different > configuration areas seem like a good way to organize the variables. Maybe I am being particularly dim here, but I feel there is some vital point hiding here that in your mind is obvious, but I just can't see it. When you talk about a "configure() statement", are you referring to something done before /compilation/ starts? Somewhat like a "./configure" script commonly run for *nix software before "make" ? Or perhaps as an alternative pre-processor pass? Or do you mean a run-time function that is called before main() starts? In my world (small system embedded programming), it is not uncommon to have functions that are called before main() itself starts up, such as to initialise key aspects of the board or device in use. But I don't see how that fits in here. > > [...] >>> I think C is great. The discussion about a variant of C came out >>> of comments on changing the C language. >>> >>> I think it is hard to get something changed in the C language, so >>> if one is so inclined, one can create a variant that works exactly >>> the way one wants. >> >> Absolutely - and there is no harm in that. There is also no harm in >> discussing what one might want in an "ideal C" (although be aware that >> some people think it is off-topic in this newsgroup) - as long as it is >> clear that we are talking about a variant of C of some sort, and there >> is no real hope of influencing the /real/ C standards significantly! You >> also have to be ready to justify your opinions and ideas when you want >> to make changes - as far as I can see in the debate about dropping one >> of "for" or "while", you have made an effort, but failed to win over the >> crowd. > > Hehe. :) > > Yes, well the loop thing is one little bit, and some of the points made > in that discussion can be applied to other parts of the language as > well. I am confident that we could find other aspects of C where we would agree that simplifying or removing a language feature could improve the language (in terms of helping people write clear, bug-free and efficient code), or make life easier for compiler writers (without hindering the user too much). My first stab at that (without having giving it much thought) would be to remove the comma operator. But removing one of "for" or "while" would be /way/ down on my list. > > As for being off-topic, I can't think of any better place to discuss > a slimmed down variant of C than comp.lang.c. The amount of details > and discussions around the subject of loops shows that people are > interested and have a lot of knowledge. /I/ don't think it is off-topic, but I know some people here do. I believe this is a fine place to talk about such variants in general terms, but if things get too detailed or stray far from "real" C, then the group might not be the best place to get the discussions and answers you want. It's like C++ - it's fine to mention C++ here, especially in terms of a comparison to C, but for more details of something that is C++ but not C, it is best to go elsewhere. (Of course with C++ there is another newsgroup for it - that's not the case for C variants.) > >>> If the new variant is a strict subset of C code except for the >>> macro bit, then "upgrading" to C or C++ isn't a big step. >>> >>> If anything, a slim, simplified variant of C could serve as a >>> recruitment channel for C. >>> >> >> This would make sense if C had too many features, and removing them >> actually made the language easier to learn - but that is not the case. >> >> (Arguably C99 and C11 added new features that made the language harder >> to learn, and it is best to "remove" them by sticking to ANSI/C89/C90. I >> say "arguably" because I don't agree with that idea, but some people do.) >> >> Removing such basic features as "for" loops will make the language >> harder, and lead potential C learners to see it as too limited. > > Well a potential C learner will know that there is the option of > upgrading to C and that the new variant is slimmed down. > > There are more things than loops that can be changed/slimmed down, > and its just not about learning but also code base size. > > Replacing macros with actual C code is another option. > Replacing macros with C code, where possible, is usually the best idea - but you can do that with C as it stands today, and you don't need to remove macros in order to do so. A good many - but not all - function-like macros can be replaced with "static inline" functions. A good many - but not all - #define'd constants can be replaced with enum constants or "static const" variables. Rather than slimming down C, the best way forward here is to /expand/ C. In particular, C++'s ability to use "const" and "static const" values as compile-time constants would help in many cases: const int bufferSize = 100; char buffer[bufferSize]; // Legal in C++, not in C Turning more general function-like macros into "normal" code requires a bit more added functionality - by the time you have templates and function overloading, you are a long way towards C++ which is seldom viewed as a "simple" language :-)
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-20 08:52 +0200 |
| Message-ID | <mr3tg4$sdi$1@speranza.aioe.org> |
| In reply to | #67790 |
On 19.08.2015 09:56, David Brown wrote:
> On 19/08/15 08:51, Morten W. Petersen wrote:
>> On 18.08.2015 01:31, David Brown wrote:
>>> On 17/08/15 22:16, Morten W. Petersen wrote:
>> [...]
>>>> Well, you have ifdef, define and so on which have some logic
>>>> in them and aren't simple string replacements that change
>>>> things before the code is compiled.
>>>>
>>>> All of these can be built to behave like a struct, so that
>>>> one basically calls different functions and change variables
>>>> instead of define macros.
>>>>
>>>
>>> I still don't really understand what you mean. Are you trying to
>>> suggest that conditional compilation (such as by #ifdef) can be replaced
>>> by structs in some way? Certainly /some/ cases could be, I suppose -
>>> probably at significant cost in terms of messy source code and
>>> inefficient object code. But it is certainly not the general case.
>>
>> Well lets say that one can define a configure() function before main
>> in a source code file.
>>
>> That configure() statement is compiled and run before the rest of
>> the compilation, and different compiler settings, defines and so
>> on can be accessed via variables, and struct variables for different
>> configuration areas seem like a good way to organize the variables.
>
> Maybe I am being particularly dim here, but I feel there is some vital
> point hiding here that in your mind is obvious, but I just can't see it.
>
> When you talk about a "configure() statement", are you referring to
> something done before /compilation/ starts? Somewhat like a
> "./configure" script commonly run for *nix software before "make" ? Or
> perhaps as an alternative pre-processor pass?
>
> Or do you mean a run-time function that is called before main() starts?
> In my world (small system embedded programming), it is not uncommon to
> have functions that are called before main() itself starts up, such as
> to initialise key aspects of the board or device in use. But I don't
> see how that fits in here.
Well, for replacing macros for example.. a function called configure,
can be placed before main.
This function can have access to functions that replace for example
define, so that the code would look something like this:
void configure() {
set_key(global_settings, "READ_AMOUNT", 4096);
set_key(global_settings, "READ_BYTES", 1024*1024*100);
if (get(global_settings, "READ_BYTES") % get(global_settings,
"READ_AMOUNT")) {
fail("READ_BYTES must be divisible by READ_AMOUNT");
}
}
Now I see that later on in for example main, replacing macros is a
bit more tricky, as it is no longer a simple search-and-replace like
it would be with a macro.
However, the compiler could know what to optimize out, additionally
the global_settings could optionally be a runtime setting so that
variables that are usually set at compilation time could be changed at
runtime.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-20 10:09 +0200 |
| Message-ID | <mr41sv$c65$1@dont-email.me> |
| In reply to | #67868 |
On 20/08/15 08:52, Morten W. Petersen wrote:
> On 19.08.2015 09:56, David Brown wrote:
>> On 19/08/15 08:51, Morten W. Petersen wrote:
>>> On 18.08.2015 01:31, David Brown wrote:
>>>> On 17/08/15 22:16, Morten W. Petersen wrote:
>>> [...]
>>>>> Well, you have ifdef, define and so on which have some logic
>>>>> in them and aren't simple string replacements that change
>>>>> things before the code is compiled.
>>>>>
>>>>> All of these can be built to behave like a struct, so that
>>>>> one basically calls different functions and change variables
>>>>> instead of define macros.
>>>>>
>>>>
>>>> I still don't really understand what you mean. Are you trying to
>>>> suggest that conditional compilation (such as by #ifdef) can be
>>>> replaced
>>>> by structs in some way? Certainly /some/ cases could be, I suppose -
>>>> probably at significant cost in terms of messy source code and
>>>> inefficient object code. But it is certainly not the general case.
>>>
>>> Well lets say that one can define a configure() function before main
>>> in a source code file.
>>>
>>> That configure() statement is compiled and run before the rest of
>>> the compilation, and different compiler settings, defines and so
>>> on can be accessed via variables, and struct variables for different
>>> configuration areas seem like a good way to organize the variables.
>>
>> Maybe I am being particularly dim here, but I feel there is some vital
>> point hiding here that in your mind is obvious, but I just can't see it.
>>
>> When you talk about a "configure() statement", are you referring to
>> something done before /compilation/ starts? Somewhat like a
>> "./configure" script commonly run for *nix software before "make" ? Or
>> perhaps as an alternative pre-processor pass?
>>
>> Or do you mean a run-time function that is called before main() starts?
>> In my world (small system embedded programming), it is not uncommon to
>> have functions that are called before main() itself starts up, such as
>> to initialise key aspects of the board or device in use. But I don't
>> see how that fits in here.
>
> Well, for replacing macros for example.. a function called configure,
> can be placed before main.
>
> This function can have access to functions that replace for example
> define, so that the code would look something like this:
>
> void configure() {
> set_key(global_settings, "READ_AMOUNT", 4096);
> set_key(global_settings, "READ_BYTES", 1024*1024*100);
> if (get(global_settings, "READ_BYTES") % get(global_settings,
> "READ_AMOUNT")) {
> fail("READ_BYTES must be divisible by READ_AMOUNT");
> }
> }
>
> Now I see that later on in for example main, replacing macros is a
> bit more tricky, as it is no longer a simple search-and-replace like
> it would be with a macro.
>
> However, the compiler could know what to optimize out, additionally
> the global_settings could optionally be a runtime setting so that
> variables that are usually set at compilation time could be changed at
> runtime.
>
It would be /vastly/ easier and more efficient to simply write:
int READ_AMOUNT = 4096; // Allowing runtime modification
or
static const int READ_AMOUNT = 4096; // No modification allowed
I can't see how your "configure" function gives any advantages. And it
cannot possibly work for the parts of C that require a literal,
#define'd constant, or enum constant - such as for the size of a
statically allocated array.
The compiler would not be able to "optimise out" anything involving your
configure'd settings - unless you plan on calling configure() before
compilation. And if the constants are not available and known to the
compiler at compile time, whole classes of optimisations become unavailable.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-20 12:48 +0200 |
| Message-ID | <mr4bac$t8q$1@speranza.aioe.org> |
| In reply to | #67876 |
On 20.08.2015 10:09, David Brown wrote:
> On 20/08/15 08:52, Morten W. Petersen wrote:
[...]
>> Well, for replacing macros for example.. a function called configure,
>> can be placed before main.
>>
>> This function can have access to functions that replace for example
>> define, so that the code would look something like this:
>>
>> void configure() {
>> set_key(global_settings, "READ_AMOUNT", 4096);
>> set_key(global_settings, "READ_BYTES", 1024*1024*100);
>> if (get(global_settings, "READ_BYTES") % get(global_settings,
>> "READ_AMOUNT")) {
>> fail("READ_BYTES must be divisible by READ_AMOUNT");
>> }
>> }
>>
>> Now I see that later on in for example main, replacing macros is a
>> bit more tricky, as it is no longer a simple search-and-replace like
>> it would be with a macro.
>>
>> However, the compiler could know what to optimize out, additionally
>> the global_settings could optionally be a runtime setting so that
>> variables that are usually set at compilation time could be changed at
>> runtime.
>>
>
> It would be /vastly/ easier and more efficient to simply write:
>
> int READ_AMOUNT = 4096; // Allowing runtime modification
>
> or
>
> static const int READ_AMOUNT = 4096; // No modification allowed
>
> I can't see how your "configure" function gives any advantages. And it
> cannot possibly work for the parts of C that require a literal,
> #define'd constant, or enum constant - such as for the size of a
> statically allocated array.
>
> The compiler would not be able to "optimise out" anything involving your
> configure'd settings - unless you plan on calling configure() before
> compilation. And if the constants are not available and known to the
> compiler at compile time, whole classes of optimisations become unavailable.
It was mentioned earlier that configure() would be run before
compilation.
I'm sure there are ways to make things work, but this is about as much
time I'm willing to spend discussing an interesting idea for now.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-20 13:00 +0200 |
| Message-ID | <mr4bsc$cto$1@dont-email.me> |
| In reply to | #67879 |
On 20/08/15 12:48, Morten W. Petersen wrote:
> On 20.08.2015 10:09, David Brown wrote:
>> On 20/08/15 08:52, Morten W. Petersen wrote:
> [...]
>>> Well, for replacing macros for example.. a function called configure,
>>> can be placed before main.
>>>
>>> This function can have access to functions that replace for example
>>> define, so that the code would look something like this:
>>>
>>> void configure() {
>>> set_key(global_settings, "READ_AMOUNT", 4096);
>>> set_key(global_settings, "READ_BYTES", 1024*1024*100);
>>> if (get(global_settings, "READ_BYTES") % get(global_settings,
>>> "READ_AMOUNT")) {
>>> fail("READ_BYTES must be divisible by READ_AMOUNT");
>>> }
>>> }
>>>
>>> Now I see that later on in for example main, replacing macros is a
>>> bit more tricky, as it is no longer a simple search-and-replace like
>>> it would be with a macro.
>>>
>>> However, the compiler could know what to optimize out, additionally
>>> the global_settings could optionally be a runtime setting so that
>>> variables that are usually set at compilation time could be changed at
>>> runtime.
>>>
>>
>> It would be /vastly/ easier and more efficient to simply write:
>>
>> int READ_AMOUNT = 4096; // Allowing runtime modification
>>
>> or
>>
>> static const int READ_AMOUNT = 4096; // No modification allowed
>>
>> I can't see how your "configure" function gives any advantages. And it
>> cannot possibly work for the parts of C that require a literal,
>> #define'd constant, or enum constant - such as for the size of a
>> statically allocated array.
>>
>> The compiler would not be able to "optimise out" anything involving your
>> configure'd settings - unless you plan on calling configure() before
>> compilation. And if the constants are not available and known to the
>> compiler at compile time, whole classes of optimisations become
>> unavailable.
>
> It was mentioned earlier that configure() would be run before
> compilation.
So this really just amounts to a rather messy and hard-to-define
alternative to one use of #define'd macros. I don't see it catching on,
especially as a far better solution is staring us in the face (from
C++). But it's fine to think of new ideas - even if most don't work
out, some will.
>
> I'm sure there are ways to make things work, but this is about as much
> time I'm willing to spend discussing an interesting idea for now.
>
Fair enough.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2015-08-20 13:53 +0000 |
| Message-ID | <slrn3vfsmtbn1s.jb4.ike@iceland.freeshell.org> |
| In reply to | #67879 |
On 2015-08-20, Morten W. Petersen <morphex@gmail.com> wrote: > It was mentioned earlier that configure() would be run before > compilation. How can configure() be run before it's compiled?
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-20 16:36 +0200 |
| Message-ID | <mr4om7$u80$1@speranza.aioe.org> |
| In reply to | #67882 |
On 08/20/2015 03:53 PM, Ike Naar wrote: > On 2015-08-20, Morten W. Petersen <morphex@gmail.com> wrote: >> It was mentioned earlier that configure() would be run before >> compilation. > > How can configure() be run before it's compiled? There will be 2 steps of compilation. configure() will be parsed and compiled first, then the rest of the program will be compiled. Then different settings will be available in for example a dictionary called global_settings for the rest of the source code. If the dictionary is marked read-only, the compiler can do a replacement of the get from dictionary code so that the variable value is directly available, if the dictionary is read-write then it becomes a runtime configuration. -Morten
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-20 07:39 -0700 |
| Message-ID | <eb2bcda5-fdc3-4744-9621-5720a3f56893@googlegroups.com> |
| In reply to | #67884 |
On Thursday, August 20, 2015 at 10:37:08 AM UTC-4, Morten W. Petersen wrote: > On 08/20/2015 03:53 PM, Ike Naar wrote: > > On 2015-08-20, Morten W. Petersen <morphex@gmail.com> wrote: > >> It was mentioned earlier that configure() would be run before > >> compilation. > > > > How can configure() be run before it's compiled? > > There will be 2 steps of compilation. configure() will be parsed > and compiled first, then the rest of the program will be compiled. > > Then different settings will be available in for example a dictionary > called global_settings for the rest of the source code. > > If the dictionary is marked read-only, the compiler can do a replacement > of the get from dictionary code so that the variable value is directly > available, if the dictionary is read-write then it becomes a runtime > configuration. > > -Morten What an interesting idea. It's like encapsulation for source code settings outside of static pragmas, where you can use program logic to determine things. I love it! I will adopt this ability for RDC. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-20 09:09 -0700 |
| Message-ID | <lnegiy2b83.fsf@kst-u.example.com> |
| In reply to | #67879 |
"Morten W. Petersen" <morphex@gmail.com> writes:
[...]
> It was mentioned earlier that configure() would be run before
> compilation.
This already exists, and is very common.
Many software packages have a script called "configure" (not a C
function, though I suppose it could be implemented in C) that can,
for example, generate a C header file containing macro definitions.
The C source code is then compiled using that generated header file.
There's no need to change the language to support pre-compile-time
configuration.
--
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 | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-20 09:08 -0700 |
| Message-ID | <bf834f08-5fe0-4cb0-8f0c-9b1927d12b36@googlegroups.com> |
| In reply to | #67886 |
On Thursday, August 20, 2015 at 11:12:42 AM UTC-4, Keith Thompson wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > [...] > > It was mentioned earlier that configure() would be run before > > compilation. > > This already exists, and is very common. > > Many software packages have a script called "configure" (not a C > function, though I suppose it could be implemented in C) that can, > for example, generate a C header file containing macro definitions. > The C source code is then compiled using that generated header file. > There's no need to change the language to support pre-compile-time > configuration. It's not quite the same thing, Keith. But, serves the same general function. The one Morten is proposing is C code which does this, using features which are added to the compiler for this purpose (a list of functions, defined quantities, etc.). I think it's rather ingenious. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-21 10:15 +0200 |
| Message-ID | <mr6mmf$5qn$1@speranza.aioe.org> |
| In reply to | #67888 |
On 20.08.2015 18:08, Rick C. Hodgin wrote: > On Thursday, August 20, 2015 at 11:12:42 AM UTC-4, Keith Thompson wrote: >> "Morten W. Petersen" <morphex@gmail.com> writes: >> [...] >>> It was mentioned earlier that configure() would be run before >>> compilation. >> >> This already exists, and is very common. >> >> Many software packages have a script called "configure" (not a C >> function, though I suppose it could be implemented in C) that can, >> for example, generate a C header file containing macro definitions. >> The C source code is then compiled using that generated header file. >> There's no need to change the language to support pre-compile-time >> configuration. > > It's not quite the same thing, Keith. But, serves the same general > function. The one Morten is proposing is C code which does this, > using features which are added to the compiler for this purpose (a > list of functions, defined quantities, etc.). I think it's rather > ingenious. :) -Morten
[toc] | [prev] | [next] | [standalone]
Page 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web