Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #63278 > unrolled thread
| Started by | Bartc <bc@freeuk.com> |
|---|---|
| First post | 2015-06-15 14:08 +0100 |
| Last post | 2015-07-14 13:14 -0700 |
| Articles | 20 on this page of 442 — 31 participants |
Back to article view | Back to comp.lang.c
typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-15 14:08 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 14:23 +0100
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-15 09:30 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 18:01 +0100
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-16 09:44 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 18:06 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 19:22 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 19:33 +0100
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-16 14:53 -0400
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 09:54 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-17 11:04 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-18 11:11 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-18 12:00 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-19 09:50 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 18:02 +0100
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-19 10:25 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 20:10 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 18:11 +0100
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-19 10:40 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 18:58 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 11:35 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 12:31 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 20:47 +0100
Re: typedef forward declaration mark.bluemel@gmail.com - 2015-06-19 03:35 -0700
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 17:23 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 09:46 -0700
Re: typedef forward declaration Barry Schwarz <schwarzb@dqel.com> - 2015-06-17 10:34 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 10:43 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-18 16:00 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-18 08:52 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-19 10:21 +0200
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-19 11:35 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 05:34 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 13:45 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 06:23 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 15:55 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 08:06 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 16:14 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 08:41 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 17:19 +0100
Re: typedef forward declaration Richard Damon <Richard@Damon-Family.org> - 2015-06-19 21:02 -0400
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 18:57 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 00:59 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-20 17:25 +0200
Re: typedef forward declaration Nathan Wagner <nw@hydaspes.if.org> - 2015-06-21 12:04 +0000
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-21 13:07 -0700
Re: typedef forward declaration Nathan Wagner <nw@hydaspes.if.org> - 2015-06-23 13:08 +0000
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 17:36 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 01:00 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 08:40 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-20 08:54 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 02:06 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-20 10:46 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 03:16 -0700
Re: typedef forward declaration Richard Damon <Richard@Damon-Family.org> - 2015-06-20 09:01 -0400
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-20 15:44 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-20 12:08 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-21 21:02 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-21 21:24 +0100
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-21 22:41 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 00:08 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 05:43 -0700
Re: typedef forward declaration Morris Dovey <mrdovey@iedu.com> - 2015-06-22 08:14 -0500
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 07:13 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 16:28 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 08:47 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 17:25 +0100
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-22 18:23 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 19:11 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 10:50 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 19:23 +0100
Re: typedef forward declaration Robert Wessel <robertwessel2@yahoo.com> - 2015-06-22 14:38 -0500
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 10:35 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 11:31 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 12:36 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 12:47 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 21:02 +0100
Re: typedef forward declaration Nathan Wagner <nw@hydaspes.if.org> - 2015-06-23 13:04 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 06:13 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-23 15:26 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 07:31 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 07:39 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 14:38 +0100
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-24 09:19 +0000
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 13:14 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-22 20:29 +0000
Re: typedef forward declaration "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-06-23 12:31 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 12:40 -0700
Re: typedef forward declaration crisdunbar@gmail.com - 2015-06-23 12:48 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 13:04 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 21:08 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 14:05 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 06:26 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 08:47 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 17:19 +0100
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-20 08:59 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 02:10 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-20 17:34 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 08:42 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 08:50 -0700
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-20 16:59 +0000
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-20 18:40 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-20 12:21 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-20 21:31 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-20 14:07 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 05:20 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-22 13:38 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 05:45 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-22 08:49 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 08:54 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-22 16:54 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 09:02 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-22 21:33 +0100
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-19 10:00 -0700
Re: typedef forward declaration Robert Wessel <robertwessel2@yahoo.com> - 2015-06-19 22:33 -0500
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-20 07:50 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 08:12 -0700
Re: typedef forward declaration gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-20 15:30 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 08:40 -0700
Re: typedef forward declaration Barry Schwarz <schwarzb@dqel.com> - 2015-06-19 10:10 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 12:58 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-19 21:30 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 13:34 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 14:56 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 13:45 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 16:26 -0700
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-06-20 12:26 +1200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 00:40 -0700
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-06-20 20:05 +1200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 01:17 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 17:52 -0700
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-20 01:12 +0000
Re: typedef forward declaration Robert Wessel <robertwessel2@yahoo.com> - 2015-06-19 22:35 -0500
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 00:55 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-20 10:27 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 02:31 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-20 15:45 +0100
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-22 15:13 -0400
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-20 11:56 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 05:36 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-22 17:12 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 09:25 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 17:54 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 10:58 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 19:39 +0100
Re: typedef forward declaration Martin Shobe <martin.shobe@yahoo.com> - 2015-06-22 13:59 -0500
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 10:37 +0200
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 11:01 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-07-12 09:02 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 09:44 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 19:42 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 11:47 -0700
Re: typedef forward declaration Rosario19 <Ros@invalid.invalid> - 2015-07-12 21:21 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 13:32 -0700
Re: typedef forward declaration Rosario19 <Ros@invalid.invalid> - 2015-07-13 09:03 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-13 03:13 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 21:53 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 14:05 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 14:30 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-13 00:52 +0100
Re: typedef forward declaration Richard Damon <Richard@Damon-Family.org> - 2015-07-12 20:57 -0400
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 22:52 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 16:56 -0700
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-07-13 13:22 +1200
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-07-13 10:05 +1200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 19:04 -0700
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-07-13 20:28 +1200
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-07-13 09:45 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-13 03:01 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-13 11:01 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-13 03:19 -0700
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-13 19:56 +0000
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-07-13 08:27 -0400
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-07-13 10:01 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-07-13 18:38 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-07-13 12:20 -0700
Re: typedef forward declaration "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-14 11:15 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 08:57 -0700
Re: typedef forward declaration luser droog <luser.droog@gmail.com> - 2015-07-13 23:25 -0700
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-07-15 12:59 -0400
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-07-20 17:32 +0200
Re: typedef forward declaration gwowen <gwowen@gmail.com> - 2015-07-13 07:22 -0700
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-07-13 11:58 -0400
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-07-13 10:06 -0700
Re: typedef forward declaration gwowen <gwowen@gmail.com> - 2015-07-15 05:24 -0700
Re: typedef forward declaration Rosario19 <Ros@invalid.invalid> - 2015-07-13 19:49 +0200
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:08 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-15 08:32 -0700
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:12 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 20:21 -0700
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:15 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 12:14 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 12:17 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 20:54 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 13:16 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 13:59 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 22:36 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 14:38 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 06:00 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 14:37 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 16:40 +0200
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 16:14 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 22:51 +0200
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 22:06 +0100
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-24 00:14 +0000
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 01:17 +0100
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-24 05:18 +0000
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 09:35 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 10:43 +0100
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-24 11:19 -0400
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-14 07:20 -0700
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-14 17:55 +0000
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 20:06 -0700
Re: typedef forward declaration Robert Wessel <robertwessel2@yahoo.com> - 2015-07-15 23:28 -0500
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 22:06 -0700
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:42 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-23 09:16 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 09:27 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-24 07:38 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-24 07:55 -0700
Re: typedef forward declaration Robert Wessel <robertwessel2@yahoo.com> - 2015-06-25 21:22 -0500
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-28 10:41 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 03:52 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 22:57 +0200
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-24 07:52 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-24 17:09 +0200
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-24 08:43 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-24 08:47 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-24 23:01 +0200
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-24 17:13 -0400
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 23:40 +0100
Re: typedef forward declaration Philip Lantz <prl@canterey.us> - 2015-06-24 21:38 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-25 11:23 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-25 11:36 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-25 11:55 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-25 00:46 +0200
Re: typedef forward declaration Melzzzzz <mel@zzzzz.com> - 2015-06-25 01:47 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 05:53 -0700
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-24 20:24 -0400
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-25 10:00 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 05:51 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-25 14:15 +0100
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-25 07:54 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 08:08 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-25 16:21 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-25 17:46 +0200
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-25 18:16 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-25 19:55 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 11:02 -0700
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-25 18:30 +0000
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-25 12:54 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-26 11:01 +0200
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-25 18:03 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-25 18:27 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-25 10:30 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 10:35 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-25 19:07 +0100
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-06-26 09:43 +1200
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-26 11:26 +0200
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-06-26 09:45 +1200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 14:51 -0700
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-06-26 09:57 +1200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 15:01 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-25 17:24 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 08:30 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-25 16:35 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-25 20:05 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 11:09 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 11:19 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-25 20:04 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-26 11:42 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 05:01 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-26 14:11 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 05:26 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-27 22:01 +0200
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-27 20:46 +0000
Re: typedef forward declaration Robert Wessel <robertwessel2@yahoo.com> - 2015-06-27 16:37 -0500
[OT] was Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-26 14:25 +0200
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 05:31 -0700
Re: [OT] was Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-26 14:18 +0100
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 06:31 -0700
Re: [OT] was Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-26 08:20 -0700
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 08:24 -0700
Re: [OT] was Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-26 10:24 -0700
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 10:30 -0700
Re: [OT] was Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-26 13:40 -0700
Re: [OT] was Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-26 14:09 -0700
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 14:23 -0700
Re: [OT] was Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-26 22:12 -0700
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 03:03 -0700
Re: [OT] was Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-27 13:08 +0100
Re: [OT] was Re: typedef forward declaration gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-27 11:37 +0000
Re: [OT] was Re: typedef forward declaration "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-06-27 13:06 -0700
Re: [OT] was Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-27 07:51 -0700
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 07:55 -0700
Re: [OT] was Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-26 08:59 -0700
Re: [OT] was Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-27 12:13 +0000
Re: [OT] was Re: typedef forward declaration Geoff <geoff@invalid.invalid> - 2015-06-27 08:25 -0700
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 08:43 -0700
Re: [OT] was Re: typedef forward declaration Geoff <geoff@invalid.invalid> - 2015-06-27 08:55 -0700
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 09:10 -0700
Re: [OT] was Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-27 11:25 -0700
Re: [OT] was Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-26 08:56 -0700
Re: [OT] was Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-27 22:05 +0200
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-25 12:46 -0400
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 10:00 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-28 10:58 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 04:03 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-28 12:43 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 06:05 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 06:33 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-28 18:28 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 10:42 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-28 18:17 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 10:32 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-28 20:53 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 17:53 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-29 12:10 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-29 04:59 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-29 14:21 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-29 06:40 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-29 17:38 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-29 10:44 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-29 22:10 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-29 15:09 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-28 11:43 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-28 10:43 +0000
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-29 08:50 +0200
Re: typedef forward declaration Richard Damon <Richard@Damon-Family.org> - 2015-06-27 12:32 -0400
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-23 13:17 -0400
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-23 13:20 -0400
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 10:25 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-24 09:51 +0200
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-24 12:05 -0400
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-24 10:43 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-27 12:18 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 05:26 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-27 14:11 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 06:38 -0700
Re: typedef forward declaration gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-27 13:55 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 07:15 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 07:34 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-27 15:56 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 08:13 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-27 21:35 +0100
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-27 18:58 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 12:35 -0700
Re: typedef forward declaration Richard Damon <Richard@Damon-Family.org> - 2015-06-27 13:21 -0400
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-27 11:34 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-27 12:07 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-28 11:02 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 06:12 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-07-03 17:25 +0000
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-24 11:51 -0700
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-24 15:17 -0400
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-24 12:31 -0400
Re: typedef forward declaration Rosario19 <Ros@invalid.invalid> - 2015-06-23 21:11 +0200
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 20:22 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 12:39 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-23 01:51 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 19:55 -0700
Re: typedef forward declaration "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-06-22 22:51 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 02:57 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 11:08 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-23 00:00 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 09:40 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 11:03 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 06:06 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 14:45 +0100
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 11:33 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-23 15:15 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 15:23 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 07:23 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 15:50 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 16:51 +0200
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 10:53 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 19:26 +0100
Re: typedef forward declaration Nathan Wagner <nw@hydaspes.if.org> - 2015-06-23 13:37 +0000
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-23 07:53 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 17:04 +0200
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 16:24 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-23 08:44 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-23 09:01 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-23 15:22 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-24 07:56 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-24 08:00 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-24 08:26 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 23:06 +0200
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 22:20 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-22 21:18 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 14:21 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-20 10:30 +0100
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-20 09:08 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 02:14 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-20 09:08 +0000
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 10:52 -0700
Re: typedef forward declaration Dr Nick <nospam-4@temporary-address.org.uk> - 2015-06-17 19:52 +0100
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-17 15:32 -0400
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 19:58 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 20:02 +0100
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-15 17:40 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 17:57 +0100
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-15 18:37 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 18:44 +0100
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-15 19:39 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 19:45 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 20:31 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-15 13:29 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-15 19:09 -0700
Re: typedef forward declaration Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-06-15 18:10 -0600
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-16 00:30 +0000
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-15 17:41 -0700
Re: typedef forward declaration Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-06-15 20:58 -0600
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-16 09:43 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 12:27 +0100
Re: typedef forward declaration Philip Lantz <prl@canterey.us> - 2015-06-16 09:20 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 19:18 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-15 10:13 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 18:24 +0100
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-18 21:47 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-15 06:24 -0700
Re: typedef forward declaration Lőrinczy Zsigmond <nospam@for.me> - 2015-06-15 21:20 +0200
Re: typedef forward declaration luser droog <luser.droog@gmail.com> - 2015-06-15 18:08 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 09:18 -0700
Re: typedef forward declaration Rosario19 <Ros@invalid.invalid> - 2015-06-26 18:46 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 10:28 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-13 05:34 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-13 21:40 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-14 09:27 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-14 20:11 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-14 12:20 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-14 12:50 -0700
Re: typedef forward declaration Philip Lantz <prl@canterey.us> - 2015-07-14 16:56 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-14 17:16 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-07-15 01:28 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-15 04:38 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-07-15 08:54 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-15 08:57 -0700
Re: typedef forward declaration Philip Lantz <prl@canterey.us> - 2015-07-14 17:03 -0700
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-15 05:10 +0000
Re: typedef forward declaration Philip Lantz <prl@canterey.us> - 2015-07-14 22:59 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-14 13:14 -0700
Page 13 of 23 — ← Prev page 1 … 11 12 [13] 14 15 … 23 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-25 05:51 -0700 |
| Message-ID | <b3966cf5-5222-4b3b-8500-de67e9a99cac@googlegroups.com> |
| In reply to | #64101 |
On Wednesday, June 24, 2015 at 5:13:58 PM UTC-4, James Kuyper wrote:
> On 06/24/2015 05:01 PM, David Brown wrote:
> > On 24/06/15 17:47, Rick C. Hodgin wrote:
> ...
> >> C tolerates self-modifying code.
>
> There is no such thing as C code that has, as it's standard-defined
> behavior, modification of the code itself. Any C construct that might
> reasonably have such a consequence necessarily has undefined behavior,
> which is the worst thing the C standard says about any code construct.
I was referring to the ability to self-modify a program using only C
code at runtime, provided you have externally created the opcodes
needed, stored them to some location, and basically do a memcpy.
But as far as the ability to use some kind of syntax which dynamically
modifies code at runtime, obviously no such creature exists.
> If, under those circumstances, you feel willing to say that "C tolerates
> this", then I defy you to describe something that C doesn't tolerate,
> and justify the distinction you're making between those two things.
Do you have to defy me? As though we're adversaries or something? We
are both human beings with wide ranging abilities and experience in
diverse areas. When I write things I'm not writing them to belittle
you or your position, but to convey my experience. I may not use the
same words you would use, but there should be a way past that disconnect
through assumptions which don't immediately jump toward something
"hostile" or "adversarial."
C is a translation vehicle. It translates human thought expressed in
human readable words, phrases, and statements, into something the
computer can conduct. It has an express range of abilities, and within
those abilities exists the ability to load external things which did
not come from C, or which came from another C source, being then used
as input into something which can be applied / copied. From within
that context, anything is possible in C. But again, within the strict
defines of C syntax, I am not aware of anything which allows self-
modifying code. My statement that it tolerates self-modifying code
means it is a mechanism which translates from A to B, and that B is,
in many places, execution address independent. The code can be
physically relocated and still reference the data on the stack, global
variables, etc. And with indirection, you can use movable functions.
It's not impossible to do, but it does require some finagling. And
it does require a comprehensive knowledge of your target environment.
The same changes may not even operate correctly on the same general
architecture, such as AMD x86 and Intel x86 (which is often why you
have self-modifying code, because at runtime you examine which
machine you're on, and then "hard wire" it to use the correct
computation algorithms for speed).
> > That's right.
> I must respectfully disagree with you about that.
I think some people in this group need to stop being so critical of
ideas which are presented which do not fit the standard, or are not
worded in proper ways as per people experienced in standard language.
There are ideas being conveyed which are beneficial to source code,
maintenance, development, and the tools in the developer's arsenal.
Just because they're not conveyed with technically correct terminology
(as per the state of common industry and educational wording), or just
because they propose something that has never been done before,
doesn't automatically mean the ideas are without merit.
Perhaps if we all give others the benefit of the doubt initially,
and don't get locked into "what has been is what shall be" thinking,
then it will be better for all.
I come to this forum for three reasons:
(1) I program in C and I need help from time to time. I also learn
a lot by simply reading the posts here.
(2) I would like to migrate C toward something which is more 2015,
and less 1970.
(3) I greatly appreciate the knowledge and experience which is here,
and it's good to be around well-thinking fellows in this industry.
I do not look down on any of you, and consider all of you to provide
value and insight. I do disagree with many aspects of the C standard
because it is, as Keith has indicated, targeted at real-world applications
which need to run on real-world equipment. And whereas I agree that
those should be targets, they should not be paramount. The needs of
people, and of people's thinking, should be paramount. We should not
be giving people what the machines can do, but giving people what they
need with the compilers doing all of the hard work of translating what
the people request into what the machines are capable of through
optimization, or, in the case of the expert developer, giving them the
extensions they need to instruct the compiler in more direct / advanced
wording, how to conduct a particular workload, thereby removing or
bypassing assumptions the compiler must make on their behalf.
This is a protractive effort that requires many of us to work together,
and is something with the potential to transform C into something
that's smoother, and works better with 2015 knowledge in code.
This is just my opinion, and my vision, but I am proceeding with it
because while there are gaps in my understanding and the understanding
other people have (or feel they have) of my understanding, when I take
the time to go through my points in exceeding detail (such as at a
white board with someone, answering all of their questions one-by-one
for a long time), they finally agree that what I'm talking about has
merit, but that they just never thought that way before.
This is a common theme in my adult programming life. I just have not
had the time or resources to bring the things I have in my head to
full fruition for people to see. And, I may never have that time as
per the Lord's plans. We'll see...
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-25 14:15 +0100 |
| Message-ID | <mmguq7$3ev$1@dont-email.me> |
| In reply to | #64119 |
On 25/06/15 13:51, Rick C. Hodgin wrote: > On Wednesday, June 24, 2015 at 5:13:58 PM UTC-4, James Kuyper wrote: >> On 06/24/2015 05:01 PM, David Brown wrote: >> > On 24/06/15 17:47, Rick C. Hodgin wrote: >> ... >> >> C tolerates self-modifying code. >> >> There is no such thing as C code that has, as it's standard-defined >> behavior, modification of the code itself. Any C construct that might >> reasonably have such a consequence necessarily has undefined behavior, >> which is the worst thing the C standard says about any code construct. > > I was referring to the ability to self-modify a program using only C > code at runtime, provided you have externally created the opcodes > needed, stored them to some location, and basically do a memcpy. > > But as far as the ability to use some kind of syntax which dynamically > modifies code at runtime, obviously no such creature exists. > >> If, under those circumstances, you feel willing to say that "C tolerates >> this", then I defy you to describe something that C doesn't tolerate, >> and justify the distinction you're making between those two things. > > Do you have to defy me? As though we're adversaries or something? Firstly, the "you" of "I defy you": James was clearly using this to address David Brown, not you. Secondly, you are taking the phrase out of context: "I defy you to describe" is idiomatic, and is roughly equivalent to "I challenge you to describe". It isn't about defiance per se. > [...] But again, within the strict > defines of C syntax, I am not aware of anything which allows self- > modifying code. My statement that it tolerates self-modifying code > means it is a mechanism which translates from A to B, and that B is, > in many places, execution address independent. The code can be > physically relocated and still reference the data on the stack, global > variables, etc. And with indirection, you can use movable functions. With sufficient indirection, C can do anything that can be done, because anything it can't do directly can be done by writing programs for other languages. But of course that isn't what is meant. Speaking purely in terms of language features, C does not *support* self-modifying code. <snip> >> > That's right. >> I must respectfully disagree with you about that. > > I think some people in this group need to stop being so critical of > ideas which are presented which do not fit the standard, or are not > worded in proper ways as per people experienced in standard language. If they are to flourish, ideas *need* criticism. Criticism of new ideas is a bit like a forest fire. It can get a bit heated, and it kills quite a few trees, but the trees that are left are the better for it. <snip> > I come to this forum for three reasons: > > (1) I program in C and I need help from time to time. I also learn > a lot by simply reading the posts here. That's why a lot of us read this group. > (2) I would like to migrate C toward something which is more 2015, > and less 1970. It's your right to try, but bear in mind that C is not in competition with other languages. There are purposes for which C is currently absolutely the best tool for the job, and there are purposes for which other languages are better-suited. There is *no value* in continual convergence into one big uber-language that tries to be all things to all men... and fails. > (3) I greatly appreciate the knowledge and experience which is here, > and it's good to be around well-thinking fellows in this industry. That's another reason a lot of us use this group. > I do not look down on any of you, and consider all of you to provide > value and insight. I cannot think of a kind reply to that sentence. > I do disagree with many aspects of the C standard > because it is, as Keith has indicated, targeted at real-world applications > which need to run on real-world equipment. And whereas I agree that > those should be targets, they should not be paramount. The needs of > people, and of people's thinking, should be paramount. But what if people think that they want to run these real-world applications on this real-world equipment, and that C is very well-suited to doing so, and that they want it to *go on* being well-suited to doing so, which means not changing it for woolly, poorly-conceived reasons? > We should not > be giving people what the machines can do, but giving people what they > need with the compilers doing all of the hard work of translating what > the people request into what the machines are capable of through > optimization, or, in the case of the expert developer, giving them the > extensions they need to instruct the compiler in more direct / advanced > wording, how to conduct a particular workload, thereby removing or > bypassing assumptions the compiler must make on their behalf. Every language should play to its own strengths. C's strength is in being absolutely the fastest thing out there other than hand-crafted assembly language. That's *important*. C is a tool that other languages can use to build on. Many compilers start life by turning NewLang into C, rather than into assembly language, because it's quick and easy (or easier, anyway) to do, and gives acceptable performance. It does so because C has very little overhead - *just* enough, in fact, to make it human-writable within acceptable timescales. > This is a protractive effort that requires many of us to work together, I'm not sure whether you really mean "protractive". "Pro-active", possibly? Anyway, your first battle is to convince people that your vision of C is worth pursuing. It may seem self-evident to you, but it sure looks like a backward step to me. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-06-25 07:54 -0700 |
| Message-ID | <56575ba7-b0ab-4bb3-b819-39fafe983676@googlegroups.com> |
| In reply to | #64121 |
On Thursday, June 25, 2015 at 6:15:12 AM UTC-7, Richard Heathfield wrote: > On 25/06/15 13:51, Rick C. Hodgin wrote: > > On Wednesday, June 24, 2015 at 5:13:58 PM UTC-4, James Kuyper wrote: > >> On 06/24/2015 05:01 PM, David Brown wrote: > >> > On 24/06/15 17:47, Rick C. Hodgin wrote: > >> ... > >> >> C tolerates self-modifying code. > >> > >> There is no such thing as C code that has, as it's standard-defined > >> behavior, modification of the code itself. Any C construct that might > >> reasonably have such a consequence necessarily has undefined behavior, > >> which is the worst thing the C standard says about any code construct. > > > > I was referring to the ability to self-modify a program using only C > > code at runtime, provided you have externally created the opcodes > > needed, stored them to some location, and basically do a memcpy. > > > > But as far as the ability to use some kind of syntax which dynamically > > modifies code at runtime, obviously no such creature exists. > > > >> If, under those circumstances, you feel willing to say that "C tolerates > >> this", then I defy you to describe something that C doesn't tolerate, > >> and justify the distinction you're making between those two things. > > > > Do you have to defy me? As though we're adversaries or something? > > Firstly, the "you" of "I defy you": James was clearly using this to > address David Brown, not you. Secondly, you are taking the phrase out of > context: "I defy you to describe" is idiomatic, and is roughly > equivalent to "I challenge you to describe". It isn't about defiance per se. > > > [...] But again, within the strict > > defines of C syntax, I am not aware of anything which allows self- > > modifying code. My statement that it tolerates self-modifying code > > means it is a mechanism which translates from A to B, and that B is, > > in many places, execution address independent. The code can be > > physically relocated and still reference the data on the stack, global > > variables, etc. And with indirection, you can use movable functions. > > With sufficient indirection, C can do anything that can be done, because > anything it can't do directly can be done by writing programs for other > languages. But of course that isn't what is meant. Speaking purely in > terms of language features, C does not *support* self-modifying code. > > <snip> > > >> > That's right. > >> I must respectfully disagree with you about that. > > > > I think some people in this group need to stop being so critical of > > ideas which are presented which do not fit the standard, or are not > > worded in proper ways as per people experienced in standard language. > > If they are to flourish, ideas *need* criticism. Criticism of new ideas > is a bit like a forest fire. It can get a bit heated, and it kills quite > a few trees, but the trees that are left are the better for it. > > <snip> > > > I come to this forum for three reasons: > > > > (1) I program in C and I need help from time to time. I also learn > > a lot by simply reading the posts here. > > That's why a lot of us read this group. > > > (2) I would like to migrate C toward something which is more 2015, > > and less 1970. > > It's your right to try, but bear in mind that C is not in competition > with other languages. There are purposes for which C is currently > absolutely the best tool for the job, and there are purposes for which > other languages are better-suited. There is *no value* in continual > convergence into one big uber-language that tries to be all things to > all men... and fails. > > > (3) I greatly appreciate the knowledge and experience which is here, > > and it's good to be around well-thinking fellows in this industry. > > That's another reason a lot of us use this group. > > > I do not look down on any of you, and consider all of you to provide > > value and insight. > > I cannot think of a kind reply to that sentence. > > > I do disagree with many aspects of the C standard > > because it is, as Keith has indicated, targeted at real-world applications > > which need to run on real-world equipment. And whereas I agree that > > those should be targets, they should not be paramount. The needs of > > people, and of people's thinking, should be paramount. > > But what if people think that they want to run these real-world > applications on this real-world equipment, and that C is very > well-suited to doing so, and that they want it to *go on* being > well-suited to doing so, which means not changing it for woolly, > poorly-conceived reasons? > > > > We should not > > be giving people what the machines can do, but giving people what they > > need with the compilers doing all of the hard work of translating what > > the people request into what the machines are capable of through > > optimization, or, in the case of the expert developer, giving them the > > extensions they need to instruct the compiler in more direct / advanced > > wording, how to conduct a particular workload, thereby removing or > > bypassing assumptions the compiler must make on their behalf. > > Every language should play to its own strengths. C's strength is in > being absolutely the fastest thing out there other than hand-crafted > assembly language. That's *important*. C is a tool that other languages > can use to build on. Many compilers start life by turning NewLang into > C, rather than into assembly language, because it's quick and easy (or > easier, anyway) to do, and gives acceptable performance. It does so > because C has very little overhead - *just* enough, in fact, to make it > human-writable within acceptable timescales. > > > This is a protractive effort that requires many of us to work together, > > I'm not sure whether you really mean "protractive". "Pro-active", > possibly? Anyway, your first battle is to convince people that your > vision of C is worth pursuing. It may seem self-evident to you, but it > sure looks like a backward step to me. C is what it is. I admit that I am not thrilled with any of the changes after C90 (you could defy me over "//" comments - which I might defend on the grounds that they aren't C - they are fodder for the preprocessor). But I like C that way because I want things SIMPLE - simpler, perhaps, than reality actually is. C does a little more than the minimum - for example "for", "switch" or "do-while" - but not much. And it is easy enough to use a subset of C90 features. The only genuinely useful hardware feature C left out is, so far as I know, the bit rotation logic in i86. And it appears that nobody misses it. Are there any other non-eccentric things lacking in C90?
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-25 08:08 -0700 |
| Message-ID | <ca4525c8-9148-4327-943a-54a47835ad4b@googlegroups.com> |
| In reply to | #64125 |
On Thursday, June 25, 2015 at 10:54:30 AM UTC-4, David Kleinecke wrote:
> The only genuinely useful hardware feature C left out is, so far as I
> know, the bit rotation logic in i86. And it appears that nobody misses
> it. Are there any other non-eccentric things lacking in C90?
Apart from some of the basic C "shortcomings" I've mentioned before:
(1) Basic class support (its operators [operator=,+,-,...], and its
simpler->sub_member->syntax() references).
(2) Basic exception handling.
(3) Easier iterative flow control:
iterate (10) {
// Do something here 10x
}
(4) Additional flow control logic:
until (condition) {
// Repeats while false
}
unless (condition) {
// Enters if false
}
(5) Adhoc functions:
int main(int x)
{
// Define a function for use in something nearby (or far away)
adhoc theTest(int a) {
// Some complex logic goes here so it can be easily
// single-stepped through in close proximity to the
// real code.
//
// adhocs are not entered under normal flow, only when
// explicitly called.
}
// Iterate until done
for (int i = 0; theTest(i); i++) {
// Loop code here
}
}
(6) Casks:
if ((|before|) x == y (|after|) (|meta|if_true|) (|mefa|if_false|))
{
// Block is entered on x == y, but the casks call these:
// before(), after()
//
// And will call if_true() if the block will be entered,
// and if_false() if the block will not be entered.
}
Casks allow code injection at any point in an otherwise syntactically
correct statement. They are primarily useful for debugging, but also
for exception handling at specific parts. They can be injected in
code as (|meia|) (which stands for "meta inquiry analysis," which
means a runtime condition has been encountered which does not align
with the expectations, so an inquiry is generated for analysis of
(or by) the developer. This was specifically added with LiveCode in
mind for RDC, which allows code to be fixed right there on the spot
in the debugger using normal changes to source code and compilation.
A few others.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-25 16:21 +0100 |
| Message-ID | <mmh66c$vt0$1@dont-email.me> |
| In reply to | #64126 |
On 25/06/15 16:08, Rick C. Hodgin wrote:
> On Thursday, June 25, 2015 at 10:54:30 AM UTC-4, David Kleinecke wrote:
>> The only genuinely useful hardware feature C left out is, so far as I
>> know, the bit rotation logic in i86. And it appears that nobody misses
>> it. Are there any other non-eccentric things lacking in C90?
>
> Apart from some of the basic C "shortcomings" I've mentioned before:
>
> (1) Basic class support (its operators [operator=,+,-,...], and its
> simpler->sub_member->syntax() references).
Surely C++ provides more than enough support for this?
> (2) Basic exception handling.
Actually, C /does/ have very, very basic exception handling in the form
of setjmp/longjmp - but it is rarely used (and probably used more than
it should be). C++, again, already has plenty of support for exception
handling.
> (3) Easier iterative flow control:
>
> iterate (10) {
> // Do something here 10x
> }
That looks simple enough until you realise that, within the loop, more
often than not you're going to want to know which iteration you're on,
which means you'll need an object to store that value, perhaps something
like:
iterate(int n : 10)
{
dosomethingwith(n);
}
Do you want 0 to 9 or 1 to 10? Do you want to be able to do this:
iterate(int n : x) /* 0 to x-1 or possibly 1 to x */
{
dosomethingwith(n);
}
Do you want to be able to go the other way?
iterate(int n : x : step -1) /* x-1 to 0 or maybe x to 1 */
We're getting very close to the for loop, aren't we?
>
> (4) Additional flow control logic:
>
> until (condition) {
> // Repeats while false
> }
Would
#define until(x) while(!(x))
do it for you?
>
> unless (condition) {
> // Enters if false
> }
#define unless(x) if(!(x))
which even allows you an else.
>
> (5) Adhoc functions:
>
> int main(int x)
What is x? Is it the same as argc?
> {
> // Define a function for use in something nearby (or far away)
> adhoc theTest(int a) {
> // Some complex logic goes here so it can be easily
> // single-stepped through in close proximity to the
> // real code.
> //
> // adhocs are not entered under normal flow, only when
> // explicitly called.
> }
You might want to explain this one a little more thoroughly.
>
> // Iterate until done
> for (int i = 0; theTest(i); i++) {
> // Loop code here
> }
> }
>
> (6) Casks:
>
> if ((|before|) x == y (|after|) (|meta|if_true|) (|mefa|if_false|))
> {
> // Block is entered on x == y, but the casks call these:
> // before(), after()
> //
> // And will call if_true() if the block will be entered,
> // and if_false() if the block will not be entered.
And this one. Isn't this the raison d'etre of RDC? If so, why not keep
it as a USP for RDC?
> }
>
> Casks allow code injection at any point in an otherwise syntactically
> correct statement. They are primarily useful for debugging, but also
> for exception handling at specific parts. They can be injected in
> code as (|meia|) (which stands for "meta inquiry analysis," which
> means a runtime condition has been encountered which does not align
> with the expectations, so an inquiry is generated for analysis of
> (or by) the developer. This was specifically added with LiveCode in
> mind for RDC, which allows code to be fixed right there on the spot
> in the debugger using normal changes to source code and compilation.
>
> A few others.
Some of these changes seem to me to be unnecessary, and some seem to
require a significant change in the character of the language. Whether
or not that is a Good Thing is a matter of taste, but in any case it
will be a lot easier to incorporate them into a new language than to
shoehorn them into C. (Not saying you shouldn't try if you want to.)
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-25 17:46 +0200 |
| Message-ID | <mmh7me$634$1@dont-email.me> |
| In reply to | #64128 |
On 25/06/15 17:21, Richard Heathfield wrote:
> On 25/06/15 16:08, Rick C. Hodgin wrote:
>> On Thursday, June 25, 2015 at 10:54:30 AM UTC-4, David Kleinecke wrote:
>>> The only genuinely useful hardware feature C left out is, so far as I
>>> know, the bit rotation logic in i86. And it appears that nobody misses
>>> it. Are there any other non-eccentric things lacking in C90?
>>
>> Apart from some of the basic C "shortcomings" I've mentioned before:
>>
>> (1) Basic class support (its operators [operator=,+,-,...], and its
>> simpler->sub_member->syntax() references).
>
> Surely C++ provides more than enough support for this?
I believe Rick wants some way of having classes while remaining simpler
than C++. But it's worth noting that historically C++ started out with
C and adding simple class ideas - the richer (or confusingly complex,
depending on your viewpoint) features C++ has today have come mostly
because they were necessary or useful extensions to the original simple
ideas. This suggests that if one were to try to add "simple", "basic"
class support to C, you will either get frustrated with a lack of
features or it will morph towards a much larger and more complex language.
And much of what is wrong with C++ (again, this is a matter of
viewpoint) comes down to its heritage in C - that is why there are so
many uses of "static", why there is the terse syntax, why the shift
operators are used for input and output, and so on.
So the lesson here is that if you want to make a nice language with
classes, don't start with C, and don't try to limit it too much at the
beginning.
>
>> (2) Basic exception handling.
>
> Actually, C /does/ have very, very basic exception handling in the form
> of setjmp/longjmp - but it is rarely used (and probably used more than
> it should be). C++, again, already has plenty of support for exception
> handling.
Basic exception handling leads to more complex class systems, which
leads to more complex exception handling, which leads to C++.
I believe trying to extend C with "basic" classes and "basic" exceptions
is a bit like trying to extend the complex numbers from a two
dimensional field into a three dimensional field - it can't be done, and
only works when you step up even more and make quaternions. In the same
way, a quest for C with "basic" classes and exceptions will fail until
you have extended it into "complex" classes and exceptions - and then
you are close to C++.
>
>> (3) Easier iterative flow control:
>>
>> iterate (10) {
>> // Do something here 10x
>> }
>
> That looks simple enough until you realise that, within the loop, more
> often than not you're going to want to know which iteration you're on,
> which means you'll need an object to store that value, perhaps something
> like:
>
> iterate(int n : 10)
> {
> dosomethingwith(n);
> }
>
> Do you want 0 to 9 or 1 to 10? Do you want to be able to do this:
>
> iterate(int n : x) /* 0 to x-1 or possibly 1 to x */
> {
> dosomethingwith(n);
> }
>
> Do you want to be able to go the other way?
>
> iterate(int n : x : step -1) /* x-1 to 0 or maybe x to 1 */
>
> We're getting very close to the for loop, aren't we?
>
And it can be made in a macro:
#define iterate(x) for (int n_ = 0; n_ < x; n_++)
>>
>> (4) Additional flow control logic:
>>
>> until (condition) {
>> // Repeats while false
>> }
>
> Would
> #define until(x) while(!(x))
> do it for you?
>>
>> unless (condition) {
>> // Enters if false
>> }
>
> #define unless(x) if(!(x))
>
> which even allows you an else.
>
>>
>> (5) Adhoc functions:
>>
>> int main(int x)
>
> What is x? Is it the same as argc?
>
>> {
>> // Define a function for use in something nearby (or far away)
>> adhoc theTest(int a) {
>> // Some complex logic goes here so it can be easily
>> // single-stepped through in close proximity to the
>> // real code.
>> //
>> // adhocs are not entered under normal flow, only when
>> // explicitly called.
>> }
>
> You might want to explain this one a little more thoroughly.
As far as I can tell, this is basically nested (or local) functions.
These can be a nice idea - gcc supports them as an extension, and C++
has lambdas. There may be some details regarding access to local
variables (captures, in C++ lambda terms).
>
>>
>> // Iterate until done
>> for (int i = 0; theTest(i); i++) {
>> // Loop code here
>> }
>> }
>>
>> (6) Casks:
>>
>> if ((|before|) x == y (|after|) (|meta|if_true|)
>> (|mefa|if_false|))
>> {
>> // Block is entered on x == y, but the casks call these:
>> // before(), after()
>> //
>> // And will call if_true() if the block will be entered,
>> // and if_false() if the block will not be entered.
>
> And this one. Isn't this the raison d'etre of RDC? If so, why not keep
> it as a USP for RDC?
Yes, I think "casks" are the key to RDC. I don't believe many (if any)
people in this group have really got the feel of what Rick means by
"casks", or why they are so important to him - I certainly don't
understand them. But it seems clear that they /are/ important to him,
but won't fit in with C as we know it. Thus RDC is made for casks, and
casks are made for RDC - and if and when RDC becomes available, we will
see what casks are for.
>
>> }
>>
>> Casks allow code injection at any point in an otherwise
>> syntactically
>> correct statement. They are primarily useful for debugging, but
>> also
>> for exception handling at specific parts. They can be injected in
>> code as (|meia|) (which stands for "meta inquiry analysis," which
>> means a runtime condition has been encountered which does not align
>> with the expectations, so an inquiry is generated for analysis of
>> (or by) the developer. This was specifically added with LiveCode in
>> mind for RDC, which allows code to be fixed right there on the spot
>> in the debugger using normal changes to source code and compilation.
>>
>> A few others.
>
> Some of these changes seem to me to be unnecessary, and some seem to
> require a significant change in the character of the language. Whether
> or not that is a Good Thing is a matter of taste, but in any case it
> will be a lot easier to incorporate them into a new language than to
> shoehorn them into C. (Not saying you shouldn't try if you want to.)
>
Apart from casks, I think they can all be handled by using C++ with
additional rules to limit features (such as banning multiple inheritance
and other non-simple class features), and a header with macros for
"unless", "iterate", "until". Maybe casks can be implemented too, with
a somewhat different syntax or a pre-processor.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-25 18:16 +0100 |
| Message-ID | <mmhcu3$r2j$1@dont-email.me> |
| In reply to | #64132 |
On 25/06/2015 16:46, David Brown wrote:
> On 25/06/15 17:21, Richard Heathfield wrote:
>>> (3) Easier iterative flow control:
>>>
>>> iterate (10) {
>>> // Do something here 10x
>>> }
>>
>> That looks simple enough until you realise that, within the loop, more
>> often than not you're going to want to know which iteration you're on,
>> which means you'll need an object to store that value, perhaps something
>> like:
> And it can be made in a macro:
>
> #define iterate(x) for (int n_ = 0; n_ < x; n_++)
A few problems with that:
* It relies on a C99 feature
* Many people don't like using the macro processor for such purposes
* Everyone will invent their own name for the macro
* If you see it in other people's code, with a macro name that is not
obvious, it is not immediately clear what is being expressed
* It creates an extra dependency (on the macro definition). So you can't
just copy and paste a function you like, you now have to go and dig up
this macro definition.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-25 19:55 +0200 |
| Message-ID | <mmhf78$4u8$1@dont-email.me> |
| In reply to | #64141 |
On 25/06/15 19:16, Bartc wrote:
> On 25/06/2015 16:46, David Brown wrote:
>> On 25/06/15 17:21, Richard Heathfield wrote:
>
>>>> (3) Easier iterative flow control:
>>>>
>>>> iterate (10) {
>>>> // Do something here 10x
>>>> }
>>>
>>> That looks simple enough until you realise that, within the loop, more
>>> often than not you're going to want to know which iteration you're on,
>>> which means you'll need an object to store that value, perhaps something
>>> like:
>
>> And it can be made in a macro:
>>
>> #define iterate(x) for (int n_ = 0; n_ < x; n_++)
>
> A few problems with that:
>
> * It relies on a C99 feature
Almost everyone who uses C uses C99. A few use older standards for good
reasons (such as portability for ancient compilers), a few use older
standards because they feel that the newfangled C99 destroyed the
simplicity and beauty of ANSI C, and a few use C11.
Since the C99 "ugliness" is hidden in a macro, the only C99 problem with
it is if your compiler doesn't actually support C99. If that's an
issue, get a better compiler or don't use the "iterate" macro.
(Note that I would not recommend any actually /use/ such a macro, any
more than I would recommend "#define R return" macros - this is merely a
way to show that Rick that this "missing feature" from C can be
implemented in C today.)
>
> * Many people don't like using the macro processor for such purposes
Nor do I - but I think it is a far better idea than changing the
language to include it as a new keyword. I don't think anyone needs
"iterate", and I don't think it will improve any code. But Rick would
like it, which is fair enough - and the macro will give him it today,
using today's tools.
>
> * Everyone will invent their own name for the macro
>
> * If you see it in other people's code, with a macro name that is not
> obvious, it is not immediately clear what is being expressed
>
> * It creates an extra dependency (on the macro definition). So you can't
> just copy and paste a function you like, you now have to go and dig up
> this macro definition.
>
All true - but all less bad than the alternative, which is a sort-of-C
compiler that includes it as a keyword.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-25 11:02 -0700 |
| Message-ID | <e6252c93-0970-4ab4-8e31-b7077c8d8fe4@googlegroups.com> |
| In reply to | #64154 |
On Thursday, June 25, 2015 at 1:55:14 PM UTC-4, David Brown wrote: > All true - but all less bad than the alternative, which is a sort-of-C > compiler that includes it as a keyword. I ultimately plan 100% compatibility with C across all versions using switches like -c90, -c99, etc., in addition to the extensions my language will provide. It just depends on time and resources. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-06-25 18:30 +0000 |
| Message-ID | <mmhhbm$bsc$1@speranza.aioe.org> |
| In reply to | #64154 |
David Brown <david.brown@hesbynett.no> wrote: (snip) > Almost everyone who uses C uses C99. A few use older standards for good > reasons (such as portability for ancient compilers), a few use older > standards because they feel that the newfangled C99 destroyed the > simplicity and beauty of ANSI C, and a few use C11. It took some years after ANSI C to switch over to ANSI features, such as function prototypes and ANSI argument lists. If I don't need C99 features, even though the compilers accept them, I still mostly write C89 code. How are the C11 compilers coming along? -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-25 12:54 -0700 |
| Message-ID | <lnegkzh8ch.fsf@kst-u.example.com> |
| In reply to | #64160 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> David Brown <david.brown@hesbynett.no> wrote:
>
> (snip)
>
>> Almost everyone who uses C uses C99. A few use older standards for good
>> reasons (such as portability for ancient compilers), a few use older
>> standards because they feel that the newfangled C99 destroyed the
>> simplicity and beauty of ANSI C, and a few use C11.
>
> It took some years after ANSI C to switch over to ANSI features,
> such as function prototypes and ANSI argument lists.
>
> If I don't need C99 features, even though the compilers accept them,
> I still mostly write C89 code.
>
> How are the C11 compilers coming along?
One data point:
https://gcc.gnu.org/wiki/C11Status
GCC 4.9 Changes: “ISO C11 support is now at a similar level of
completeness to ISO C99 support: substantially complete modulo
bugs, extended identifiers (supported except for corner cases
when -fextended-identifiers is used), floating-point issues
(mainly but not entirely relating to optional C99 features from
Annexes F and G) and the optional Annexes K (Bounds-checking
interfaces) and L (Analyzability).
Bounds-checking interfaces (Annex K) and threading are listed as
"Library issue (not implemented)"; both features are optional in C11.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-26 11:01 +0200 |
| Message-ID | <mmj4bk$7d3$2@dont-email.me> |
| In reply to | #64160 |
On 25/06/15 20:30, glen herrmannsfeldt wrote: > David Brown <david.brown@hesbynett.no> wrote: > > (snip) > >> Almost everyone who uses C uses C99. A few use older standards for good >> reasons (such as portability for ancient compilers), a few use older >> standards because they feel that the newfangled C99 destroyed the >> simplicity and beauty of ANSI C, and a few use C11. > > It took some years after ANSI C to switch over to ANSI features, > such as function prototypes and ANSI argument lists. > > If I don't need C99 features, even though the compilers accept them, > I still mostly write C89 code. > Yes, but I expect your code is compatible with both C89 and C99, and I expect your compiler is happy with C99. Would that be correct? > How are the C11 compilers coming along? gcc and clang are doing fine. I haven't had much use for any C11 features myself, except _Static_assert (I previously used a macro for that in C99, but "real" _Static_assert gives neater errors). > > -- glen >
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-25 18:03 +0100 |
| Message-ID | <mmhc7c$o74$1@dont-email.me> |
| In reply to | #64128 |
On 25/06/2015 16:21, Richard Heathfield wrote:
> On 25/06/15 16:08, Rick C. Hodgin wrote:
>> (3) Easier iterative flow control:
>>
>> iterate (10) {
>> // Do something here 10x
>> }
>
> That looks simple enough until you realise that, within the loop, more
> often than not you're going to want to know which iteration you're on,
> which means you'll need an object to store that value, perhaps something
> like:
More often than not doesn't mean never. Sometimes you /do/ just want to
repeat something N times. In a quick analysis of my current lot of code
(in a syntax that allows these special forms):
58% of loops are simple iterations with an index from A to B (and
usually A is 1 or 0)
15% are while-loops
11% are loops that repeat N times as has been proposed.
11% are infinite loops that use another means to exit
5% are repeat-until loops
0% are C-style loops (they are available I think, but are never used. I
think most likely uses are just written as while loops if they don't fit
into one of the other forms.)
Repeat-N-times loops I think are used more often than the 11% suggests
as they are used a lot for throwaway or temporary code (in C you would
need to do:
for (int i; i=0; i<=N; ++i) ....
The trouble is by the time you've concentrated on getting that lot
exactly right, you've half-forgotten what is supposed to go in the
loop!). (And quickly checking before posting, I notice there is a
mistake in that loop, which I've left in; obviously I wasn't
concentrating enough! *This* is the reason why a dedicated loop is a
good idea.)
> iterate(int n : 10)
> {
> dosomethingwith(n);
> }
>
> Do you want 0 to 9 or 1 to 10? Do you want to be able to do this:
>
> iterate(int n : x) /* 0 to x-1 or possibly 1 to x */
> {
> dosomethingwith(n);
> }
>
> Do you want to be able to go the other way?
>
> iterate(int n : x : step -1) /* x-1 to 0 or maybe x to 1 */
>
> We're getting very close to the for loop, aren't we?
You need to print 2168 asterisks one after the other. You need a loop.
You don't need to know the loop index within the loop, you don't care
what it starts from, and you don't care whether it counts up or down. A
full C for-loop is overkill. Probably you'd use a while (--n) loop, or
is it while(n--)? While you're pondering that, someone else can just use
iterate(2168) printf("*");
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-25 18:27 +0100 |
| Message-ID | <mmhdk4$tv7$1@dont-email.me> |
| In reply to | #64139 |
On 25/06/15 18:03, Bartc wrote:
> On 25/06/2015 16:21, Richard Heathfield wrote:
>> On 25/06/15 16:08, Rick C. Hodgin wrote:
>
>>> (3) Easier iterative flow control:
>>>
>>> iterate (10) {
>>> // Do something here 10x
>>> }
>>
>> That looks simple enough until you realise that, within the loop, more
>> often than not you're going to want to know which iteration you're on,
>> which means you'll need an object to store that value, perhaps something
>> like:
>
> More often than not doesn't mean never. Sometimes you /do/ just want to
> repeat something N times.
If we can assume C99+ for a moment, it takes me, let's see:
for(int n = 0; n < 100; n++)
about three seconds to type that. My fingers *know* how to do it
already. If we introduce the iterate() control structure, I have two
choices: teach my fingers how to type iterate(100) as quickly as I can
type for(int n = 0; n < 100; n++), or just ignore iterate() in favour of
the very, very familiar for loop. For me at least, it's a no-brainer.
But hey, why not? It wouldn't do any harm to add iterate(), just as long
as you spell it _iterate() (or alternatively make its validity dependent
on a new #include file).
<snip stats on various kinds of loop>
> Repeat-N-times loops I think are used more often than the 11% suggests
> as they are used a lot for throwaway or temporary code (in C you would
> need to do:
>
> for (int i; i=0; i<=N; ++i) ....
Close, but no cigar. :-)
> The trouble is by the time you've concentrated on getting that lot
> exactly right, you've half-forgotten what is supposed to go in the
> loop!).
Actually, no, I haven't. The above is automatic, and I wouldn't have
typed <=. That doesn't mean I don't put bugs into my code. But I don't
put /that/ bug into my code. In fact, I'm more likely to go the other
way, and leave out the '=' in cases where it should be there.
> (And quickly checking before posting, I notice there is a
> mistake in that loop, which I've left in; obviously I wasn't
> concentrating enough! *This* is the reason why a dedicated loop is a
> good idea.)
Or you could just cosy up to the pattern of n = 0; n < N; n++
Just a thought.
<snip>
> You need to print 2168 asterisks one after the other. You need a loop.
> You don't need to know the loop index within the loop, you don't care
> what it starts from, and you don't care whether it counts up or down. A
> full C for-loop is overkill. Probably you'd use a while (--n) loop, or
> is it while(n--)? While you're pondering that, someone else can just use
> iterate(2168) printf("*");
I wouldn't bother to ponder. I'd just write:
for(n = 0; n < num_asterisks; n++)
{
putchar('*');
}
(Actually, I'd just write print_n_char(stdout, '*'); instead, on the
grounds that I'd probably want to do it again later on.) I wouldn't have
described that as overkill. I'd have described it as coding.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-25 10:30 -0700 |
| Message-ID | <lnlhf78zml.fsf@nuthaus.mib.org> |
| In reply to | #64139 |
Bartc <bc@freeuk.com> writes:
[...]
> Repeat-N-times loops I think are used more often than the 11% suggests
> as they are used a lot for throwaway or temporary code (in C you would
> need to do:
>
> for (int i; i=0; i<=N; ++i) ....
>
> The trouble is by the time you've concentrated on getting that lot
> exactly right, you've half-forgotten what is supposed to go in the
> loop!). (And quickly checking before posting, I notice there is a
> mistake in that loop, which I've left in; obviously I wasn't
> concentrating enough! *This* is the reason why a dedicated loop is a
> good idea.)
Of course the correct version (assuming C99 or later) is:
for (int i=0; i<N; i++) ...
There were two mistakes in yours: the declaration and initialization
need to be in the same clause, and you have an off-by-one error.
The third clause can be either "i++" or "++i"; it doesn't matter
which. (In C++ there can be reasons to cultivate a habit of
preferring one over the other; those reasons don't apply to C, and
even in C++ they don't directly apply in a simple case like this.)
I understand that you seem to have difficulty with C for loops.
I'm afraid I don't understand why. Yes, it's a moderately complex
construct, because of its unusual flexibility. But simple things,
like iterating N times, are still reasonably easy to do. It just
requires the use of a few common idioms.
You could write a macro that simplifies simple cases, but most
experienced C programmers don't bother.
[...]
> You need to print 2168 asterisks one after the other. You need a loop.
> You don't need to know the loop index within the loop, you don't care
> what it starts from, and you don't care whether it counts up or down. A
> full C for-loop is overkill. Probably you'd use a while (--n) loop, or
> is it while(n--)? While you're pondering that, someone else can just use
> iterate(2168) printf("*");
for (int i = 0; i < 2168; i ++) {
putchar('*');
}
I wrote that as fast as I could type it (and I type fairly quickly).
To use iterate(), I'd first have to understand the iterate() macro
(if that's what it is), and probably how it maps onto a C for loop.
To use it in general, I'd worry about corner cases that might
be hidden in side the implementation, rather than exposed in the
semantics of for().
I'm not unsympathetic to your concerns about C's for loop, but
personally I've found that the best approach is to work with the
language rather than fighting against it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-25 10:35 -0700 |
| Message-ID | <42f0977f-ad81-4e3e-8dd6-38138a51b989@googlegroups.com> |
| In reply to | #64144 |
On Thursday, June 25, 2015 at 1:30:19 PM UTC-4, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
> [...]
> > Repeat-N-times loops I think are used more often than the 11% suggests
> > as they are used a lot for throwaway or temporary code (in C you would
> > need to do:
> >
> > for (int i; i=0; i<=N; ++i) ....
> >
> > The trouble is by the time you've concentrated on getting that lot
> > exactly right, you've half-forgotten what is supposed to go in the
> > loop!). (And quickly checking before posting, I notice there is a
> > mistake in that loop, which I've left in; obviously I wasn't
> > concentrating enough! *This* is the reason why a dedicated loop is a
> > good idea.)
>
> Of course the correct version (assuming C99 or later) is:
>
> for (int i=0; i<N; i++) ...
>
> There were two mistakes in yours: the declaration and initialization
> need to be in the same clause, and you have an off-by-one error.
>
> The third clause can be either "i++" or "++i"; it doesn't matter
> which. (In C++ there can be reasons to cultivate a habit of
> preferring one over the other; those reasons don't apply to C, and
> even in C++ they don't directly apply in a simple case like this.)
>
> I understand that you seem to have difficulty with C for loops.
> I'm afraid I don't understand why. Yes, it's a moderately complex
> construct, because of its unusual flexibility. But simple things,
> like iterating N times, are still reasonably easy to do. It just
> requires the use of a few common idioms.
>
> You could write a macro that simplifies simple cases, but most
> experienced C programmers don't bother.
WHOOOSH!!
[the sound of the points being made going right past you, Keith]
> [...]
> > You need to print 2168 asterisks one after the other. You need a loop.
> > You don't need to know the loop index within the loop, you don't care
> > what it starts from, and you don't care whether it counts up or down. A
> > full C for-loop is overkill. Probably you'd use a while (--n) loop, or
> > is it while(n--)? While you're pondering that, someone else can just use
> > iterate(2168) printf("*");
>
> for (int i = 0; i < 2168; i ++) {
> putchar('*');
> }
>
> I wrote that as fast as I could type it (and I type fairly quickly).
> To use iterate(), I'd first have to understand the iterate() macro
> (if that's what it is), and probably how it maps onto a C for loop.
> To use it in general, I'd worry about corner cases that might
> be hidden in side the implementation, rather than exposed in the
> semantics of for().
>
> I'm not unsympathetic to your concerns about C's for loop, but
> personally I've found that the best approach is to work with the
> language rather than fighting against it.
And again.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-25 19:07 +0100 |
| Message-ID | <mmhfue$81o$1@dont-email.me> |
| In reply to | #64147 |
On 25/06/15 18:35, Rick C. Hodgin wrote: > On Thursday, June 25, 2015 at 1:30:19 PM UTC-4, Keith Thompson wrote: <snip> >> You could write a macro that simplifies simple cases, but most >> experienced C programmers don't bother. > > WHOOOSH!! > > [the sound of the points being made going right past you, Keith] They weren't particularly strong points. If they did go past him, I expect it was because he didn't think they were worth catching. (FWIW, neither did I.) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-06-26 09:43 +1200 |
| Message-ID | <cv3b0kFqsmtU1@mid.individual.net> |
| In reply to | #64128 |
Richard Heathfield wrote:
> On 25/06/15 16:08, Rick C. Hodgin wrote:
>
>> (3) Easier iterative flow control:
>>
>> iterate (10) {
>> // Do something here 10x
>> }
>
> That looks simple enough until you realise that, within the loop, more
> often than not you're going to want to know which iteration you're on,
> which means you'll need an object to store that value, perhaps something
> like:
>
> iterate(int n : 10)
> {
> dosomethingwith(n);
> }
You may think so, but I've found the new range-for statement in C++ (and
foreach in PHP) to be very useful. My code involves a lot of iterating
over lists of things where the thing is of interest, not the index.
I find something like:
for( auto& file : files )
{
process( file );
}
more natural than
for( int n = 0; n < count(files); ++n )
{
process( files[n] );
}
Expressions like "files[n]" have always bugged me...
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-26 11:26 +0200 |
| Message-ID | <mmj5pu$d3g$1@dont-email.me> |
| In reply to | #64181 |
On 25/06/15 23:43, Ian Collins wrote:
> Richard Heathfield wrote:
>> On 25/06/15 16:08, Rick C. Hodgin wrote:
>>
>>> (3) Easier iterative flow control:
>>>
>>> iterate (10) {
>>> // Do something here 10x
>>> }
>>
>> That looks simple enough until you realise that, within the loop, more
>> often than not you're going to want to know which iteration you're on,
>> which means you'll need an object to store that value, perhaps something
>> like:
>>
>> iterate(int n : 10)
>> {
>> dosomethingwith(n);
>> }
>
> You may think so, but I've found the new range-for statement in C++ (and
> foreach in PHP) to be very useful. My code involves a lot of iterating
> over lists of things where the thing is of interest, not the index.
That's a different sort of situation, and unlike the "iterate" syntax
the C++ range-for provides a more convenient way to write a lot of loops.
>
> I find something like:
>
> for( auto& file : files )
> {
> process( file );
> }
>
> more natural than
>
> for( int n = 0; n < count(files); ++n )
> {
> process( files[n] );
> }
>
> Expressions like "files[n]" have always bugged me...
>
It's common in Python too:
for f in files :
process(f)
And when you also want access to the index number, you would often write:
for i, s in enumerate(strings) :
print "String %i = %s" % (i, s)
rather than the C-style:
for i in range(len(strings)) :
print "String %i = %s" % (i, strings[s])
I'm sure you could make some equivalent to "enumerate" in C++, returning
a tuple, but I don't think it would be as neat.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-06-26 09:45 +1200 |
| Message-ID | <cv3b47FqsmtU2@mid.individual.net> |
| In reply to | #64126 |
Rick C. Hodgin wrote: > On Thursday, June 25, 2015 at 10:54:30 AM UTC-4, David Kleinecke wrote: >> The only genuinely useful hardware feature C left out is, so far as I >> know, the bit rotation logic in i86. And it appears that nobody misses >> it. Are there any other non-eccentric things lacking in C90? > > Apart from some of the basic C "shortcomings" I've mentioned before: You mentioned before and I showed you how nearly all of them can be addressed with C++..... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
Page 13 of 23 — ← Prev page 1 … 11 12 [13] 14 15 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web