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 4 of 23 — ← Prev page 1 2 3 [4] 5 6 … 23 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-22 00:08 +0100 |
| Message-ID | <mm7g2j$mbq$1@dont-email.me> |
| In reply to | #63757 |
On 21/06/15 22:41, Bartc wrote: > On 21/06/2015 21:24, Richard Heathfield wrote: >> It's not as if C is a particularly good name for a language. In fact, >> the more unique the name, the better, and C is far from being a unique >> name. It's a single letter, a musical note, a fitness grade, an academic >> grade, a (hex) digit, a vitamin, a battery size, a temperature scale, a >> unit of charge, a chemical element, a nucleic acid, and the head of MI6. >> It's a *terrible* name for a language, and IMHO it has always been the C >> language's greatest weakness. > > I think you've just shown that a single-letter name can be used > successfully, when there is some context. No, what I've shown is that humans aren't very good at choosing names. The whole *point* of a name is that it is a label for the object or concept under discussion. A name with only one meaning does not require disambiguating context. -- 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 | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-22 05:43 -0700 |
| Message-ID | <daa62fe4-6b7b-4849-a989-1e81723f7584@googlegroups.com> |
| In reply to | #63699 |
On Saturday, June 20, 2015 at 3:08:37 PM UTC-4, Keith Thompson wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > I can't see it being an issue for me though. I can't imagine a time > > when I will use some unusual architecture with such odd quirks. > > But even if you did use such an unusual architecture, your code can > still work as long as you don't rely on non-portable assumptions when > you write it. I think you vastly underestimate how much you can do > based only on the guarantees given by the standard. I think you vastly underestimate the amount of effort it takes to learn the proper nuances of the standard so you are able to write truly portable code. I don't know about you, but I have other things I want to do with my life. And messing around with all these different varieties of C compilers is crazy. Every time I switch between MSVC and GCC there is something I have to change. And vice-versa. It's an effort to maintain the separatism in the two. And it's been true of the handful of other compilers I've used as well. It's very difficult to write code which only goes the standard if it's not easily identifiable which parts are the standard, and which parts are the extensions or allowances for the implementation. Over time you begin to sort some of it out, but it should be much simpler. > > (1) Get rid of char, short, int, long, long long (LOL!) and so on... > You've just broken every C program ever written. "ccompiler -ext-type-compatible" Now they're not broken anymore. The types map to whatever's appropriate for that machine, but the language fundamental units are named by size. > If you want a new language, by all means go ahead and define and > implement it. People do that all the time. You just don't get to > call it C. RDC (Lord willing). Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-06-22 08:14 -0500 |
| Message-ID | <mm91o6$ubo$1@speranza.aioe.org> |
| In reply to | #63803 |
On 6/22/15 7:43 AM, Rick C. Hodgin wrote: > I think you vastly underestimate the amount of effort it takes to learn > the proper nuances of the standard so you are able to write truly > portable code. I don't know about you, but I have other things I want > to do with my life. And messing around with all these different > varieties of C compilers is crazy. Agreed. The only encouragement I can offer is that learning those nuances is worth the time and effort spent. > Every time I switch between MSVC and GCC there is something I have to > change. And vice-versa. It's an effort to maintain the separatism in > the two. And it's been true of the handful of other compilers I've > used as well. It /is/ an effort (see above). > It's very difficult to write code which only goes the standard if it's > not easily identifiable which parts are the standard, and which parts > are the extensions or allowances for the implementation. Over time you > begin to sort some of it out, but it should be much simpler. What's worked for me has been developing the habit of pushing all code that relies on extensions to separate, clearly identified files (I do that by adding remarks to a comment "prolog" to each module). This can facilitate having everything pre-sorted from the git-go. It does make things simpler - and it has made it very much easier for me to zoom in on compiler / environment issues. -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-22 07:13 -0700 |
| Message-ID | <d5e0277d-98f3-4854-9de7-8201cbbda44a@googlegroups.com> |
| In reply to | #63808 |
On Monday, June 22, 2015 at 9:14:57 AM UTC-4, Morris Dovey wrote: > On 6/22/15 7:43 AM, Rick C. Hodgin wrote: > > > I think you vastly underestimate the amount of effort it takes to learn > > the proper nuances of the standard so you are able to write truly > > portable code. I don't know about you, but I have other things I want > > to do with my life. And messing around with all these different > > varieties of C compilers is crazy. > > Agreed. The only encouragement I can offer is that learning those > nuances is worth the time and effort spent. > > > Every time I switch between MSVC and GCC there is something I have to > > change. And vice-versa. It's an effort to maintain the separatism in > > the two. And it's been true of the handful of other compilers I've > > used as well. > > It /is/ an effort (see above). > > > It's very difficult to write code which only goes the standard if it's > > not easily identifiable which parts are the standard, and which parts > > are the extensions or allowances for the implementation. Over time you > > begin to sort some of it out, but it should be much simpler. > > What's worked for me has been developing the habit of pushing all code > that relies on extensions to separate, clearly identified files (I do > that by adding remarks to a comment "prolog" to each module). > > This can facilitate having everything pre-sorted from the git-go. It > does make things simpler - and it has made it very much easier for me to > zoom in on compiler / environment issues. I agree they should be divided out. I just think the C language itself should do this. Core C here (or C standard stuff here), and other stuff there. That way it can still be in the same file, but its home location is known. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-22 16:28 +0100 |
| Message-ID | <mm99ft$3i8$1@dont-email.me> |
| In reply to | #63803 |
On 22/06/15 13:43, Rick C. Hodgin wrote: > On Saturday, June 20, 2015 at 3:08:37 PM UTC-4, Keith Thompson wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> > I can't see it being an issue for me though. I can't imagine a time >> > when I will use some unusual architecture with such odd quirks. >> >> But even if you did use such an unusual architecture, your code can >> still work as long as you don't rely on non-portable assumptions when >> you write it. I think you vastly underestimate how much you can do >> based only on the guarantees given by the standard. > > I think you vastly underestimate the amount of effort it takes to learn > the proper nuances of the standard so you are able to write truly > portable code. I don't know about you, but I have other things I want > to do with my life. And messing around with all these different > varieties of C compilers is crazy. > > Every time I switch between MSVC and GCC there is something I have to > change. And vice-versa. It's an effort to maintain the separatism in > the two. And it's been true of the handful of other compilers I've > used as well. Strange. I never have that problem. Do you have some example code that you would be prepared to post? -- 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 | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-22 08:47 -0700 |
| Message-ID | <34f2f328-0138-49da-8cb5-b8dcbfc71206@googlegroups.com> |
| In reply to | #63817 |
On Monday, June 22, 2015 at 11:28:26 AM UTC-4, Richard Heathfield wrote:
> On 22/06/15 13:43, Rick C. Hodgin wrote:
> > On Saturday, June 20, 2015 at 3:08:37 PM UTC-4, Keith Thompson wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> > I can't see it being an issue for me though. I can't imagine a time
> >> > when I will use some unusual architecture with such odd quirks.
> >>
> >> But even if you did use such an unusual architecture, your code can
> >> still work as long as you don't rely on non-portable assumptions when
> >> you write it. I think you vastly underestimate how much you can do
> >> based only on the guarantees given by the standard.
> >
> > I think you vastly underestimate the amount of effort it takes to learn
> > the proper nuances of the standard so you are able to write truly
> > portable code. I don't know about you, but I have other things I want
> > to do with my life. And messing around with all these different
> > varieties of C compilers is crazy.
> >
> > Every time I switch between MSVC and GCC there is something I have to
> > change. And vice-versa. It's an effort to maintain the separatism in
> > the two. And it's been true of the handful of other compilers I've
> > used as well.
>
> Strange. I never have that problem. Do you have some example code that
> you would be prepared to post?
Search for "#ifdef __GNUC__" in these files:
(1) https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/compiler/vxb/vxb_compiler.cpp
(2) https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/vjr_compile_time_settings.h
-----
The (1) types could be wrapped into a single #define name with the
definition only occurring once in the header file.
The (2) relate to assembly opcodes to force signal a breakpoint without
having to have it set in the debugger on x86. The two C syntaxes are
not compatible, though I believe GCC now has an Intel syntax switch
which does make the assembly opcodes at least more compatible.
There are other places too. If you load the project and search for
the #ifdef __GNUC__ you'll see all of them. Some are merely for
identification, such as indicating which compiler is in use, etc.
Others are the include path folder separators require "\" or "/" for
their characters. Others are mapping the default types into s8,s16,
s32,s64, etc., without using uint32_t and the like (though I do use
those in GCC now, I could probably add them to MSVC as well, but I
haven't tried to do so yet).
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-22 17:25 +0100 |
| Message-ID | <mm9cqr$i91$1@dont-email.me> |
| In reply to | #63821 |
On 22/06/15 16:47, Rick C. Hodgin wrote:
> On Monday, June 22, 2015 at 11:28:26 AM UTC-4, Richard Heathfield wrote:
>> On 22/06/15 13:43, Rick C. Hodgin wrote:
>> > On Saturday, June 20, 2015 at 3:08:37 PM UTC-4, Keith Thompson wrote:
>> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> >> > I can't see it being an issue for me though. I can't imagine a time
>> >> > when I will use some unusual architecture with such odd quirks.
>> >>
>> >> But even if you did use such an unusual architecture, your code can
>> >> still work as long as you don't rely on non-portable assumptions when
>> >> you write it. I think you vastly underestimate how much you can do
>> >> based only on the guarantees given by the standard.
>> >
>> > I think you vastly underestimate the amount of effort it takes to learn
>> > the proper nuances of the standard so you are able to write truly
>> > portable code. I don't know about you, but I have other things I want
>> > to do with my life. And messing around with all these different
>> > varieties of C compilers is crazy.
>> >
>> > Every time I switch between MSVC and GCC there is something I have to
>> > change. And vice-versa. It's an effort to maintain the separatism in
>> > the two. And it's been true of the handful of other compilers I've
>> > used as well.
>>
>> Strange. I never have that problem. Do you have some example code that
>> you would be prepared to post?
>
> Search for "#ifdef __GNUC__" in these files:
>
> (1) https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/compiler/vxb/vxb_compiler.cpp
>
> (2) https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/vjr_compile_time_settings.h
>
> -----
Okay, my first observation is that the name vxb_compiler.cpp is a bit of
a hint to the compiler to use C++ rules rather than C rules. C++ is of
course off-topic here, but as long as we don't bump into anything
obviously C++-specific, I guess we can pretend for our purposes that you
called it .c rather than .cpp.
Secondly, on seeing the size of the file I took your hint, and searched
for GNUC. This revealed:
#ifdef __GNUC__
return(strtoull(var->value.data, NULL, 10));
#else
return(_strtoui64((s8*)var->value.data, NULL, 10));
#endif
Well, I wouldn't have done it like that. I'd have done it like this:
return strtoul(var->value.data, NULL, 10);
Now, the obvious objection is that unsigned long long is guaranteed to
be at least 64 bits wide, but strtoul treats the data as an unsigned
long rather than an unsigned long long, possibly losing information. On
the other hand, the function returns u32 which is, presumably, a typedef
for a 32-bit unsigned integer type. So it's not as if we're losing
anything we weren't already losing.
BUT... maybe u32 was a misprint for u64. Okay, so then I'd do it like this:
#ifndef H_VXBPORTABILITY_
#define H_VXBPORTABILITY_ 1
u64 vxb_string_to_ull(const char *, char **, int);
#endif
and then written vxbportability.c EITHER like this:
#include <vxbportability.h>
u64 vxb_string_to_ull(const char *s, char **p, int b)
{
return strtoull(s, p, b);
}
for the Linux version, and
#include <vxbportability.h>
u64 vxb_string_to_ull(const char *s, char **p, int b)
{
return _strtoui64(s, p, b);
}
for the Windows version, OR of course it is possible to put both of
these in the same call and wrapped #ifdef __GNUC__ around them.
Personally, I prefer the former method, even though it requires slightly
more careful file management, but I realise that some people might
prefer the latter.
The point of doing it this way is that you isolate all the non-portable
stuff into its own module. This makes porting a lot easier, because you
just have to touch the one module - you don't have to go through the
entire source file with a fine-toothed comb.
This is pretty easy stuff, and hardly constitutes a major pain.
> The (2) relate to assembly opcodes to force signal a breakpoint without
> having to have it set in the debugger on x86. The two C syntaxes are
> not compatible, though I believe GCC now has an Intel syntax switch
> which does make the assembly opcodes at least more compatible.
That's beyond the scope of C, which doesn't specify assembly language
interfaces, and so it's hardly surprising that implementations have
their own way of doing things. But again, the solution is to wrap all
the non-portable stuff into small functions in a single module, which
you rewrite for each new platform.
It is possible, using this technique, to reduce the porting effort
enormously. Data point: the Fresco Web browser for set-top boxes
comprised half a million lines of code, of which around five thousand
had to be written afresh for each new platform. Because those five
thousand lines were carefully isolated into a separate module, the
complete rewrite (including testing) took only a few weeks instead of
several months or even years.
--
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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-22 18:23 +0100 |
| Message-ID | <mm9g7k$oo$1@dont-email.me> |
| In reply to | #63831 |
On 22/06/2015 17:25, Richard Heathfield wrote: > That's beyond the scope of C, which doesn't specify assembly language > interfaces, and so it's hardly surprising that implementations have > their own way of doing things. But again, the solution is to wrap all > the non-portable stuff into small functions in a single module, which > you rewrite for each new platform. > > It is possible, using this technique, to reduce the porting effort > enormously. Data point: the Fresco Web browser for set-top boxes > comprised half a million lines of code, of which around five thousand > had to be written afresh for each new platform. Because those five > thousand lines were carefully isolated into a separate module, the > complete rewrite (including testing) took only a few weeks instead of > several months or even years. Take CPython as an example. This C application deals mainly with console and file i/o, you wouldn't think there'd be much problem in compiling it practically anywhere and with anything. However, for Linux it compiles only with gcc. For Windows it needs MSVC (why?). (It also builds smoothly under Linux using 'make', while a Windows build is supposed to be very difficult and is more of a DIY job. It doesn't help that these build systems often like to run OS-specific shell scripts to configure things or even generate code.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-22 19:11 +0100 |
| Message-ID | <mm9j1f$c24$1@dont-email.me> |
| In reply to | #63836 |
On 22/06/15 18:23, Bartc wrote: > On 22/06/2015 17:25, Richard Heathfield wrote: > >> It is possible, using this technique, to reduce the porting effort >> enormously. Data point: the Fresco Web browser for set-top boxes >> comprised half a million lines of code, of which around five thousand >> had to be written afresh for each new platform. Because those five >> thousand lines were carefully isolated into a separate module, the >> complete rewrite (including testing) took only a few weeks instead of >> several months or even years. > > Take CPython as an example. This C application deals mainly with console > and file i/o, you wouldn't think there'd be much problem in compiling it > practically anywhere and with anything. It all depends how it was written. If only the programmers had been comp.lang.c aficionados... -- 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 | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-22 10:50 -0700 |
| Message-ID | <52700c68-29fd-4632-82e5-68e4c7736cf2@googlegroups.com> |
| In reply to | #63831 |
On Monday, June 22, 2015 at 12:25:24 PM UTC-4, Richard Heathfield wrote:
> On 22/06/15 16:47, Rick C. Hodgin wrote:
> > On Monday, June 22, 2015 at 11:28:26 AM UTC-4, Richard Heathfield wrote:
> >> On 22/06/15 13:43, Rick C. Hodgin wrote:
> >> > On Saturday, June 20, 2015 at 3:08:37 PM UTC-4, Keith Thompson wrote:
> >> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> >> > I can't see it being an issue for me though. I can't imagine a time
> >> >> > when I will use some unusual architecture with such odd quirks.
> >> >>
> >> >> But even if you did use such an unusual architecture, your code can
> >> >> still work as long as you don't rely on non-portable assumptions when
> >> >> you write it. I think you vastly underestimate how much you can do
> >> >> based only on the guarantees given by the standard.
> >> >
> >> > I think you vastly underestimate the amount of effort it takes to learn
> >> > the proper nuances of the standard so you are able to write truly
> >> > portable code. I don't know about you, but I have other things I want
> >> > to do with my life. And messing around with all these different
> >> > varieties of C compilers is crazy.
> >> >
> >> > Every time I switch between MSVC and GCC there is something I have to
> >> > change. And vice-versa. It's an effort to maintain the separatism in
> >> > the two. And it's been true of the handful of other compilers I've
> >> > used as well.
> >>
> >> Strange. I never have that problem. Do you have some example code that
> >> you would be prepared to post?
> >
> > Search for "#ifdef __GNUC__" in these files:
> >
> > (1) https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/compiler/vxb/vxb_compiler.cpp
> >
> > (2) https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/vjr_compile_time_settings.h
> >
> > -----
>
> Okay, my first observation is that the name vxb_compiler.cpp is a bit of
> a hint to the compiler to use C++ rules rather than C rules. C++ is of
> course off-topic here, but as long as we don't bump into anything
> obviously C++-specific, I guess we can pretend for our purposes that you
> called it .c rather than .cpp.
There is very little C++ in my project. I use a C++ compiler because
it has more restrictive casting requirements, and there are some
relaxations I prefer, like not needing to use "struct SMyStruct" and
only needing "SMyStruct" without any special defines, single-line
comments more places, and a few others.
> Secondly, on seeing the size of the file I took your hint, and
> searched for GNUC. This revealed:
>
> #ifdef __GNUC__
> return(strtoull(var->value.data, NULL, 10));
> #else
> return(_strtoui64((s8*)var->value.data, NULL, 10));
> #endif
>
> Well, I wouldn't have done it like that. I'd have done it like this:
>
> return strtoul(var->value.data, NULL, 10);
>
> Now, the obvious objection is that unsigned long long is guaranteed to
> be at least 64 bits wide, but strtoul treats the data as an unsigned
> long rather than an unsigned long long, possibly losing information. On
> the other hand, the function returns u32 which is, presumably, a typedef
> for a 32-bit unsigned integer type. So it's not as if we're losing
> anything we weren't already losing.
The return type was u64. And the values obtained there are compared
based on their type.
> BUT... maybe u32 was a misprint for u64. Okay, so then I'd do it like this:
>
> #ifndef H_VXBPORTABILITY_
> #define H_VXBPORTABILITY_ 1
> u64 vxb_string_to_ull(const char *, char **, int);
> #endif
>
> and then written vxbportability.c EITHER like this:
>
> #include <vxbportability.h>
> u64 vxb_string_to_ull(const char *s, char **p, int b)
> {
> return strtoull(s, p, b);
> }
>
> for the Linux version, and
>
> #include <vxbportability.h>
> u64 vxb_string_to_ull(const char *s, char **p, int b)
> {
> return _strtoui64(s, p, b);
> }
>
> for the Windows version, OR of course it is possible to put both of
> these in the same call and wrapped #ifdef __GNUC__ around them.
> Personally, I prefer the former method, even though it requires slightly
> more careful file management, but I realise that some people might
> prefer the latter.
>
> The point of doing it this way is that you isolate all the non-portable
> stuff into its own module. This makes porting a lot easier, because you
> just have to touch the one module - you don't have to go through the
> entire source file with a fine-toothed comb.
Modern-day GUIs use features like Whole Tomato's Ctrl+Shift+F which
allows you to find all instances of a particular token in the source
file. You then click on each to navigate there.
Even so, these could've been combined into one location. I typically
do that, but did not do so here.
> This is pretty easy stuff, and hardly constitutes a major pain.
I never said it was a major pain. But, it's something I have to do
in many areas on every project I port from Windows to Linux, or even
from MSVC to GCC.
> > The (2) relate to assembly opcodes to force signal a breakpoint without
> > having to have it set in the debugger on x86. The two C syntaxes are
> > not compatible, though I believe GCC now has an Intel syntax switch
> > which does make the assembly opcodes at least more compatible.
>
> That's beyond the scope of C, which doesn't specify assembly language
> interfaces, and so it's hardly surprising that implementations have
> their own way of doing things. But again, the solution is to wrap all
> the non-portable stuff into small functions in a single module, which
> you rewrite for each new platform.
It's an extension to the C-language which allows the assembly code
to be included in a C source file. But, it's non-standard. It should
be standard.
> It is possible, using this technique, to reduce the porting effort
> enormously. Data point: the Fresco Web browser for set-top boxes
> comprised half a million lines of code, of which around five thousand
> had to be written afresh for each new platform. Because those five
> thousand lines were carefully isolated into a separate module, the
> complete rewrite (including testing) took only a few weeks instead of
> several months or even years.
I understand. I do what you suggest in some areas. It depends on
several factors. In this particular case I was seeing how much
effort it took to get it to compile in GCC having spent the previous
many months developing it in MSVC. Repeating that same fix three
times was faster than doing it the other way. I had to change a few
dozen other things to get it to compile. When I was done, I was
content and left it. I can refactor it later.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-22 19:23 +0100 |
| Message-ID | <mm9jpd$f9c$1@dont-email.me> |
| In reply to | #63840 |
On 22/06/15 18:50, Rick C. Hodgin wrote: > On Monday, June 22, 2015 at 12:25:24 PM UTC-4, Richard Heathfield wrote: <snip> >> Now, the obvious objection is that unsigned long long is guaranteed to >> be at least 64 bits wide, but strtoul treats the data as an unsigned >> long rather than an unsigned long long, possibly losing information. On >> the other hand, the function returns u32 which is, presumably, a typedef >> for a 32-bit unsigned integer type. So it's not as if we're losing >> anything we weren't already losing. > > The return type was u64. Okay, I'll take your word for it. Perhaps I scrolled a little too far (I looked at the code in a browser rather than stuffing it into an editor). <snip> >> >> The point of doing it this way is that you isolate all the non-portable >> stuff into its own module. This makes porting a lot easier, because you >> just have to touch the one module - you don't have to go through the >> entire source file with a fine-toothed comb. > > Modern-day GUIs use features like Whole Tomato's Ctrl+Shift+F which > allows you to find all instances of a particular token in the source > file. You then click on each to navigate there. Sure. I've used such IDEs myself. But, given the choice of the two ways, I would unhesitatingly choose mine, as I'm much less likely to miss something. > Even so, these could've been combined into one location. I typically > do that, but did not do so here. Why not? >> This is pretty easy stuff, and hardly constitutes a major pain. > > I never said it was a major pain. But, it's something I have to do > in many areas on every project I port from Windows to Linux, or even > from MSVC to GCC. Okay. You said it was an effort. That is *literally* true of every programming task, so I took you to mean that it was a greater effort than you would think reasonable. If I was wrong about that, well, then I was wrong, but it renders your claim somewhat lacking in force. My way, it isn't a major effort. It's a very minor effort. >> > The (2) relate to assembly opcodes to force signal a breakpoint without >> > having to have it set in the debugger on x86. The two C syntaxes are >> > not compatible, though I believe GCC now has an Intel syntax switch >> > which does make the assembly opcodes at least more compatible. >> >> That's beyond the scope of C, which doesn't specify assembly language >> interfaces, and so it's hardly surprising that implementations have >> their own way of doing things. But again, the solution is to wrap all >> the non-portable stuff into small functions in a single module, which >> you rewrite for each new platform. > > It's an extension to the C-language which allows the assembly code > to be included in a C source file. But, it's non-standard. It should > be standard. Why? The C Standard standardises C, not assembly language. <snip> > I understand. I do what you suggest in some areas. It depends on > several factors. In this particular case I was seeing how much > effort it took to get it to compile in GCC having spent the previous > many months developing it in MSVC. Repeating that same fix three > times was faster than doing it the other way. I had to change a few > dozen other things to get it to compile. When I was done, I was > content and left it. I can refactor it later. It is easier to make the code portable when you are first writing it than it is to impose portability after the fact. That is why we set such great store by portability. -- 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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-06-22 14:38 -0500 |
| Message-ID | <7togoaths4bda3g8rvpuvcaghaeodn4b9b@4ax.com> |
| In reply to | #63831 |
On Mon, 22 Jun 2015 17:25:16 +0100, Richard Heathfield
<rjh@cpax.org.uk> wrote:
>On 22/06/15 16:47, Rick C. Hodgin wrote:
>> On Monday, June 22, 2015 at 11:28:26 AM UTC-4, Richard Heathfield wrote:
>>> On 22/06/15 13:43, Rick C. Hodgin wrote:
>>> > On Saturday, June 20, 2015 at 3:08:37 PM UTC-4, Keith Thompson wrote:
>>> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>> >> > I can't see it being an issue for me though. I can't imagine a time
>>> >> > when I will use some unusual architecture with such odd quirks.
>>> >>
>>> >> But even if you did use such an unusual architecture, your code can
>>> >> still work as long as you don't rely on non-portable assumptions when
>>> >> you write it. I think you vastly underestimate how much you can do
>>> >> based only on the guarantees given by the standard.
>>> >
>>> > I think you vastly underestimate the amount of effort it takes to learn
>>> > the proper nuances of the standard so you are able to write truly
>>> > portable code. I don't know about you, but I have other things I want
>>> > to do with my life. And messing around with all these different
>>> > varieties of C compilers is crazy.
>>> >
>>> > Every time I switch between MSVC and GCC there is something I have to
>>> > change. And vice-versa. It's an effort to maintain the separatism in
>>> > the two. And it's been true of the handful of other compilers I've
>>> > used as well.
>>>
>>> Strange. I never have that problem. Do you have some example code that
>>> you would be prepared to post?
>>
>> Search for "#ifdef __GNUC__" in these files:
>>
>> (1) https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/compiler/vxb/vxb_compiler.cpp
>>
>> (2) https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/vjr_compile_time_settings.h
>>
>> -----
>
>Okay, my first observation is that the name vxb_compiler.cpp is a bit of
>a hint to the compiler to use C++ rules rather than C rules. C++ is of
>course off-topic here, but as long as we don't bump into anything
>obviously C++-specific, I guess we can pretend for our purposes that you
>called it .c rather than .cpp.
>
>Secondly, on seeing the size of the file I took your hint, and searched
>for GNUC. This revealed:
>
>#ifdef __GNUC__
> return(strtoull(var->value.data, NULL, 10));
>#else
> return(_strtoui64((s8*)var->value.data, NULL, 10));
>#endif
>
>Well, I wouldn't have done it like that. I'd have done it like this:
>
> return strtoul(var->value.data, NULL, 10);
>
>Now, the obvious objection is that unsigned long long is guaranteed to
>be at least 64 bits wide, but strtoul treats the data as an unsigned
>long rather than an unsigned long long, possibly losing information. On
>the other hand, the function returns u32 which is, presumably, a typedef
>for a 32-bit unsigned integer type. So it's not as if we're losing
>anything we weren't already losing.
>
>BUT... maybe u32 was a misprint for u64. Okay, so then I'd do it like this:
>
>#ifndef H_VXBPORTABILITY_
>#define H_VXBPORTABILITY_ 1
>u64 vxb_string_to_ull(const char *, char **, int);
>#endif
>
>and then written vxbportability.c EITHER like this:
>
>#include <vxbportability.h>
>u64 vxb_string_to_ull(const char *s, char **p, int b)
>{
> return strtoull(s, p, b);
>}
>
>for the Linux version, and
>
>#include <vxbportability.h>
>u64 vxb_string_to_ull(const char *s, char **p, int b)
>{
> return _strtoui64(s, p, b);
>}
>
>for the Windows version, OR of course it is possible to put both of
>these in the same call and wrapped #ifdef __GNUC__ around them.
>Personally, I prefer the former method, even though it requires slightly
>more careful file management, but I realise that some people might
>prefer the latter.
OTOH, since Rick appears to be compiling in C++ mode, MSVC has
supported long long since VS08, and strtoull since VS13. I don't
believe long long has made it into the C side of MSVC.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-22 10:35 -0700 |
| Message-ID | <lnioafd4tp.fsf@nuthaus.mib.org> |
| In reply to | #63803 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Saturday, June 20, 2015 at 3:08:37 PM UTC-4, Keith Thompson wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> > I can't see it being an issue for me though. I can't imagine a time
>> > when I will use some unusual architecture with such odd quirks.
>>
>> But even if you did use such an unusual architecture, your code can
>> still work as long as you don't rely on non-portable assumptions when
>> you write it. I think you vastly underestimate how much you can do
>> based only on the guarantees given by the standard.
>
> I think you vastly underestimate the amount of effort it takes to learn
> the proper nuances of the standard so you are able to write truly
> portable code. I don't know about you, but I have other things I want
> to do with my life. And messing around with all these different
> varieties of C compilers is crazy.
Drafts of the ISO C standard are freely available.
At least on Linux, documentation for library functions typically has a
"CONFORMING TO" section; I don't know whether Windows documentation is
similar.
And you can always ask for help here.
> Every time I switch between MSVC and GCC there is something I have to
> change. And vice-versa. It's an effort to maintain the separatism in
> the two. And it's been true of the handful of other compilers I've
> used as well.
The example you gave earlier was converting an integer to a string. If
you show us the code you wrote to do that that had to be changed when
switching between MSVC and GCC, we can help you with it. I find your
persistent failure to provide concrete examples of what you're talking
about puzzling.
Or you can continue complaining about it and telling us that C needs to
be changed to conform to your personal requirements.
[...]
>> If you want a new language, by all means go ahead and define and
>> implement it. People do that all the time. You just don't get to
>> call it C.
>
> RDC (Lord willing).
But the rest of us should change the way C is defined so you can use it
until RDC is ready?
--
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-22 11:31 -0700 |
| Message-ID | <7058206e-197d-4337-b153-103ca7b8e370@googlegroups.com> |
| In reply to | #63837 |
On Monday, June 22, 2015 at 1:35:24 PM UTC-4, Keith Thompson wrote:
> Drafts of the ISO C standard are freely available.
That's another issue I have ... the ISO C standard is not available
apart from a fee. Only drafts, and there are multiple versions that
I have found when attempting to download it previously.
I believe that is categorically an incorrect way to write and support
a standard. It should be completed, and then released freely to all.
> > Every time I switch between MSVC and GCC there is something I have to
> > change. And vice-versa. It's an effort to maintain the separatism in
> > the two. And it's been true of the handful of other compilers I've
> > used as well.
>
> The example you gave earlier was converting an integer to a string. If
> you show us the code you wrote to do that that had to be changed when
> switching between MSVC and GCC, we can help you with it. I find your
> persistent failure to provide concrete examples of what you're talking
> about puzzling.
It was code which converts a string to a 64-bit unsigned integer.
> Or you can continue complaining about it and telling us that C needs
> to be changed to conform to your personal requirements.
You're just not hearing what I'm saying. You're asking for specifics,
and when I'm telling you specific things you skip over them and ask
for other specifics.
I don't have time right now to go through each of these posts and
give each of them an appropriate response, especially considering
some of the responses I am receiving (such as my comment about
values not being finite). Some of these replies are quite amazing.
But, for now, the short version is this:
(1) char, short, int, long, long long, and their unsigneds, need to
go away. C needs new fundamental data types which are size-
specific, and to maintain backward compatibility use a switch
which aliases those names to the finite quantities.
(2) C should only support little-endian by default, and allow for
big-endian support as an extension.
(3) C needs native threading, and to be aware of other threads.
(4) C needs to be natively aware of other processes.
(5) C needs to define some kind of communication protocol between
processes.
(5) C needs to have its own virtual machine, with a full suite of
an editor, compiler, debugger, which is to its standard. These
need to be available to be ported onto every platform, with
nothing inside the vm changing across architectures or OSes.
And other things I don't have time for right now.
> >> If you want a new language, by all means go ahead and define and
> >> implement it. People do that all the time. You just don't get to
> >> call it C.
> >
> > RDC (Lord willing).
>
> But the rest of us should change the way C is defined so you can use it
> until RDC is ready?
No. But C should adapt. It's 2015 where memory is cheap, and hardware is
fast. We should not have ties to legacy baggage on future standards.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-22 12:36 -0700 |
| Message-ID | <lny4jbbkmd.fsf@nuthaus.mib.org> |
| In reply to | #63846 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Monday, June 22, 2015 at 1:35:24 PM UTC-4, Keith Thompson wrote:
>> Drafts of the ISO C standard are freely available.
>
> That's another issue I have ... the ISO C standard is not available
> apart from a fee. Only drafts, and there are multiple versions that
> I have found when attempting to download it previously.
>
> I believe that is categorically an incorrect way to write and support
> a standard. It should be completed, and then released freely to all.
I would certainly prefer it if the ISO C standard were available
at zero cost. ISO does spend money to produce and distribute
the standard, but as I understand it that money doesn't go to the
committee members who do the work of writing it.
FYI, nobody here is likely to be in a position to do anything about
that. comp.std.c would be a more appropriate place to discuss it,
but I suggest checking for previous discussions first. Be aware
that most members of the committee don't hang out there anyway (not
that even committee members are in a position to change ISO policy).
The N1256 draft consists of the C99 standard with the three
Technical Corrigenda merged into it. It is, for most purposes,
*better* than the published (and non-free) C99 standard.
The N1570 draft consists of the C11 standard as it was shortly before
the final version was published. The differences beween N1570 and
the actual (non-free) C11 standard are minor. I have both, and I
usually refer to N1570.
I am personally annoyed by the prices charged for copies of the
standard, and by the license terms ANSI imposes when I buy them,
but in practice it's a minor issue. The drafts really are good enough
99% of the time.
>> > Every time I switch between MSVC and GCC there is something I have to
>> > change. And vice-versa. It's an effort to maintain the separatism in
>> > the two. And it's been true of the handful of other compilers I've
>> > used as well.
>>
>> The example you gave earlier was converting an integer to a string. If
>> you show us the code you wrote to do that that had to be changed when
>> switching between MSVC and GCC, we can help you with it. I find your
>> persistent failure to provide concrete examples of what you're talking
>> about puzzling.
>
> It was code which converts a string to a 64-bit unsigned integer.
For Windows, you might have problems because Microsoft's compiler
doesn't conform to C99. That's hardly C's fault. But at least Visual
Studio 2013 does support the standard strtoll() function, which converts
a string to an unsigned type that's at least 64 bits wide.
>> Or you can continue complaining about it and telling us that C needs
>> to be changed to conform to your personal requirements.
>
> You're just not hearing what I'm saying. You're asking for specifics,
> and when I'm telling you specific things you skip over them and ask
> for other specifics.
>
> I don't have time right now to go through each of these posts and
> give each of them an appropriate response, especially considering
> some of the responses I am receiving (such as my comment about
> values not being finite). Some of these replies are quite amazing.
>
> But, for now, the short version is this:
>
> (1) char, short, int, long, long long, and their unsigneds, need to
> go away. C needs new fundamental data types which are size-
> specific, and to maintain backward compatibility use a switch
> which aliases those names to the finite quantities.
That's just not going to happen. It could be a reasonable approach for
an entirely new language.
But since the intN_t types exist, why does it matter that they're
defined in a standard header rather than predefined by the language?
(Admittedly promotion of narrow types to int or unsigned int can be an
issue.)
> (2) C should only support little-endian by default, and allow for
> big-endian support as an extension.
That's just not going to happen. There are big-endian systems in
widespread use.
> (3) C needs native threading, and to be aware of other threads.
C11 has native threading as an optional feature. I'm not sure what
"aware of other threads" means. Certainly you can use system-specific
threading libraries in C.
> (4) C needs to be natively aware of other processes.
POSIX.
> (5) C needs to define some kind of communication protocol between
> processes.
POSIX.
> (5) C needs to have its own virtual machine, with a full suite of
> an editor, compiler, debugger, which is to its standard. These
> need to be available to be ported onto every platform, with
> nothing inside the vm changing across architectures or OSes.
You want the C standard to define a standard *editor*?
There are plenty of virtual machine implementations. Build a VM running
your favorite operating system, C implementation, and associated tools,
and port it anywhere you like. (I won't be using it to run the C code I
work on that runs inside the Linux kernel on embedded devices.)
> And other things I don't have time for right now.
>
>> >> If you want a new language, by all means go ahead and define and
>> >> implement it. People do that all the time. You just don't get to
>> >> call it C.
>> >
>> > RDC (Lord willing).
>>
>> But the rest of us should change the way C is defined so you can use it
>> until RDC is ready?
>
> No. But C should adapt. It's 2015 where memory is cheap, and hardware is
> fast. We should not have ties to legacy baggage on future standards.
Most of the adaptations you suggest are, in my not-so-humble opinion,
unreasonable.
--
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-22 12:47 -0700 |
| Message-ID | <9a675b83-6c8e-436b-ba1b-def556718c2c@googlegroups.com> |
| In reply to | #63854 |
On Monday, June 22, 2015 at 3:37:15 PM UTC-4, Keith Thompson wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > It was code which converts a string to a 64-bit unsigned integer. > > For Windows, you might have problems because Microsoft's compiler > doesn't conform to C99. That's hardly C's fault. But at least Visual > Studio 2013 does support the standard strtoll() function, which converts > a string to an unsigned type that's at least 64 bits wide. MSVC 2010 had a function, but it used a different name. This is part of my displeasure with C, and it feeds into my statement when I say "it shouldn't be like that." > > (1) char, short, int, long, long long, and their unsigneds, need to > > go away. C needs new fundamental data types which are size- > > specific, and to maintain backward compatibility use a switch > > which aliases those names to the finite quantities. > > That's just not going to happen... > > But since the intN_t types exist, why does it matter that they're > defined in a standard header rather than predefined by the language? > (Admittedly promotion of narrow types to int or unsigned int can be an > issue.) > > > (2) C should only support little-endian by default, and allow for > > big-endian support as an extension. > > That's just not going to happen... > > > (3) C needs native threading, and to be aware of other threads. > > C11 has native threading as an optional feature. I'm not sure what > "aware of other threads" means. Certainly you can use system-specific > threading libraries in C. It's one thing to be able to launch another thread, it's another to have a way to manually control other threads (or self), or to send messages back and forth. C should define those things and not rely on system-specific libraries, except for the mechanics of translating the request in C to the OS call(s) necessary. > > (4) C needs to be natively aware of other processes. > POSIX. > > > (5) C needs to define some kind of communication protocol between > > processes. > POSIX. These should be defined in C. > > (5) C needs to have its own virtual machine, with a full suite of > > an editor, compiler, debugger, which is to its standard. These > > need to be available to be ported onto every platform, with > > nothing inside the vm changing across architectures or OSes. > > You want the C standard to define a standard *editor*? I want it to have an editor, one that is standard in the VM. That doesn't mean it's the only one, but it is one that is then a standard that people can rely on for using examples, writing documentation, making tutorials, etc. > There are plenty of virtual machine implementations. Build a VM running > your favorite operating system, C implementation, and associated tools, > and port it anywhere you like. (I won't be using it to run the C code I > work on that runs inside the Linux kernel on embedded devices.) I'm talking about a C-only VM. A very thin client app which runs the virtual C environment, allowing for additional debugging features because it is running inside a VM. If I'm ever able to complete my Visual FreePro virtual machine, you'll see in practice what I'm talking about. > >> But the rest of us should change the way C is defined so you can use it > >> until RDC is ready? > > No. But C should adapt. It's 2015 where memory is cheap, and hardware is > > fast. We should not have ties to legacy baggage on future standards. > > Most of the adaptations you suggest are, in my not-so-humble opinion, > unreasonable. There's nothing to prevent C from remaining where it is with the current standard. I'm talking about the "before" and "after" division I mentioned previously. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-22 21:02 +0100 |
| Message-ID | <mm9pig$81j$1@dont-email.me> |
| In reply to | #63856 |
On 22/06/15 20:47, Rick C. Hodgin wrote: > On Monday, June 22, 2015 at 3:37:15 PM UTC-4, Keith Thompson wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> > It was code which converts a string to a 64-bit unsigned integer. >> >> For Windows, you might have problems because Microsoft's compiler >> doesn't conform to C99. That's hardly C's fault. But at least Visual >> Studio 2013 does support the standard strtoll() function, which converts >> a string to an unsigned type that's at least 64 bits wide. > > MSVC 2010 had a function, but it used a different name. This is part > of my displeasure with C, and it feeds into my statement when I say > "it shouldn't be like that." You're saying that it's C's fault that Microsoft didn't fully implement C99? Well, I didn't fully implement C99 either. In fact, I didn't implement any of it. Nor did I implement C90 or C11. Is that C's fault too? If you must experience displeasure with anything, surely it should be with the implementation that failed to keep pace with what was in 2010 already a decade-old standard. <snip> >> > (4) C needs to be natively aware of other processes. >> POSIX. >> >> > (5) C needs to define some kind of communication protocol between >> > processes. >> POSIX. > > These should be defined in C. Why? POSIX already adequately defines such cross-process interaction, as Keith already explained. It isn't enough to make declarative statements. If you want to persuade people, you have to make cogent arguments too. >> > (5) C needs to have its own virtual machine, with a full suite of >> > an editor, compiler, debugger, which is to its standard. These >> > need to be available to be ported onto every platform, with >> > nothing inside the vm changing across architectures or OSes. >> >> You want the C standard to define a standard *editor*? > > I want it to have an editor, one that is standard in the VM. That > doesn't mean it's the only one, but it is one that is then a standard > that people can rely on for using examples, writing documentation, > making tutorials, etc. If you think about how long it took for the ISO C Committee to adopt BCPL comments and gcc's long long int, and if you consider that it took more than two decades for them to throw out gets(), how long do you think it will take them to agree on a standard editor, compiler, and debugger? We're talking centuries here. Realistically, it simply will not happen in our lifetimes, no matter what *anyone* wants. -- 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 | Nathan Wagner <nw@hydaspes.if.org> |
|---|---|
| Date | 2015-06-23 13:04 +0000 |
| Message-ID | <slrnmoimb3.1a3.nw@granicus.if.org> |
| In reply to | #63858 |
> On 22/06/15 20:47, Rick C. Hodgin wrote: >> I want it to have an editor, one that is standard [...] >> that people can rely on for using examples, writing documentation, >> making tutorials, etc. There's already a standard editor, it's called "ed". -- nw
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-23 06:13 -0700 |
| Message-ID | <589512b9-c89c-46b3-a07e-bd1664451422@googlegroups.com> |
| In reply to | #63916 |
On Tuesday, June 23, 2015 at 9:08:55 AM UTC-4, Nathan Wagner wrote: > > On 22/06/15 20:47, Rick C. Hodgin wrote: > >> I want it to have an editor, one that is standard [...] > >> that people can rely on for using examples, writing documentation, > >> making tutorials, etc. > > There's already a standard editor, it's called "ed". Then "ed" can be the standard editor. I'd have to see it before signing off completely, but if it has basic editor abilities then sure ... sounds good to me. I just want something that can be reliably used by people, so that they can see a video and follow along point-by-point with a particular version of the VM environment, which comprises all of the tools needed. RDC plans to do this with the Visual FreePro virtual machine (VVM). But, that's likely a long ways off. It will require an act on behalf of the Lord to move it forward because I've pushed and pushed and pushed and I haven't gotten there yet. Progress has been made, but it's still a ways off. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-23 15:26 +0100 |
| Message-ID | <mmbq7p$itt$1@dont-email.me> |
| In reply to | #63918 |
On 23/06/2015 14:13, Rick C. Hodgin wrote: > RDC plans to do this with the Visual FreePro virtual machine (VVM). But, > that's likely a long ways off. It will require an act on behalf of the > Lord to move it forward because I've pushed and pushed and pushed and I > haven't gotten there yet. Progress has been made, but it's still a ways > off. I would keep the development tools separate from the language design, which should stand on its own. People like to use their own tools too, or none at all, just using the nearest editor to hand. (I haven't been able to use MSVC for this reason; a full download (for Visual Studio) is 6000MB. I'm sure the core compiler, linker and essential headers are much less, but I don't know to separate them out from the rest.) Imagine you want to distribute working source code in your language. You want to provide a means for people to compile code into an application, but not develop or debug it. That means a bare compiler, linker and essential libraries (or however it will work if it's a bit different). -- bartc
[toc] | [prev] | [next] | [standalone]
Page 4 of 23 — ← Prev page 1 2 3 [4] 5 6 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web