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 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2015-08-22 08:25 +0200 |
| Message-ID | <2e5gtadnv71ql8sltu3isjf47mfhptqqi4@4ax.com> |
| In reply to | #67577 |
On 17 Aug 2015 11:34:00 GMT, ram@zedat.fu-berlin.de wrote: >Bartc <bc@freeuk.com> writes: >>That is also an odd attitude. So we go out of our way to eliminate a >>construct that makes code easier to read, involves less typing and is >>less error-prone, for what reason exactly? > > In my C courses, there always is too little time. So, I was > thinking about how to simplify C. I came up with an omission > of »for«, because one already can program all loops with > »while« alone, and »for« is just an abbreviation. > > But soon I observed that, whenever I wanted to show how to > solve an exercise with a loop, I first typed »for«. Then, I > remembered that so far I only had introduced »while« and > edited that »for« to »while«. > > Eventually, I learned that I seem to have a strong > preference for using »for« instead of while in many cases, > so I thought that there must be something about »for« that > appeals to my mind. So, I though that the participiants > might like »for«, too, and that I should re-integrate »for« > into the course. > > However, sometimes there is so little time, that the course > just ends with »while«. But I try to also teach »for«, whenever > this is possible, soon after the introduction of »while«. i instead thought to take for(;;) and to leave while() i invece ho pensato meglio: prendere for(;;) e lasciare while() and goes all well because with for() the loop is more easy to think
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-17 14:46 +0200 |
| Message-ID | <mqsl03$d3l$1@dont-email.me> |
| In reply to | #67575 |
On 17/08/15 12:40, Morten W. Petersen wrote: > On 17.08.2015 12:27, Bartc wrote: >> On 17/08/2015 02:47, glen herrmannsfeldt wrote: > [...] >> That sounds rather perverse. How you thought about whether that makes it >> easier or harder for the readers of your code? >> >> I've just looked at some of my code and I use many hundreds of while >> statements, each of which exactly represents what I'm trying to express. >> Example: >> >> while(a<b) a=a*2; >> >> I can't really see that it helps matters by writing it as: >> >> for (;a<b;a=a*2); >> >> Here, the original intention has to be reconstructed in the mind of the >> reader. And it's also now position dependent; change the phase of the >> semicolons: >> >> for (a<b;a=a*2;); >> >> and it looks almost identical, it still compiles, but it's completely >> wrong. This phase-checking is something else that needs to be done in >> the mind of the reader. > > Misplaced commas, semicolons etc. are something that can pop up in code, > is it better to learn how to avoid, spot and handle those or be > "nannied" with a loop construct that is a bit easier on the eyes? > It is best to write code that is clear easily understood, preferably by a range of "typical" programmers (you never know who will have to understand or maintain your code in the future). And it is best to write code in such a way that small typos and visually small changes are syntax errors, or can be caught by static error checking by the compiler/linter. Writing "harder" code, in order to force people to "learn to do it properly", is just silly. I expect that Glen has written for loops like "for (;a<b;a=a*2);" so often that they are clear and easily understood by /him/ - and thus he doesn't see it as a problem. Most programmers, at least those who work mostly alone or within the same small group, have habits that make perfect sense to them but are not immediately clear to other programmers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-17 09:45 -0700 |
| Message-ID | <lnzj1p6ez1.fsf@kst-u.example.com> |
| In reply to | #67574 |
Bartc <bc@freeuk.com> writes:
> On 17/08/2015 02:47, glen herrmannsfeldt wrote:
[...]
>> I pretty much never write while loops. If I have logic that would
>> need one, I write the matching for loop instead.
>
> That sounds rather perverse. How you thought about whether that makes it
> easier or harder for the readers of your code?
I agree, but ...
> I've just looked at some of my code and I use many hundreds of while
> statements, each of which exactly represents what I'm trying to express.
> Example:
>
> while(a<b) a=a*2;
>
> I can't really see that it helps matters by writing it as:
>
> for (;a<b;a=a*2);
Why did you put the "a=a*2" in the header of the for loop?
If I wanted (for whatever reason) to write that using a for loop, I'd
probably write:
for (;a < b;) {
a = a * 2;
}
which is much closer in appearance to:
while (a < b) {
a = a * 2;
}
In a language that has a C-style for loop but no while loop, omitting
the first and third items in the loop header would be a common idiom.
It would be tempting to create a macro:
#define WHILE(cond) for(;cond;)
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-17 18:55 +0100 |
| Message-ID | <mqt740$pel$1@dont-email.me> |
| In reply to | #67607 |
On 17/08/2015 17:45, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: >> On 17/08/2015 02:47, glen herrmannsfeldt wrote: > [...] >>> I pretty much never write while loops. If I have logic that would >>> need one, I write the matching for loop instead. >> >> That sounds rather perverse. How you thought about whether that makes it >> easier or harder for the readers of your code? > > I agree, but ... > >> I've just looked at some of my code and I use many hundreds of while >> statements, each of which exactly represents what I'm trying to express. >> Example: >> >> while(a<b) a=a*2; >> >> I can't really see that it helps matters by writing it as: >> >> for (;a<b;a=a*2); > > Why did you put the "a=a*2" in the header of the for loop? Why not? It's the sort of thing that would be done by people who like to cram everything into a for-loop. What exactly belongs in that third part of a for-loop anyway? 'a' is being tested as the exit condition, and it is a that is being updated to its next value. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-17 12:11 -0700 |
| Message-ID | <lnvbcd687j.fsf@kst-u.example.com> |
| In reply to | #67610 |
Bartc <bc@freeuk.com> writes:
> On 17/08/2015 17:45, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>>> On 17/08/2015 02:47, glen herrmannsfeldt wrote:
>> [...]
>>>> I pretty much never write while loops. If I have logic that would
>>>> need one, I write the matching for loop instead.
>>>
>>> That sounds rather perverse. How you thought about whether that makes it
>>> easier or harder for the readers of your code?
>>
>> I agree, but ...
>>
>>> I've just looked at some of my code and I use many hundreds of while
>>> statements, each of which exactly represents what I'm trying to express.
>>> Example:
>>>
>>> while(a<b) a=a*2;
>>>
>>> I can't really see that it helps matters by writing it as:
>>>
>>> for (;a<b;a=a*2);
>>
>> Why did you put the "a=a*2" in the header of the for loop?
>
> Why not? It's the sort of thing that would be done by people who like to
> cram everything into a for-loop.
How did "people who like to cram everything into a for-loop" enter
into the discussion? It almost seems as if you're trying to make
the for loop as terse and obscure as possible to make some point
about C's for loops.
> What exactly belongs in that third part of a for-loop anyway? 'a' is
> being tested as the exit condition, and it is a that is being updated to
> its next value.
It's hard to see the intent without more context, but the behavior of
the original while loop:
while(a<b) a=a*2;
is to double a zero or more times until it equals or exceeds the
value of b. For example, it might be used to compute the smallest
power of two whose value is at least that of b (if the initial
value of a is 1). The value of a would then be used after the end
of the loop (unlike a typical
for (i = 0; i < N; i ++)
loop where the value of i is usually used only within the loop).
If that's the intent, then IMHO the while loop is the clearest way to
write it in C (though I'd write `a *= 2;` rather than `a=a*2;`), and
the equivalent for loop is most clearly written with the same body.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-17 23:07 +0100 |
| Message-ID | <mqtlsm$tro$1@dont-email.me> |
| In reply to | #67612 |
On 17/08/2015 20:11, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: >> On 17/08/2015 17:45, Keith Thompson wrote: >>> Bartc <bc@freeuk.com> writes: >>>> On 17/08/2015 02:47, glen herrmannsfeldt wrote: >>> [...] >>>>> I pretty much never write while loops. If I have logic that would >>>>> need one, I write the matching for loop instead. >>>> >>>> That sounds rather perverse. How you thought about whether that makes it >>>> easier or harder for the readers of your code? >>> >>> I agree, but ... >>> >>>> I've just looked at some of my code and I use many hundreds of while >>>> statements, each of which exactly represents what I'm trying to express. >>>> Example: >>>> >>>> while(a<b) a=a*2; >>>> >>>> I can't really see that it helps matters by writing it as: >>>> >>>> for (;a<b;a=a*2); >>> >>> Why did you put the "a=a*2" in the header of the for loop? >> >> Why not? It's the sort of thing that would be done by people who like to >> cram everything into a for-loop. > > How did "people who like to cram everything into a for-loop" enter > into the discussion? It almost seems as if you're trying to make > the for loop as terse and obscure as possible to make some point > about C's for loops. Here's a case in point, from earlier in the thread: On 17/08/2015 02:47, glen herrmannsfeldt wrote: > for(n=1; fgets( ... ) ; n++) ... n isn't a loop index as normally understood, and plays no part in terminating the loop. So what's it doing in the for-loop 'header'? As I said, people who are keen on doing everything with for-loops seem to like to do as much as possible within the header. So there's this extra problem when it tries to do the job of a while loop: the temptation to squeeze it all into header. (BTW this example was made up but a very similar one appears on page 10 of K&R2; it uses a while loop.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-17 15:13 -0700 |
| Message-ID | <612b1798-e484-47dc-b617-8b07d1ea68c5@googlegroups.com> |
| In reply to | #67640 |
Bartc wrote: > On 17/08/2015 02:47, glen herrmannsfeldt wrote: > > for(n=1; fgets( ... ) ; n++) ... > > n isn't a loop index as normally understood, > and plays no part in terminating the loop. > So what's it doing in the for-loop 'header'? It's related to the iteration, associated with it, and directly couple to it. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-08-17 22:56 +0000 |
| Message-ID | <mqtorb$jk7$1@speranza.aioe.org> |
| In reply to | #67640 |
Bartc <bc@freeuk.com> wrote:
> On 17/08/2015 20:11, Keith Thompson wrote:
(snip)
>> How did "people who like to cram everything into a for-loop" enter
>> into the discussion? It almost seems as if you're trying to make
>> the for loop as terse and obscure as possible to make some point
>> about C's for loops.
> Here's a case in point, from earlier in the thread:
(snip, I previously wrote)
>>> for(n=1; fgets( ... ) ; n++) ...
> n isn't a loop index as normally understood, and plays no part in
> terminating the loop. So what's it doing in the for-loop 'header'?
But it is a loop index, at least as I normally understand it.
I do remember, not so long after I started learning Fortran, that
PL/I has a DO loop where TO is optional. You can write:
DO N=1 BY 1;
GET LIST(X(I));
IF X(I) < 0 THEN GOTO OUT;
END;
OUT:;
(They may have added something like BREAK, they didn't have it 40
years ago.)
> As I said, people who are keen on doing everything with for-loops seem
> to like to do as much as possible within the header. So there's this
> extra problem when it tries to do the job of a while loop: the
> temptation to squeeze it all into header.
I try to make sure that the loop parts are related to the
function of the loop.
> (BTW this example was made up but a very similar one appears on page 10
> of K&R2; it uses a while loop.)
-- glen
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-08-17 20:04 +0000 |
| Message-ID | <mqteof$tmb$1@speranza.aioe.org> |
| In reply to | #67574 |
Bartc <bc@freeuk.com> wrote:
(snip on to while or not to while, I wrote)
>> I pretty much never write while loops. If I have logic that would
>> need one, I write the matching for loop instead.
> That sounds rather perverse. How you thought about whether that makes it
> easier or harder for the readers of your code?
> I've just looked at some of my code and I use many hundreds of while
> statements, each of which exactly represents what I'm trying to express.
> Example:
> while(a<b) a=a*2;
> I can't really see that it helps matters by writing it as:
> for (;a<b;a=a*2);
It doesn't happen all that often to me, but more likely:
for (;a<b;) a=a*2;
> Here, the original intention has to be reconstructed in the mind of the
> reader. And it's also now position dependent; change the phase of the
> semicolons:
> for (a<b;a=a*2;);
No, that never happens to me.
> and it looks almost identical, it still compiles, but it's completely
> wrong. This phase-checking is something else that needs to be done in
> the mind of the reader.
>> But as always, write the most readable form. I have done:
>> for(n=1; fgets( ... ) ; n++) ...
>> so that n counts the lines, (well, fgetss) as another example.
> And this is a perfect example. It took me quite a few extra seconds to
> establish that that this wasn't a normal interating loop (helped by your
> comment and the context; encountered in normal code I wouldn't have
> those cues).
Not sure what is normal or not, but not so far from normal.
> This would not be necessary if written as:
> nlines=0;
> while (fgets()) {
> ++nlines;
> ....
> }
But as with other loops, it does have an initialization and
increment step, so why not use the for the way it is supposed
to be used.
Now, I and some others have wondered why no traditional loop
like the Fortran or PL/I DO loop.
I might have sometimes accidentally written:
for(i=0; j<10; i++) ...
and wondered why it didn't work.
PL/I has a loop like:
DO I=1 BY 1;
PUT SKIP LIST(I);
END;
similar to the C: for(i=1; ; i++) ...
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-13 14:46 +0100 |
| Message-ID | <87io8j47yo.fsf@bsb.me.uk> |
| In reply to | #67252 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Wednesday, August 12, 2015 at 5:41:42 PM UTC-4, Ben Bacarisse wrote: >> ... The argument is over the fact that you advocate using a union when >> you mean a type conversion from one type to another. > > Well, Ben... I know you interpret what I mean under the context of the > understanding you have about what you think I mean, but you are doing > so with values placed in areas where I do not have values, and you are > doing so with no values placed in areas where I do have values. As > such, we will never see eye-to-eye on this until one or more of us > changes... But, that being said... > > I do not mean type conversion. Yes, I know. That's exactly why you are wrong. You *should* mean conversion because that's what's required here. You are proposing an alternative to conversion that is not really an alternative. Yes, your suggestion works (on the systems you care about) because the same bit pattern gives the right value for both pointer types, and the union therefore gets you round the type system, but the whole thing involves an otherwise unnecessary type and is, in effect, a tiny lie. It will complicate the code and will make a reader wonder what else you might be doing that's a bit hacky. > I mean there is a pointer pointing to > a location in memory where data has been arranged a particular way. > The data exists. And the pointer can enter in to wherever it's used > via any form of carrier, yet in the end, that pointer always points > back to the start of that block of data, regardless of whether it's > assigned to a void*, struct xyz*, int*, or any other form of pointer. > This is the requirement of what I consider to be a proper C standard, > and a proper machine architecture. Yes, I know. You don't think pointers values should ever need converting -- the bits are enough. Readers of your code who know C will sit up and take note. They will start looking for other things you might be assuming are true about "proper C". <snip> > In any event, barring answering questions, this is my final post on the > matter. And I really am shocked that there are people purporting to > write code in such a way when it will only make a difference on the > smallest fringe architectures that most developers will never see. You keep saying this, presumably because you have no response to the other argument -- that the code is a lie. Rather than writing what you mean, you take advantage of a special case and re-interpret the bits. Do you do this when you want to convert an unsigned into to a signed int? I'm guessing you don't. You certainly can't do it for int and float because it simply doesn't work on *any* system. <snip> > I really am shocked at the thinking. To me it is completely backwards, > and not as it should be. Yes I am sure you are socked, but have you found anyone who agrees with you? If not (and I've never seem this hack advocated before) you might want to see if you can find any merit in the conventional wisdom so as to temper your certainly that everyone else is wrong. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-13 07:33 -0700 |
| Message-ID | <96335872-03b2-4cae-b3dd-59ffe5424db7@googlegroups.com> |
| In reply to | #67291 |
On Thursday, August 13, 2015 at 9:46:33 AM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > > On Wednesday, August 12, 2015 at 5:41:42 PM UTC-4, Ben Bacarisse wrote: > >> ... The argument is over the fact that you advocate using a union when > >> you mean a type conversion from one type to another. > > > > Well, Ben... I know you interpret what I mean under the context of the > > understanding you have about what you think I mean, but you are doing > > so with values placed in areas where I do not have values, and you are > > doing so with no values placed in areas where I do have values. As > > such, we will never see eye-to-eye on this until one or more of us > > changes... But, that being said... > > > > I do not mean type conversion. > > Yes, I know. That's exactly why you are wrong. You *should* mean > conversion because that's what's required here. You are proposing an > alternative to conversion that is not really an alternative. My proposal is a change to the C standard so that all pointers are the same size, and their underlying bits reflect an address in memory, and are therefore completely interchangeable with no ill side effects, as per the standard. If there are machine architectures which do not adhere to this requirement, they can either work-around it by doing whatever fixup is required to allow the C developer to write code which assumes all pointers are the same size, and the underlying bits do reflect an address, or issue warnings or even errors on use. I'm wanting a change because I look at what the hardware is doing, should be doing, and will likely be doing from this point forward on all new or modern architectures. Best regards Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-13 16:39 +0200 |
| Message-ID | <mqia3k$lpu$1@dont-email.me> |
| In reply to | #67296 |
On 13/08/15 16:33, Rick C. Hodgin wrote: > On Thursday, August 13, 2015 at 9:46:33 AM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> >>> On Wednesday, August 12, 2015 at 5:41:42 PM UTC-4, Ben Bacarisse wrote: >>>> ... The argument is over the fact that you advocate using a union when >>>> you mean a type conversion from one type to another. >>> >>> Well, Ben... I know you interpret what I mean under the context of the >>> understanding you have about what you think I mean, but you are doing >>> so with values placed in areas where I do not have values, and you are >>> doing so with no values placed in areas where I do have values. As >>> such, we will never see eye-to-eye on this until one or more of us >>> changes... But, that being said... >>> >>> I do not mean type conversion. >> >> Yes, I know. That's exactly why you are wrong. You *should* mean >> conversion because that's what's required here. You are proposing an >> alternative to conversion that is not really an alternative. > > My proposal is a change to the C standard so that all pointers are the > same size, and their underlying bits reflect an address in memory, and > are therefore completely interchangeable with no ill side effects, as > per the standard. If there are machine architectures which do not > adhere to this requirement, they can either work-around it by doing > whatever fixup is required to allow the C developer to write code > which assumes all pointers are the same size, and the underlying bits > do reflect an address, or issue warnings or even errors on use. > > I'm wanting a change because I look at what the hardware is doing, > should be doing, and will likely be doing from this point forward on > all new or modern architectures. > 1) Such changes are never going to happen. 2) Even if such changes are realistic, they will not have a backward effect on existing code, compilers or C standards. And they would not help the original poster in any way. 3) The changes /do/ /not/ /matter/. It is irrelevant that the sizes of the pointers are the same - the code should /still/ be a conversion of types. The compiler does not need to generate any code for this conversion, but it is still a conversion. An x86 compiler today does not generate any code here - all your proposed change to the standard would do is guarantee that there is no need for generated code. The /conversion/ is a type conversion, and it is still needed.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-13 19:20 +0100 |
| Message-ID | <87k2sz2fqj.fsf@bsb.me.uk> |
| In reply to | #67296 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Thursday, August 13, 2015 at 9:46:33 AM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> >> > On Wednesday, August 12, 2015 at 5:41:42 PM UTC-4, Ben Bacarisse wrote: >> >> ... The argument is over the fact that you advocate using a union when >> >> you mean a type conversion from one type to another. >> > >> > Well, Ben... I know you interpret what I mean under the context of the >> > understanding you have about what you think I mean, but you are doing >> > so with values placed in areas where I do not have values, and you are >> > doing so with no values placed in areas where I do have values. As >> > such, we will never see eye-to-eye on this until one or more of us >> > changes... But, that being said... >> > >> > I do not mean type conversion. >> >> Yes, I know. That's exactly why you are wrong. You *should* mean >> conversion because that's what's required here. You are proposing an >> alternative to conversion that is not really an alternative. > > My proposal is a change to the C standard [...] Knock yourself out. It won't be happen. But it sounded for all the world like you were suggesting an alternative to a cast that someone using the language as it is currently defined should use. Provided that's *not* what you are proposing, we're good. (I doubt I'd care about very much about anything you want to change about C, just as I doubt I'd care much about any UN resolutions you want to get passed. I may not agree with them, but it's as much a waste of my time arguing about them as it of yours to propose them.) <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-13 11:55 -0700 |
| Message-ID | <6d2e77cc-4ba5-4c58-96ca-e40876ac31a1@googlegroups.com> |
| In reply to | #67322 |
On Thursday, August 13, 2015 at 2:41:33 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > My proposal is a change to the C standard [...]
>
> Knock yourself out. It won't be happen.
I know. It will be supplanted as the horse drawn carriage was,
then relegated to nights out on the town for couples, and some
displays at old technology festivals.
"And here's where you see developers using a command line to
compile programs written in an ancient language, called C."
"Why'd they call it C, teacher?"
"There was a language before that called B, and C took many of
its traits from B."
"Why'd they call that language B, teacher?"
"Well we're not sure. It was made by Bell Labs, and had some
ties to something called BCPL. It may be short for one of
those."
"B? C? Why didn't they give their languages a real name,
teacher, and not just a letter?"
"That's a good question, Billy. I think maybe they were
limited on RAM and disk space back in those early days. Okay,
class, let's move along to the next exhibit. We don't want to
keep others from having their chance to see C. Oh! Look there.
I made a funny."
"Yeah. That was a good one, teacher."
"Thank you, Billy."
-----
And did you read this part in one of my replies?
"And, since I'm working on my own compiler, it's not really an
issue because I see very clearly that C will never change ...
It's just the way it is..."
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-13 21:11 +0100 |
| Message-ID | <87r3n70w3f.fsf@bsb.me.uk> |
| In reply to | #67326 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Thursday, August 13, 2015 at 2:41:33 PM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> > My proposal is a change to the C standard [...] >> >> Knock yourself out. It won't be happen. > > I know. It will be supplanted as the horse drawn carriage was, > then relegated to nights out on the town for couples, and some > displays at old technology festivals. What is the "it"? C? I think C is over-used; and it's often used for quasi-emotional reasons. C is sometimes seen as the language that "real programmers" use (something a bit like "real men" -- the programming equivalent of swinging a big axe) whilst also being simple enough for beginners to learn. I suspect (with, I freely, admit little evidence) that many buggy bits of software are born from this unfortunate perception. For many tasks there are better languages, but I doubt that C will be totally supplanted any time soon. It occupies a particular niche in the language ecosystem, due, in part, to some of the things you don't like about it. Ironically, it's partly because people like you continue to use it that it won't be supplanted. Could you not think of a better language to use? <snip> > And did you read this part in one of my replies? > > "And, since I'm working on my own compiler, it's not really an > issue because I see very clearly that C will never change ... > It's just the way it is..." Yes, I did. You've said that many times. I think it's an excellent plan, but I hope you are planning to write the RDC compiler in RDC, then you won't have any reason to devise new C hacks. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-13 15:15 -0700 |
| Message-ID | <957af91f-cefa-4fd7-88d1-9f4985d64117@googlegroups.com> |
| In reply to | #67335 |
On Thursday, August 13, 2015 at 4:31:09 PM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > > On Thursday, August 13, 2015 at 2:41:33 PM UTC-4, Ben Bacarisse wrote: > >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > >> > My proposal is a change to the C standard [...] > >> > >> Knock yourself out. It won't be happen. > > > > I know. It will be supplanted as the horse drawn carriage was, > > then relegated to nights out on the town for couples, and some > > displays at old technology festivals. > > What is the "it"? An indefinite pronoun. > C? The third letter of the English alphabet. > I think C is over-used; I think E is over-used. > and it's often used for > quasi-emotional reasons. "C"rying, for example, though I would liken that to a real emotional state, though the underlying cause(s) of the tears could stem from quasi-real reasons... but I digress. > C is sometimes seen as the language that "real > programmers" use (something a bit like "real men" -- the programming > equivalent of swinging a big axe) whilst also being simple enough for > beginners to learn. I suspect (with, I freely, admit little evidence) > that many buggy bits of software are born from this unfortunate > perception. I was with you, and then you lost me at "many buggy bits." > For many tasks there are better languages, but I doubt that C will be > totally supplanted any time soon. It occupies a particular niche in the > language ecosystem, due, in part, to some of the things you don't like > about it. Ironically, it's partly because people like you continue to > use it that it won't be supplanted. I use it because I don't have a choice. It is a particular flavor of a language I haven't seen elsewhere, close to hardware, yet not overrun by it, and to my knowledge there isn't a better language for what C does. It just needs some tweaking (says Rick from an assembly background where real freedom is found, along with a tremendous amount of typing). > Could you not think of a better > language to use? I could think of a better language to use: RDC. It's just that at the time it hadn't been invented yet. And even now, it's still largely on the drawing board ... but strides are being made. > <snip> > > And did you read this part in one of my replies? > > > > "And, since I'm working on my own compiler, it's not really an > > issue because I see very clearly that C will never change ... > > It's just the way it is..." > > Yes, I did. You've said that many times. I think it's an excellent > plan, but I hope you are planning to write the RDC compiler in RDC, then > you won't have any reason to devise new C hacks. Did I really devise a "new C hack?" Why, I had no idea! Is there money in that? Maybe I could apply for a patent. Seriously though ... it is actually my goal. I intend to write RDC in my incorrect C/C++ usage on a machine that supports it correctly, until I get the source code to the point where RDC is sufficiently developed to essentially bootstrap itself. Then I'll switch over, and never look back. ----- You may find this interesting as well, Ben: I also plan for RDC to provide eventual full compliance with the C standard versions (at least up to C99), by using a compiler switch, enabling those people who wish to migrate their C code away from the confines of C, to swim instead the warm seas of coding freedom... Of course I could be a little over dramatic there. :-) I actually think C (and when I say "C" I mean "the version of C /I think/ should exist, which is mostly C with a few things removed, and a few things added, basically RDC" in other words) is one of the best programming languages ever devised. I disagree with the C standard on many points and believe there should be a closer tie to hardware. But, that's me looking at it through my x86/ARM/similar-architectures' eyes. I still think it's a correct path in moving forward. Having oddities in hardware needs to have a real payoff to make it worthwhile, and I can't help but wonder how many of those oddities were introduced simply to work around patents, for example, rather than to provide any real useful contribution. Just my thinking on the matter. I could be wrong. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-14 09:29 +0200 |
| Message-ID | <mqk5ae$3js$1@dont-email.me> |
| In reply to | #67335 |
On 13/08/15 22:11, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > >> On Thursday, August 13, 2015 at 2:41:33 PM UTC-4, Ben Bacarisse wrote: >>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >>>> My proposal is a change to the C standard [...] >>> >>> Knock yourself out. It won't be happen. >> >> I know. It will be supplanted as the horse drawn carriage was, >> then relegated to nights out on the town for couples, and some >> displays at old technology festivals. > > What is the "it"? C? I think C is over-used; and it's often used for > quasi-emotional reasons. C is sometimes seen as the language that "real > programmers" use (something a bit like "real men" -- the programming > equivalent of swinging a big axe) whilst also being simple enough for > beginners to learn. I suspect (with, I freely, admit little evidence) > that many buggy bits of software are born from this unfortunate > perception. > > For many tasks there are better languages, but I doubt that C will be > totally supplanted any time soon. It occupies a particular niche in the > language ecosystem, due, in part, to some of the things you don't like > about it. Ironically, it's partly because people like you continue to > use it that it won't be supplanted. Could you not think of a better > language to use? > I too think C is over-used. It is certainly the best choice for some uses (in small embedded systems, it is dominant for good reason - though even here there are worthwhile alternatives such as C++, Ada, or Forth). But there is a great deal of code written in C for the wrong reasons, such as speed (because speed is often unimportant, because algorithms are often more important than the details of the language, because many C programmers don't understand how to write fast code, because many alternative languages are not nearly as slow as people think, etc.). I see a lot of questions in this newsgroup where the really useful answer is "don't try to do this in C - use language XX instead". Often that language is C++, but often it is a higher level language such as Python. (It's the higher level language I know best, rather than necessarily being the best high level language.) Look at the long thread on "How to read a data file whose size is unknown". The answer is simple, at least for ordinary files (which is the main consideration) : data = file(filename).read() No faffing around with different OS's and different API's, no messy memory allocations and re-allocations, or loops to read the file blocks, or figuring out how fstat works - just a single line of Python code that works on all major platforms. Someone else has already done all the work - with all the details handled in the Python runtime and libraries (written in C for speed!). And they will have spent more time and effort getting /all/ the details right, and testing on a range of platforms and circumstances - the code will be better than a typical C programmer would write themselves, even with the advice from this group. C is a hammer. It's a good hammer - well-built, solid and reliable, and can be taken anywhere. But it's still just a hammer - if you don't use it properly, you'll hit your thumb or bend your nail. And it is not the only tool in the toolbox - sometimes that big expensive power drill really is a better tool for the job in hand.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-14 08:01 -0400 |
| Message-ID | <mqkl7r$o0s$1@dont-email.me> |
| In reply to | #67359 |
On 08/14/2015 03:29 AM, David Brown wrote: ... > I see a lot of questions in this newsgroup where the really useful > answer is "don't try to do this in C - use language XX instead". Often > that language is C++, but often it is a higher level language such as > Python. (It's the higher level language I know best, rather than > necessarily being the best high level language.) Look at the long > thread on "How to read a data file whose size is unknown". The answer > is simple, at least for ordinary files (which is the main consideration) : > > data = file(filename).read() > > No faffing around with different OS's and different API's, no messy > memory allocations and re-allocations, or loops to read the file blocks, > or figuring out how fstat works - just a single line of Python code that > works on all major platforms. Someone else has already done all the > work - with all the details handled in the Python runtime and libraries > (written in C for speed!). And they will have spent more time and > effort getting /all/ the details right, and testing on a range of > platforms and circumstances - the code will be better than a typical C > programmer would write themselves, even with the advice from this group. That sounds wonderful - but what happens when filename identifies a file that is too big to fit in memory? I suppose those can't be considered "ordinary files"? I'm not suggesting that python can't deal with that issue, I'm just curious how it does deal with it. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-14 14:46 +0200 |
| Message-ID | <mqkns6$1oc$1@dont-email.me> |
| In reply to | #67388 |
On 14/08/15 14:01, James Kuyper wrote: > On 08/14/2015 03:29 AM, David Brown wrote: > ... >> I see a lot of questions in this newsgroup where the really useful >> answer is "don't try to do this in C - use language XX instead". Often >> that language is C++, but often it is a higher level language such as >> Python. (It's the higher level language I know best, rather than >> necessarily being the best high level language.) Look at the long >> thread on "How to read a data file whose size is unknown". The answer >> is simple, at least for ordinary files (which is the main consideration) : >> >> data = file(filename).read() >> >> No faffing around with different OS's and different API's, no messy >> memory allocations and re-allocations, or loops to read the file blocks, >> or figuring out how fstat works - just a single line of Python code that >> works on all major platforms. Someone else has already done all the >> work - with all the details handled in the Python runtime and libraries >> (written in C for speed!). And they will have spent more time and >> effort getting /all/ the details right, and testing on a range of >> platforms and circumstances - the code will be better than a typical C >> programmer would write themselves, even with the advice from this group. > > That sounds wonderful - but what happens when filename identifies a file > that is too big to fit in memory? I suppose those can't be considered > "ordinary files"? I'm not suggesting that python can't deal with that > issue, I'm just curious how it does deal with it. > Just as someone pointed out in the other thread, there is no one solution that fits every circumstance. If you have to deal with something unusual, such as extremely large files, pipes, etc., then your code has to be changed appropriately. And obviously your code may be different depending on the task at hand - if your file is xml, you'll use an xml parser module rather than loading the file directly, while if it is a binary array of data you'd use numpy, and so on. And just like in C, you'll want some sort of error handling - but in Python the errors will be conveniently turned into exceptions, and since there is only one line here there is only one place you need to put the error handling (as the code stands). My point is merely that C is not the most suitable language for many of the tasks to which it is used. In particular, many "high level" tasks that involve complex and error prone code, or at a minimum require finding the right libraries and learning how to use them, can often be done much more easily in other languages. This is not the right newsgroup, and not the right thread, to discuss details of Python solutions to reading files - all I wanted to show is how the answer to a simple question was complicated in C, and a one-liner in Python. (But the quick answer to your question is to give the read() function a parameter for the maximum chunk size to read.)
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-16 19:14 +0200 |
| Message-ID | <mqqgcs$jai$1@speranza.aioe.org> |
| In reply to | #67393 |
On 14.08.2015 14:46, David Brown wrote: [...] > > Just as someone pointed out in the other thread, there is no one > solution that fits every circumstance. If you have to deal with > something unusual, such as extremely large files, pipes, etc., then your > code has to be changed appropriately. And obviously your code may be > different depending on the task at hand - if your file is xml, you'll > use an xml parser module rather than loading the file directly, while if > it is a binary array of data you'd use numpy, and so on. And just like > in C, you'll want some sort of error handling - but in Python the errors > will be conveniently turned into exceptions, and since there is only one > line here there is only one place you need to put the error handling (as > the code stands). > > My point is merely that C is not the most suitable language for many of > the tasks to which it is used. In particular, many "high level" tasks > that involve complex and error prone code, or at a minimum require > finding the right libraries and learning how to use them, can often be > done much more easily in other languages. Yes, when all you have is a hammer, everything starts looking like a nail. It's a bit of a cliché, but it true in so many areas. I'm working on an XML reader and writer, and really didn't have to because there are so many different tools out there. If I were on some budget I'd take libxml and use that if I had to create something in C. If I were free to choose, I'd use Python, because I know it well and it is easy to be productive in such a high-level language and it has many XML tools. But for me this is more of a project I'm doing to explore C and Assembly, and it is a good learning exercise to create a library/ tool for something as well-defined as XML. If this library becomes popular and gets a user base then that's great, and when it all comes down to it, C developers produce some of the fastest programs out there. If this project contributes to the C developers toolbox then that's great, if it makes standards more ubiquitous then that's great too. -Morten
[toc] | [prev] | [next] | [standalone]
Page 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web