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 10 of 12 — ← Prev page 1 … 8 9 [10] 11 12 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-21 02:17 -0700 |
| Message-ID | <df4c4378-a0eb-4ddd-b759-439599348704@googlegroups.com> |
| In reply to | #67925 |
Morten, I was thinking about this implementation
last night. I remembered we have variables like
"_innerhtml" available for programatically generating
HTML source code to render. You could define a
few fixed forms, and then also allow injection by
relative position:
_header_c [prepend, append] = { ... }
_footer_c [prepend, append] = { ... }
inject [[before, after] myFunction()] = { ... }
replace myFunction with { ... }
You could define parts to be variable code parts
by token:
int main(int argc, char* argv[])
{
$startup ...
}
And then in your configure() reference them:
delete $startup
$startup = { ... }
...and so one. A whole host of source code fixup
abilities would be defined.
It's one of the best ideas for C/C++ I've ever heard.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-21 14:23 +0100 |
| Message-ID | <87si7c93n9.fsf@bsb.me.uk> |
| In reply to | #67928 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > Morten, I was thinking about this implementation > last night. I remembered we have variables like > "_innerhtml" available for programatically generating > [...] This appears to be part of a private discussion. If so, it's probably best done by email rather than on comp.lang.c. But if you are implementing this in RDC I think it should be discussed in an RDC forum. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-21 15:44 +0200 |
| Message-ID | <mr79vv$ird$1@speranza.aioe.org> |
| In reply to | #67940 |
On 21.08.2015 15:23, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > >> Morten, I was thinking about this implementation >> last night. I remembered we have variables like >> "_innerhtml" available for programatically generating >> [...] > > This appears to be part of a private discussion. If so, it's probably > best done by email rather than on comp.lang.c. But if you are > implementing this in RDC I think it should be discussed in an RDC forum. It looks like Rick is onto something that can replace macros using standard C stuff (it will compile with a C compiler) so I'm interested in hearing more. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-21 14:59 +0100 |
| Message-ID | <87mvxk91ya.fsf@bsb.me.uk> |
| In reply to | #67941 |
"Morten W. Petersen" <morphex@gmail.com> writes: > On 21.08.2015 15:23, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> >>> Morten, I was thinking about this implementation >>> last night. I remembered we have variables like >>> "_innerhtml" available for programatically generating >>> [...] >> >> This appears to be part of a private discussion. If so, it's probably >> best done by email rather than on comp.lang.c. But if you are >> implementing this in RDC I think it should be discussed in an RDC forum. > > It looks like Rick is onto something that can replace macros using > standard C stuff (it will compile with a C compiler) so I'm interested > in hearing more. Sure, but it appears to be a private discussion. Rick's post quoted no context and referred to things what don't seemed to have been mentioned before making it impenetrable for others. That's, well, let's say annoying, in a public group. That's usually the time to take it to email. It could be I've missed the context because Rick simply replied to the wrong post, and, were I able to know what's being talked about, it may turn out to be topical, but I don't often lose track of a thread in such a complete fashion. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-21 07:03 -0700 |
| Message-ID | <44c30b0a-b56f-464d-b395-81d13571235d@googlegroups.com> |
| In reply to | #67942 |
Ben, Morten's proposal was for C. We are now in idea/discussion mode. Feel free to participate if you have creativity. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-23 21:50 +0200 |
| Message-ID | <mrd82t$7t2$1@dont-email.me> |
| In reply to | #67942 |
On 21/08/15 15:59, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > >> On 21.08.2015 15:23, Ben Bacarisse wrote: >>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >>> >>>> Morten, I was thinking about this implementation >>>> last night. I remembered we have variables like >>>> "_innerhtml" available for programatically generating >>>> [...] >>> >>> This appears to be part of a private discussion. If so, it's probably >>> best done by email rather than on comp.lang.c. But if you are >>> implementing this in RDC I think it should be discussed in an RDC forum. >> >> It looks like Rick is onto something that can replace macros using >> standard C stuff (it will compile with a C compiler) so I'm interested >> in hearing more. > > Sure, but it appears to be a private discussion. Rick's post quoted no > context and referred to things what don't seemed to have been mentioned > before making it impenetrable for others. That's, well, let's say > annoying, in a public group. That's usually the time to take it to email. > > It could be I've missed the context because Rick simply replied to the > wrong post, and, were I able to know what's being talked about, it may > turn out to be topical, but I don't often lose track of a thread in such > a complete fashion. > The fact that many of Rick's posts have no context or quotations is a different issue. I agree it's annoying, rude, against Usenet convention, and can make some threads difficult to follow. But at least he writes in legible English, is generally polite, does not quote without attribution, and wraps his lines properly (which seems to be an effort when using GG). There are worse posters in this group. I think in this case it is just because it is hard to see what all the fuss is about with this "configure()" idea. As far as I can see, it is nothing that you couldn't do with a slightly complex Makefile - but it is not something I would ever dream of doing. (I have had occasion to have build processes that generate C code on the fly, or do unusual pre-processing. But C is not the language for that - a scripting language such as Python is typically a far better choice. And I would never do it for something that can be expressed simply and clearly using normal, conventional and easily understood C idioms.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-21 16:25 +0200 |
| Message-ID | <mr7c92$2ss$1@dont-email.me> |
| In reply to | #67941 |
On 21/08/15 15:44, Morten W. Petersen wrote: > On 21.08.2015 15:23, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> >>> Morten, I was thinking about this implementation >>> last night. I remembered we have variables like >>> "_innerhtml" available for programatically generating >>> [...] >> >> This appears to be part of a private discussion. If so, it's probably >> best done by email rather than on comp.lang.c. But if you are >> implementing this in RDC I think it should be discussed in an RDC forum. > > It looks like Rick is onto something that can replace macros using > standard C stuff (it will compile with a C compiler) so I'm interested > in hearing more. > No, there is nothing in this idea that comes close to replacing macros with "standard C stuff". At best, the idea is to use code written in C to build a custom pre-processor that is run to pre-process the "real" C source file, in addition to using the standard C pre-processor (which is still needed). Could it be used to replace macros by using something only written in "real" C? Yes, of course it could. Should it? No, of course it should not. The C code required for this sort of configuration is ugly, messy, and in every way worse than a simple "#define" would be. The machinery around this in order to extract the configuration functions and do the required pre-processing would be large and complex. The result would give no benefits to anyone other except to remove a few uses of the C pre-processor - at the price of a weird, hard-to-understand and fragile system that almost no one understands, and almost no tools support. There are /far/ better ways of reducing the use of #define's and pre-processor macros, especially if you are willing to be a little flexible in making something non-standard. (For those that want to stick to standards, the obvious method is to use C++.) First, allow "const" values - or at least "static const" values - to be used as compile-time constants. That would eliminate a substantial usage of #define'd values. Second, support some sort of overloading of functions according to parameter type. C only allows this with macros (ironically) using C11 generics. But it is quite possible to extend C to allow overloaded functions - just as Jacob. This would let you replace most function-like macros with static inline functions. If that is not enough, then you need to take a step back and figure out what problem you are actually trying to solve. What is wrong in C as it stands, and how could it be better? What does the existing code look like, and how would you like the new code to look? Remember, Rick has an extraordinary amount of enthusiasm and optimism. He is quick to take new ideas, see a connection (real or imaginary) with something else, and declare that it's the best idea since sliced bread, and will be implemented in RDC. That's just the way he works - he thinks through thinks while implementing them, rather than /before/ implementing them. It seems a strange method to me - just like the edit-while-debugging system he is so fond of - but it seems to suit him, and that's fine. But it also means that just because Rick has started implementing an idea in RDC, it does not mean that it is a good idea, a beneficial idea, or even a possible idea. It just means he thinks it is worth playing with to see if it leads anywhere. And also remember that RDC is significantly different than C. Whether you think that is a good thing or a bad thing is personal opinion (obviously Rick thinks it is good!) - but it is very far from "standard C stuff", and AFAIUI it is a good deal more complex than C. Personally, I don't mind seeing this sort of stuff in comp.lang.c, as long as it is not too detailed in the implementation. With enough ideas flying around, even if they are wild, there can be inspiration to new techniques in real-world C coding. And we are all allowed to dream about our ideal version of C!
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-21 07:34 -0700 |
| Message-ID | <e34b84cc-a89b-4b92-8fef-8a874b6aa9a2@googlegroups.com> |
| In reply to | #67944 |
On Friday, August 21, 2015 at 10:25:25 AM UTC-4, David Brown wrote: > And also remember that RDC is significantly different than C. Whether > you think that is a good thing or a bad thing is personal opinion > (obviously Rick thinks it is good!) - but it is very far from "standard > C stuff", and AFAIUI it is a good deal more complex than C. RDC plans right now to be able to compile C source code with very few changes (if any in most cases). It probably won't generate the exact same functionality at runtime, however, because there are a few rules that I have changed in implementing. However, in the long term I do plan to provide native support for 100% C89 and C99 (and possibly something beyond that, or some extensions of something beyond that, but that is absolutely last on my list of interests). And, for the record, I have made one comment about implementing this in RDC. The rest of my comments have not been RDC-specific, but rather have been specific to flushing out the idea for C or any other language that would use this configure() ability. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-21 20:44 +0100 |
| Message-ID | <mr7v0b$f1o$1@dont-email.me> |
| In reply to | #67928 |
On 21/08/2015 10:17, Rick C. Hodgin wrote:
> Morten, I was thinking about this implementation
> last night. I remembered we have variables like
> "_innerhtml" available for programatically generating
> HTML source code to render. You could define a
> few fixed forms, and then also allow injection by
> relative position:
>
> _header_c [prepend, append] = { ... }
> _footer_c [prepend, append] = { ... }
> inject [[before, after] myFunction()] = { ... }
> replace myFunction with { ... }
>
> You could define parts to be variable code parts
> by token:
>
> int main(int argc, char* argv[])
> {
> $startup ...
> }
>
> And then in your configure() reference them:
>
> delete $startup
> $startup = { ... }
>
> ...and so one. A whole host of source code fixup
> abilities would be defined.
>
> It's one of the best ideas for C/C++ I've ever heard.
It sounds more like another excellent way of writing completely
incomprehensible code!
But I'm guessing the details.
(1) Would the meta-code that generates the real code also be written in
C? If so that's a bad idea, for many reasons. (It would be very
confusing, but what you really need here is a scripting language, which
C isn't.)
(2) If the meta-language is C, would it need its own compiling and link
stages, or would it somehow just be executed via some sort of interpreter?
(3) What is the output of the code-generating language? Will it be just
C source, in the same way that a Javascript section of a HTML file just
generates more HTML? Ie. will the output C just be embedded in the
normal C code?
(4) Would you ever see the generated code? Ie, is the preprocessing a
discrete step where the output is normal C? If not, then it could make
debugging interesting if the code that's being compiled is, effectively,
invisible. (Although this is also a problem with the macro system.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-08-22 14:10 +0000 |
| Message-ID | <55d8825b.19522187@news.xs4all.nl> |
| In reply to | #67960 |
Bartc <bc@freeuk.com> wrote: > On 21/08/2015 10:17, Rick C. Hodgin wrote: > > ...and so one. A whole host of source code fixup > > abilities would be defined. > > > > It's one of the best ideas for C/C++ I've ever heard. > > It sounds more like another excellent way of writing completely > incomprehensible code! > > But I'm guessing the details. Well, that's the problem with most of these suggestions for Grand Improvements to C, isn't it? We're all just guessing the details, often including, I get the impression, those doing the suggesting. It's easy to complain that C Is Wrong. It's easy to suggest Grand Improvements. It turns out to be not nearly so easy to make the improvements _work_. Richard
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-08-17 20:08 +0000 |
| Message-ID | <mqtevg$tmb$2@speranza.aioe.org> |
| In reply to | #67590 |
David Brown <david.brown@hesbynett.no> wrote: (snip) > Thus C has a "+" operator, even though it is unnecessary - you can use > "- -" in most circumstances. But it does not have an operator for > calculating integer powers, even though it might occasionally be useful. Yes. Fortran compilers reliably optimize integer power expressions, such that you can write I**2 or A**3 and be pretty sure that the compiler won't call a slow library routine. Not so easy in C. > And thus C has "while" loops and "for" loops, but not "until" loops or > "repeat" loops. - glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-17 09:33 -0700 |
| Message-ID | <ln4mjx7u3r.fsf@kst-u.example.com> |
| In reply to | #67586 |
"Morten W. Petersen" <morphex@gmail.com> writes:
[...]
> Well, you can construct a for-like loop using while, can't you?
Certainly. Fortunately, you don't have to.
> Bartc illustrates what I was thinking as well, that one can take a
> minimalistic approach to a language in the message with message ID
> <mqsj45$67m$1@dont-email.me>.
>
> Macros with parameters for example, why not have a compiler that
> must support inline? No more complicated macro implementations for
> compiler writers, no more headaches for developers.
Because there are plenty of macros that cannot be expressed as inline
functions. A simple example:
#define MAX(x, y) ((x) > (y) ? (x) : (y))
An inline function would have to specify the type of the arguments.
(Of course the macro has the drawback that one of the arguments
will be evaluated twice.)
> The underlying point here is that the simpler a language is,
> the more time can be spent in other areas, such as how well
> the compiler optimizes. It will also be less complex so that
> all other tasks should receive more focus and attention. This
> way, it would also be easier for developers to take a holistic view
> of the language/compiler as well, which might bring new results
> that probably wouldn't have been found in a more complex system.
Once you've implemented while loops in the compiler, the effort to
implement for loops is minimal. It's not likely to take away any
significant amount of time that would otherwise be spent improving
optimization.
But even if it did, the point is to make it easier to write and
(more importantly) read C code. A typical C for loop:
for (int i = 0; i < MAX; i ++) { /* ... */ }
is easier to write and to read than the equivalent while loop,
where the initialization is above the top of the loop and the "i ++"
is buried at the bottom of the loop body. That expressiveness more
important than a little extra optimization.
> Another cool thing could be that when a function recurses, the
> function must be tail-call optimizable or the compilation will
> fail.
Recursion is a useful tool, and not all recursion is tail-call
optimizable. You're suggesting a severe restriction on the
expressiveness of the language.
If you want a language in which you can't write a straightforward
binary tree traversal algorithm, I suggest calling it something
other than C, and not expecting many people to use it.
> If the language was a strict subset of C for example, one could
> at every turn compare the code that a compiler in the new language
> compiles to for example code that gcc with -O3 creates. That way,
> one can say and document that it is indeed faster when it does
> become faster.
Presumably you'd be comparing it to C code written under the
same restrictions (no for loops, no non-tail recursion, etc.).
There's no reason a full C compiler couldn't optimize such code
just as well as a hypothetical subset-of-C compiler.
--
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 22:20 +0200 |
| Message-ID | <mqtfmb$av$1@speranza.aioe.org> |
| In reply to | #67606 |
On 17.08.2015 18:33, Keith Thompson wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: [...] >> Macros with parameters for example, why not have a compiler that >> must support inline? No more complicated macro implementations for >> compiler writers, no more headaches for developers. > > Because there are plenty of macros that cannot be expressed as inline > functions. A simple example: > > #define MAX(x, y) ((x) > (y) ? (x) : (y)) > > An inline function would have to specify the type of the arguments. > (Of course the macro has the drawback that one of the arguments > will be evaluated twice.) Well, it might not be possible to express a function in exactly the way as a macro, but something equivalent should be possible. [...] >> Another cool thing could be that when a function recurses, the >> function must be tail-call optimizable or the compilation will >> fail. > > Recursion is a useful tool, and not all recursion is tail-call > optimizable. You're suggesting a severe restriction on the > expressiveness of the language. > > If you want a language in which you can't write a straightforward > binary tree traversal algorithm, I suggest calling it something > other than C, and not expecting many people to use it. OK, I'm not so sure about the recursion. On the other hand, it would be impossible (?) to exhaust the stack with such a setup. >> If the language was a strict subset of C for example, one could >> at every turn compare the code that a compiler in the new language >> compiles to for example code that gcc with -O3 creates. That way, >> one can say and document that it is indeed faster when it does >> become faster. > > Presumably you'd be comparing it to C code written under the > same restrictions (no for loops, no non-tail recursion, etc.). > There's no reason a full C compiler couldn't optimize such code > just as well as a hypothetical subset-of-C compiler. Well it would be a good measure and a good argument. And if it turns out it can produce faster code, some of that should can be cross-pollinated to C compilers. -Morten
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-17 17:28 -0400 |
| Message-ID | <55D25210.20306@verizon.net> |
| In reply to | #67625 |
On 08/17/2015 04:20 PM, Morten W. Petersen wrote: > On 17.08.2015 18:33, Keith Thompson wrote: >> "Morten W. Petersen" <morphex@gmail.com> writes: > [...] >>> Macros with parameters for example, why not have a compiler that >>> must support inline? No more complicated macro implementations for >>> compiler writers, no more headaches for developers. >> >> Because there are plenty of macros that cannot be expressed as inline >> functions. A simple example: >> >> #define MAX(x, y) ((x) > (y) ? (x) : (y)) >> >> An inline function would have to specify the type of the arguments. >> (Of course the macro has the drawback that one of the arguments >> will be evaluated twice.) > > Well, it might not be possible to express a function in > exactly the way as a macro, but something equivalent > should be possible. Have you actually thought that through? The key difference between a macro and a function is that the function necessarily has a single specific type for each parameter, and for it's return type. The macro can be used on any two values for x and y for which "x > y" is permitted: "both operands have real type; or both operands are pointers to qualified or unqualified versions of compatible object types." (6.5.8p2). "If both of the operands have arithmetic type, the usual arithmetic conversions are performed." A single C function can't do that. It's only allowed to take arguments that can be implicitly converted to a type compatible with the function parameters. There's no one type that both real types and pointers to arbitrary types can be implicitly converted to. The best you could do is have a long double version for the real types, and a void* version for the pointer types. However, even in that case, the long double version might not have enough precision to correctly represent all values of the type uint_max_t. A more subtle and complicated issue has to do with usual arithmetic conversions (6.3.1.8). The result of using MAX(x,y) will have a type and value that are both determined by the usual arithmetic conversions as applied to x and y, which in turn can affect how expressions containing MAX(x,y) are handled. A function can only have one return type, which will often not be the same type as that returned by MAX(x,y), no matter which type it is. Also, after performing the integer promotions, if MAX() ends up comparing a unsigned value with a signed value of lower integer conversion rank, the signed value is supposed to be converted to the unsigned type; the result of that conversion will be a non-negative number, even if the original value was negative. As a result MAX(-1, 1UL) is ULONG_MAX-1, not 1. It's quite easy to argue that the usual arithmetic conversions don't produce the result that you want - all you have to do is want something different. However, the behavior of MAX(x,y) does depend upon those rules in a certain way, and if someone actually writes code that expects MAX(-1, 1UL) to produce ULONG_MAX-1, they're going to be pretty upset with you if your replacement function doesn't produce the same behavior. ... >>> Another cool thing could be that when a function recurses, the >>> function must be tail-call optimizable or the compilation will >>> fail. >> >> Recursion is a useful tool, and not all recursion is tail-call >> optimizable. You're suggesting a severe restriction on the >> expressiveness of the language. >> >> If you want a language in which you can't write a straightforward >> binary tree traversal algorithm, I suggest calling it something >> other than C, and not expecting many people to use it. I agree - a language that makes binary tree traversal unnecessarily complicated would be fairly unattractive to a lot of people, myself included. > OK, I'm not so sure about the recursion. On the other hand, > it would be impossible (?) to exhaust the stack with such a setup. Why? If you have a maximum stack size, it's generally feasible to write code that will exhaust that stack. Recursion makes it easy to write such code, but outlawing recursion won't make it impossible to write it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-17 16:42 -0700 |
| Message-ID | <lnwpwt4h43.fsf@kst-u.example.com> |
| In reply to | #67634 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 08/17/2015 04:20 PM, Morten W. Petersen wrote:
>> On 17.08.2015 18:33, Keith Thompson wrote:
>>> "Morten W. Petersen" <morphex@gmail.com> writes:
>> [...]
>>>> Macros with parameters for example, why not have a compiler that
>>>> must support inline? No more complicated macro implementations for
>>>> compiler writers, no more headaches for developers.
>>>
>>> Because there are plenty of macros that cannot be expressed as inline
>>> functions. A simple example:
>>>
>>> #define MAX(x, y) ((x) > (y) ? (x) : (y))
>>>
>>> An inline function would have to specify the type of the arguments.
>>> (Of course the macro has the drawback that one of the arguments
>>> will be evaluated twice.)
>>
>> Well, it might not be possible to express a function in
>> exactly the way as a macro, but something equivalent
>> should be possible.
>
> Have you actually thought that through? The key difference between a
> macro and a function is that the function necessarily has a single
> specific type for each parameter, and for it's return type.
[...]
Mostly true. Variadic functions (like printf) can take arguments
of varying types. But even so, the return type is fixed, so you
can't write a max() function that's anywhere near as convenient as
the macro.
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-17 19:39 -0400 |
| Message-ID | <55D270C9.6090606@verizon.net> |
| In reply to | #67652 |
On 08/17/2015 07:42 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 08/17/2015 04:20 PM, Morten W. Petersen wrote:
>>> On 17.08.2015 18:33, Keith Thompson wrote:
>>>> "Morten W. Petersen" <morphex@gmail.com> writes:
>>> [...]
>>>>> Macros with parameters for example, why not have a compiler that
>>>>> must support inline? No more complicated macro implementations for
>>>>> compiler writers, no more headaches for developers.
>>>>
>>>> Because there are plenty of macros that cannot be expressed as inline
>>>> functions. A simple example:
>>>>
>>>> #define MAX(x, y) ((x) > (y) ? (x) : (y))
>>>>
>>>> An inline function would have to specify the type of the arguments.
>>>> (Of course the macro has the drawback that one of the arguments
>>>> will be evaluated twice.)
>>>
>>> Well, it might not be possible to express a function in
>>> exactly the way as a macro, but something equivalent
>>> should be possible.
>>
>> Have you actually thought that through? The key difference between a
>> macro and a function is that the function necessarily has a single
>> specific type for each parameter, and for it's return type.
> [...]
>
> Mostly true. Variadic functions (like printf) can take arguments
> of varying types. But even so, the return type is fixed, so you
> can't write a max() function that's anywhere near as convenient as
> the macro.
I hadn't thought about that. The macro would be immensely simpler, but a
variadic function could be defined to match the behavior of the macro.
int max_func(const char *format, ...);
Where format must contain three format specifiers, using the same rules
as for the printf/scanf family to specify arithmetic types or void*.
The first and second specifiers specify the type of the second and third
arguments, respectively; the third specifier specifies the type that the
fourth argument points at. It would return error codes if anything's
wrong with the format string. Given
int x;
long y;
long z;
then
z = MAX(x,y);
could be replaced by
if(max_func("%d%ld%ld", x, y, &z))
{
// error handling.
}
The body of max_fun would be huge, mainly by reason of having to cover a
large number of different combinations of types. I don't see any
advantage to this - it's excessively complicated in many different ways
- but I can at least say that it's feasible. Without using a variadic
function, there's no way to fully match the macro's flexibility with
regards to type.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-17 16:15 -0700 |
| Message-ID | <ln614d5wws.fsf@kst-u.example.com> |
| In reply to | #67625 |
"Morten W. Petersen" <morphex@gmail.com> writes:
> On 17.08.2015 18:33, Keith Thompson wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
> [...]
>>> Macros with parameters for example, why not have a compiler that
>>> must support inline? No more complicated macro implementations for
>>> compiler writers, no more headaches for developers.
>>
>> Because there are plenty of macros that cannot be expressed as inline
>> functions. A simple example:
>>
>> #define MAX(x, y) ((x) > (y) ? (x) : (y))
>>
>> An inline function would have to specify the type of the arguments.
>> (Of course the macro has the drawback that one of the arguments
>> will be evaluated twice.)
>
> Well, it might not be possible to express a function in
> exactly the way as a macro, but something equivalent
> should be possible.
You can write a max function that works on ints, and another that works
on longs and another that works on doubles, and ... -- and each would
have to have a distinct name. That's about as close as you can get
without using a macro.
> [...]
>>> Another cool thing could be that when a function recurses, the
>>> function must be tail-call optimizable or the compilation will
>>> fail.
>>
>> Recursion is a useful tool, and not all recursion is tail-call
>> optimizable. You're suggesting a severe restriction on the
>> expressiveness of the language.
>>
>> If you want a language in which you can't write a straightforward
>> binary tree traversal algorithm, I suggest calling it something
>> other than C, and not expecting many people to use it.
>
> OK, I'm not so sure about the recursion. On the other hand,
> it would be impossible (?) to exhaust the stack with such a setup.
Having a optional *warning* for non-tail-optimizable recursion would
be reasonable. There are coding standards (typically for embedded
systems requiring very high reliability) that forbid recursion. But
removing it from the language would IMHO be a huge step backwards.
>>> If the language was a strict subset of C for example, one could
>>> at every turn compare the code that a compiler in the new language
>>> compiles to for example code that gcc with -O3 creates. That way,
>>> one can say and document that it is indeed faster when it does
>>> become faster.
>>
>> Presumably you'd be comparing it to C code written under the
>> same restrictions (no for loops, no non-tail recursion, etc.).
>> There's no reason a full C compiler couldn't optimize such code
>> just as well as a hypothetical subset-of-C compiler.
>
> Well it would be a good measure and a good argument. And if
> it turns out it can produce faster code, some of that should
> can be cross-pollinated to C compilers.
Sure, any new compiler might optimize better than existing ones in some
cases, but I don't see how restricting the language would make that
significantly easier or more likely. Existing C compilers include a
*lot* of work on code optimization.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-18 00:19 +0100 |
| Message-ID | <87y4h9cxka.fsf@bsb.me.uk> |
| In reply to | #67625 |
"Morten W. Petersen" <morphex@gmail.com> writes: > On 17.08.2015 18:33, Keith Thompson wrote: >> "Morten W. Petersen" <morphex@gmail.com> writes: <snip> > [...] >>> Another cool thing could be that when a function recurses, the >>> function must be tail-call optimizable or the compilation will >>> fail. >> >> Recursion is a useful tool, and not all recursion is tail-call >> optimizable. You're suggesting a severe restriction on the >> expressiveness of the language. >> >> If you want a language in which you can't write a straightforward >> binary tree traversal algorithm, I suggest calling it something >> other than C, and not expecting many people to use it. > > OK, I'm not so sure about the recursion. On the other hand, > it would be impossible (?) to exhaust the stack with such a setup. A program can run out of stack from non-recursive function calls (that's been said already), but your restriction of permitting only tail recursive calls is hard to implement. Two (or more) mutually recursive functions (possible in separate translation units) will be hard to detect. (And, of course, recursion is a Good Thing. For example your XML structure would be much harder to parse and traverse if only tail calls are permitted. This is true of tree structures generally.) <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-08-17 08:32 -0400 |
| Message-ID | <TvkAx.24$h_1.12@fx29.iad> |
| In reply to | #67577 |
On 8/17/15 7:34 AM, Stefan Ram wrote:
> Bartc <bc@freeuk.com> writes:
>> That is also an odd attitude. So we go out of our way to eliminate a
>> construct that makes code easier to read, involves less typing and is
>> less error-prone, for what reason exactly?
>
> In my C courses, there always is too little time. So, I was
> thinking about how to simplify C. I came up with an omission
> of »for«, because one already can program all loops with
> »while« alone, and »for« is just an abbreviation.
for is NOT just an abbreviation.
It might first seem that you can convert
for(A; B; C) { D; }
into
A;
while(B) {
D;
C;
}
but if D contains a continue statement behavior changes, so you need to
add a label for C and convert continue to goto.
>
> But soon I observed that, whenever I wanted to show how to
> solve an exercise with a loop, I first typed »for«. Then, I
> remembered that so far I only had introduced »while« and
> edited that »for« to »while«.
>
> Eventually, I learned that I seem to have a strong
> preference for using »for« instead of while in many cases,
> so I thought that there must be something about »for« that
> appeals to my mind. So, I though that the participiants
> might like »for«, too, and that I should re-integrate »for«
> into the course.
>
> However, sometimes there is so little time, that the course
> just ends with »while«. But I try to also teach »for«, whenever
> this is possible, soon after the introduction of »while«.
>
Any course that claims to be "Teaching C" that doesn't at least touch on
all of for, while, and do while, is doing the students an extreme
disservice. (Maybe a course that only last a total of a few hours, and
only claims to be an overview could get away with something like this).
It also shouldn't take much time, at the point when you get to them in
the course, you spend a few minutes showing all three, and talk briefly
about their similarities and differences. You then can go into more
depth on one of them (sounds like in your case for),
Unless you are intentionally avoiding teaching the goto statement (which
I think would be a mistake) showing how you would write each loop with
an if and gotos (with labels for where continue and break goto). This
also gives a hook to start to describe why we want to avoid using gotos
but prefer to use more structured constructs.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-17 18:02 +0100 |
| Message-ID | <878u99etl9.fsf@bsb.me.uk> |
| In reply to | #67585 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 8/17/15 7:34 AM, Stefan Ram wrote:
>> Bartc <bc@freeuk.com> writes:
>>> That is also an odd attitude. So we go out of our way to eliminate a
>>> construct that makes code easier to read, involves less typing and is
>>> less error-prone, for what reason exactly?
>>
>> In my C courses, there always is too little time. So, I was
>> thinking about how to simplify C. I came up with an omission
>> of »for«, because one already can program all loops with
>> »while« alone, and »for« is just an abbreviation.
>
> for is NOT just an abbreviation.
>
> It might first seem that you can convert
>
> for(A; B; C) { D; }
>
> into
>
> A;
> while(B) {
> D;
> C;
> }
>
> but if D contains a continue statement behavior changes, so you need
> to add a label for C and convert continue to goto.
This comes close:
{ A;
if (B)
do { D;
} while ((C), B);
}
though I would not vouch for all corner cases. You need the extra {}s
round the whole thing (in your example as well) to handle declaration
scope.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 10 of 12 — ← Prev page 1 … 8 9 [10] 11 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web