Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #54051 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2014-12-07 14:48 -0800 |
| Last post | 2014-12-12 02:24 -0800 |
| Articles | 20 on this page of 299 — 34 participants |
Back to article view | Back to comp.lang.c
which one is better fir <profesor.fir@gmail.com> - 2014-12-07 14:48 -0800
Re: which one is better Siri Crews <chine.bleu@yahoo.com> - 2014-12-07 16:14 -0800
Re: which one is better glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-08 01:28 +0000
Re: which one is better Siri Crews <chine.bleu@yahoo.com> - 2014-12-07 19:01 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-08 00:32 -0800
Re: which one is better Siri Crews <chine.bleu@yahoo.com> - 2014-12-08 01:40 -0800
which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-07 19:00 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-08 00:35 -0800
Re: which one is better gordonb.7ngx1@burditt.org (Gordon Burditt) - 2014-12-16 06:28 -0600
Re: which one is better BartC <bc@freeuk.com> - 2014-12-16 13:08 +0000
Re: which one is better Richard Damon <Richard@Damon-Family.org> - 2014-12-16 23:49 -0500
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-16 05:15 -0800
Re: which one is better gordonb.9nipv@burditt.org (Gordon Burditt) - 2014-12-17 02:22 -0600
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-17 01:21 -0800
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-18 02:21 -0600
Re: which one is better Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-11 12:34 +0100
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 05:33 -0800
Re: which one is better Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-11 16:27 +0100
Re: which one is better gordonb.cx8yb@burditt.org (Gordon Burditt) - 2014-12-16 06:58 -0600
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 15:05 +0000
Re: which one is better Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-11 16:31 +0100
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 17:11 +0000
Re: which one is better Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-11 18:44 +0100
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 10:19 -0800
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 20:07 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-11 20:52 +0000
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 22:10 +0000
Re: which one is better Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-11 22:57 +0100
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-11 15:34 +0000
Re: which one is better Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-11 16:45 +0100
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 07:56 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-11 16:08 +0000
Re: which one is better Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-11 17:19 +0100
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 08:35 -0800
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 17:09 +0000
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 09:58 -0800
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 20:13 +0000
Re: which one is better glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-11 20:18 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-11 12:57 -0800
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-12 01:55 -0600
Re: which one is better Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-12-12 03:03 -0500
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-12 02:30 -0600
Re: which one is better glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-14 04:03 +0000
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 17:04 +0000
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 08:53 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-11 17:49 +0000
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 10:18 -0800
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 10:43 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 11:50 -0800
Re: which one is better John Bode <jfbode1029@gmail.com> - 2014-12-11 12:10 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-11 20:30 +0000
Re: which one is better John Bode <jfbode1029@gmail.com> - 2014-12-11 13:19 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 13:32 -0800
Re: which one is better gordonb.ygnb6@burditt.org (Gordon Burditt) - 2014-12-16 08:00 -0600
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-16 06:23 -0800
Re: which one is better gordonb.ne8xc@burditt.org (Gordon Burditt) - 2014-12-17 02:38 -0600
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-17 01:29 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-17 02:31 -0800
Re: which one is better gordonb.dwhy1@burditt.org (Gordon Burditt) - 2014-12-19 02:50 -0600
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-19 05:03 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-17 01:48 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-17 01:57 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-17 02:21 -0800
Re: which one is better Phil Carmody <pc+usenet@asdf.org> - 2014-12-18 01:53 +0200
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 00:42 -0800
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-18 11:33 +0100
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 02:46 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 03:00 -0800
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-18 12:35 +0100
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 03:53 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 12:10 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 04:45 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 04:55 -0800
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-18 14:50 +0100
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 07:16 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 07:36 -0800
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-18 16:42 +0100
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 07:52 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:06 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 03:58 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 04:09 -0800
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-18 14:51 +0100
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-18 08:24 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 08:29 -0800
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-18 10:56 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 12:08 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 04:15 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-18 12:55 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 05:12 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 13:19 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 05:41 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 13:49 +0000
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 13:09 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-18 05:22 -0800
Re: which one is better Phil Carmody <pc+usenet@asdf.org> - 2014-12-23 12:32 +0200
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-24 02:10 -0800
Re: which one is better John Bode <jfbode1029@gmail.com> - 2014-12-11 13:35 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-11 22:08 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-11 22:00 +0000
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-11 22:08 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-11 15:38 -0800
Re: which one is better glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-12 02:29 +0000
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 20:26 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-11 12:56 -0800
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-12 02:05 -0600
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 00:44 -0800
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-18 02:24 -0600
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-11 20:17 +0000
Re: which one is better Phil Carmody <pc+usenet@asdf.org> - 2014-12-18 01:14 +0200
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 06:15 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 06:25 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-11 15:00 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 07:28 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 07:42 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 08:01 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 08:37 -0800
Re: which one is better Nobody <nobody@nowhere.invalid> - 2014-12-14 05:46 +0000
Re: which one is better John Bode <jfbode1029@gmail.com> - 2014-12-11 08:14 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-11 08:26 -0800
Re: which one is better "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 08:32 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-11 16:45 +0000
Re: which one is better glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-12 02:35 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-11 20:36 -0800
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-12 05:14 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-12 06:20 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 09:23 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 10:22 +0000
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 10:43 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 11:11 +0000
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 11:43 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 04:47 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 12:51 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 05:10 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 13:25 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 05:57 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 14:15 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 06:49 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 14:51 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 06:57 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-13 01:50 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-13 02:15 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 05:36 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 13:51 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 06:00 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 14:56 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 07:08 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 07:32 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 15:36 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 08:26 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 10:27 -0800
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-12 07:46 -0800
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-15 09:57 +0100
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-15 09:54 +0100
Re: which one is better John Bode <jfbode1029@gmail.com> - 2014-12-12 10:03 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 11:14 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 11:46 +0000
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 12:05 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 12:27 +0000
Re: which one is better Phil Carmody <pc+usenet@asdf.org> - 2014-12-18 02:11 +0200
Re: which one is better glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-14 04:15 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-13 21:19 -0800
Re: which one is better Richard Damon <Richard@Damon-Family.org> - 2014-12-12 22:51 -0500
Re: which one is better gordonb.3w2i6@burditt.org (Gordon Burditt) - 2014-12-16 09:09 -0600
Re: which one is better Lynn McGuire <lmc@winsim.com> - 2014-12-11 16:12 -0600
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-11 14:29 -0800
Re: which one is better Lynn McGuire <lmc@winsim.com> - 2014-12-11 17:32 -0600
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-11 15:39 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-11 23:55 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-11 15:57 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 00:29 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-11 16:52 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 10:47 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-12 03:40 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 11:52 +0000
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-12 13:00 +0100
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 12:43 +0000
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-12 13:51 +0100
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 12:59 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 13:29 +0000
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 14:10 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 15:01 +0000
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 15:47 +0000
Re: which one is better gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-12 16:07 +0000
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-12 17:51 -0800
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-12 21:10 -0800
Re: which one is better Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-12-13 01:40 +0000
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-12 18:17 -0800
Re: which one is better Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-12-13 02:29 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-13 10:25 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-13 13:43 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-13 22:44 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-13 15:24 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-14 01:07 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-13 19:18 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-14 12:01 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-14 12:44 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-14 20:57 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-14 13:24 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-14 13:29 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-14 14:03 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-14 14:34 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-14 15:08 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-14 15:55 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 00:52 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-17 08:05 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 00:25 -0800
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-14 14:33 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-14 23:28 +0000
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-14 15:42 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-15 01:07 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 02:44 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 11:02 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 03:13 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 03:26 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-15 11:19 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 03:31 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 11:50 +0000
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-15 11:59 +0000
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-15 10:50 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-15 18:57 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 04:15 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 04:31 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 04:39 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 04:43 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 04:52 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 05:10 -0800
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-15 12:43 +0100
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 11:59 +0000
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-15 14:03 +0100
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 13:28 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 06:09 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 06:35 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-16 03:13 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-15 14:06 +0000
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-15 10:46 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 10:53 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 19:20 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 12:18 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 12:40 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 04:03 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 03:05 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-15 11:32 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 03:38 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-15 17:20 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 09:40 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 17:59 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-15 10:34 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 10:01 -0800
Re: which one is better gordonb.3j8fq@burditt.org (Gordon Burditt) - 2014-12-16 10:18 -0600
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-15 18:08 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 10:37 -0800
Re: which one is better Kaz Kylheku <kaz@kylheku.com> - 2014-12-15 21:05 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 14:10 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 14:18 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-15 22:22 +0000
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 14:58 -0800
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-15 15:34 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 17:25 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-16 02:55 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-16 03:20 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-16 03:37 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-15 05:00 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 01:41 +0000
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-18 02:33 -0600
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-18 00:42 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-14 21:47 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-14 15:55 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-14 16:03 -0800
Re: which one is better BartC <bc@freeuk.com> - 2014-12-15 00:54 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-16 10:55 +0000
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-16 11:11 +0000
Re: which one is better Ian Collins <ian-news@hotmail.com> - 2014-12-15 14:01 +1300
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-15 10:09 +0100
Re: which one is better David Brown <david.brown@hesbynett.no> - 2014-12-12 15:58 +0100
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 15:41 +0000
Re: which one is better BartC <bc@freeuk.com> - 2014-12-12 18:27 +0000
Re: which one is better Ian Collins <ian-news@hotmail.com> - 2014-12-13 08:42 +1300
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 19:59 +0000
Re: which one is better Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-12 07:39 -0800
Re: which one is better gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-12 16:05 +0000
Re: which one is better Keith Thompson <kst-u@mib.org> - 2014-12-12 08:16 -0800
Re: which one is better Richard Heathfield <invalid@see.sig.invalid> - 2014-12-12 16:43 +0000
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 14:01 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-12 06:15 -0800
Re: which one is better Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-12 16:10 +0000
Re: which one is better rick.c.hodgin@gmail.com - 2014-12-12 08:28 -0800
Re: which one is better gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-12 15:27 +0000
Re: which one is better gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-12 14:39 +0000
Re: which one is better Morris Dovey <mrdovey@iedu.com> - 2014-12-12 11:11 -0600
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 09:34 -0800
Re: which one is better Ian Collins <ian-news@hotmail.com> - 2014-12-12 21:47 +1300
Re: which one is better Ken Brody <kenbrody@spamcop.net> - 2014-12-16 12:30 -0500
Re: which one is better Stephen Sprunk <stephen@sprunk.org> - 2014-12-16 12:21 -0600
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-16 13:06 -0600
Re: which one is better Stephen Sprunk <stephen@sprunk.org> - 2014-12-16 16:44 -0600
Re: which one is better Robert Wessel <robertwessel2@yahoo.com> - 2014-12-16 18:21 -0600
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 01:04 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 02:06 -0800
Re: which one is better fir <profesor.fir@gmail.com> - 2014-12-12 02:24 -0800
Page 14 of 15 — ← Prev page 1 … 12 13 [14] 15 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-16 03:37 -0800 |
| Message-ID | <25a3a325-b393-4217-91d7-3de24a802c3a@googlegroups.com> |
| In reply to | #54664 |
ps sorry for beaing a little 'mean' to ya I am bored of mind reducing climates this is common, would like to try something more open
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-15 05:00 -0800 |
| Message-ID | <bb9a6a5c-ee7a-4f36-921c-7f1000bc8781@googlegroups.com> |
| In reply to | #54540 |
W dniu poniedziałek, 15 grudnia 2014 11:45:05 UTC+1 użytkownik fir napisał: > > hell with low endian i think i should not accept it maybe further (i usulaly tolerated that but feel a bit tired of this0 (add, thought) ps reversed order bytes can be also considered like 10000000 insteead 00000001
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-15 01:41 +0000 |
| Message-ID | <b%qjw.101584$tr6.21423@fx15.am4> |
| In reply to | #54516 |
On 14/12/2014 23:42, Malcolm McLean wrote:
> for(ch = uniget(str); ch != 0; str += uniskip(str), ch = uniget(str))
> {
> switch(ch)
> {
> case UNI_ALPHA: /* got a Greek letter alpha */
> case UNI_BETA: /* got a Greek beta */
> }
> }
>
> That's a good argument for a flexible for loop, BTW.
It's an argument for a flexible loop. But not a for-loop.
And written as a while-loop, you might be able to get away with writing
'ch = uniget(str)' just once instead of twice:
while (ch=uniget(str)) {
........
str += uniskip(str);
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2014-12-18 02:33 -0600 |
| Message-ID | <vq359al52pmvt9iblc7a0md4lp6loom4i0@4ax.com> |
| In reply to | #54510 |
On Sun, 14 Dec 2014 14:33:40 -0800 (PST), Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >On Sunday, December 14, 2014 8:57:46 PM UTC, Richard Heathfield wrote: >> Keith Thompson wrote: >> >> I'm not exactly enamoured of your list, but I'll let that pass. :-) >> But it would be remiss of us to pass up the opportunity to add a >> much-needed int type: byte. Not sbyte or ubyte, though - just byte. >> The valid range would be >> either from 0 to 255 or from 0 to UCHAR_MAX - 1 (inclusive), depending on >> just how portable this C-like language has to be. >> >I agree with byte. signed and unsigned char would go. >You have int, with the understanding that int is fast and large enough >to index any array. So malloc() would take an int. (You could calloc >a super-massive array if determined to defeat the system). >You'd also have an int16, uint8 type system, where the digit could >be anything, forcing the compiler to generate an integer of that >width. It would be understood that typically 8, 16, 32, and 64 are >fast and efficient, odd values like 42 put the compiler through >gyrations, and may be rejected by non-feature complete compilers. At that point wouldn't it make more sense just to allow the definition of the exact range for all variables? Of course you could provide some standard definitions and/or shorthands so that you didn't have to tediously specify "[-2147483648..2147483647]" on each int sized item you wanted to declare. Then there's an obvious extension to allow scaling. Maybe you could specify "S9(9)V9(2)" to define a field with a couple of digits of decimal scaling, a sign and the range to store -999,999,999.99..999,999,999.99. More seriously, Cobol syntax aside, why not? It wouldn't be very C-ish, but we're pretty far afield already.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-18 00:42 -0800 |
| Message-ID | <83a4ec39-f4ba-4b1f-a120-2d5f7762ac7f@googlegroups.com> |
| In reply to | #54915 |
On Thursday, December 18, 2014 8:31:27 AM UTC, robert...@yahoo.com wrote: > On Sun, 14 Dec 2014 14:33:40 -0800 (PST), Malcolm McLean > <malcolm.mclean5@btinternet.com> wrote: > > >I agree with byte. signed and unsigned char would go. > >You have int, with the understanding that int is fast and large enough > >to index any array. So malloc() would take an int. (You could calloc > >a super-massive array if determined to defeat the system). > >You'd also have an int16, uint8 type system, where the digit could > >be anything, forcing the compiler to generate an integer of that > >width. It would be understood that typically 8, 16, 32, and 64 are > >fast and efficient, odd values like 42 put the compiler through > >gyrations, and may be rejected by non-feature complete compilers. > > > At that point wouldn't it make more sense just to allow the definition > of the exact range for all variables? Of course you could provide > some standard definitions and/or shorthands so that you didn't have to > tediously specify "[-2147483648..2147483647]" on each int sized item > you wanted to declare. Then there's an obvious extension to allow > scaling. Maybe you could specify "S9(9)V9(2)" to define a field with > a couple of digits of decimal scaling, a sign and the range to store > -999,999,999.99..999,999,999.99. More seriously, Cobol syntax aside, > why not? It wouldn't be very C-ish, but we're pretty far afield > already. > Ada does that. It's not inherently a bad idea to have exact limits on variables with the program generating error messages if they are exceeded. But it's not C-like. C is about bit twiddling. We already have struct fields of arbitrary bit size, so the proposal is syntactic sugar for that, plus a natural extension to force the compiler to support fields larger than a register.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-14 21:47 +0000 |
| Message-ID | <Nznjw.129403$976.76721@fx37.am4> |
| In reply to | #54502 |
On 14/12/2014 20:44, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > If I were designing a C-like language from scratch, with no concern for > backward compatibility but keeping the existing type structure, I'd > probably define a distinct keyword for each type, perhaps something like > char, uchar, schar, sint, usint, int, uint, lint, ulint, llint, ullint. Would you define a fixed size for each, or have it dependent on implementation? In which case, we're back where we were before STDINT.H. And does the width gradually increase with each (so that llint is 128 bits), or will some steps stay the same size? Again, we're back with one of the problems with C where type sizes are a bit of a mystery For a different perspective from mine, C# uses these names (actually, they are built-in aliases for names such as System.Boolean): bool 1 byte char 2 sbyte 1 byte 1 short 2 ushort 2 int 4 uint 4 long 8 ulong 8 This removes any ambiguity of the size of a type (eg. is long 32 or 64 bits? Is it bigger than int or the same size?), keeps char segregated (and avoids the nonsense of a signed char type), and even adds the byte type that RH wants. They are also short and readable enough that people are less likely to want to create their own aliases. > IMHO int32_t is short enough. Sorry, no. It has the "_t" which is not really needed nor wanted (I notice your proposals don't include it!). It also has the "32" which is needed in C but not C#, but because of this, having "i32" instead of "int32" has some appeal. >> So in all, there could dozens of ways of declaring the same 32-bit int >> type. Perhaps my 4 or 5 variations aren't so many after all! > > Certainly 4 or 5 is less than, say, 19. But surely 1 is better than 4 > or 5. What exactly do you gain by having more than one name for the > same type, when the different names convey no extra information? Why > settle for being a little simpler than C when you can be a lot simpler > than C? I thought I explained all that. The main method of denoting width is by specifying the number of bits or bytes. So that's two methods, but really the same one. The alias "int32" is just for convenience, while "i32" is mainly used when generating code. For this purpose, having a short name is more efficient, and usually no-one will be reading it, but it needs to be supported. But I also like providing a choice. For example, where one of my if-statements is expected to be written if...end if, I also allow if...endif, if...end and if...fi. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-14 15:55 -0800 |
| Message-ID | <ln388hiy7c.fsf@nuthaus.mib.org> |
| In reply to | #54508 |
BartC <bc@freeuk.com> writes:
> On 14/12/2014 20:44, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> If I were designing a C-like language from scratch, with no concern for
>> backward compatibility but keeping the existing type structure, I'd
>> probably define a distinct keyword for each type, perhaps something like
>> char, uchar, schar, sint, usint, int, uint, lint, ulint, llint, ullint.
>
> Would you define a fixed size for each, or have it dependent on
> implementation? In which case, we're back where we were before STDINT.H.
> And does the width gradually increase with each (so that llint is 128
> bits), or will some steps stay the same size? Again, we're back with one
> of the problems with C where type sizes are a bit of a mystery
The premise of my list is a C-like language *that keeps the existing
type structure*. The keywords are nothing more or less than new names
for the existing zoo of sequences of keywords.
If I'm free to re-work the set of fundamental types, rather than just
their names, I'll probably do something quite different. That's a very
different question, and I haven't given it a lot of thought.
> For a different perspective from mine, C# uses these names (actually,
> they are built-in aliases for names such as System.Boolean):
>
> bool 1 byte
> char 2
> sbyte 1
> byte 1
> short 2
> ushort 2
> int 4
> uint 4
> long 8
> ulong 8
>
> This removes any ambiguity of the size of a type (eg. is long 32 or 64
> bits? Is it bigger than int or the same size?), keeps char segregated
> (and avoids the nonsense of a signed char type), and even adds the byte
> type that RH wants.
>
> They are also short and readable enough that people are less likely to
> want to create their own aliases.
Forcing char to be 2 bytes rather than 4 assumes UTF-16 (or, at the time
it was designed, probably UCS-2). For Unicode support, you need 32 bits
(well, at least 24 but 32 is easier to deal with) to store a character.
I personally like UTF-8 as an external representation for Unicode.
One thing this design loses relative to C is the ability to define "int"
as the "natural" integer type for a given platform. Whether that's a
good thing or a bad thing is arguable. I suppose C's int16fast_t can
fill that niche.
>> IMHO int32_t is short enough.
>
> Sorry, no. It has the "_t" which is not really needed nor wanted (I
> notice your proposals don't include it!). It also has the "32" which is
> needed in C but not C#, but because of this, having "i32" instead of
> "int32" has some appeal.
Sorry, yes.
int32_t and friends are standard; I know *exactly* what they mean. The
names were chosen to avoid conflicting with existing typedefs like
"int32", "i32", etc. (Some conflict is inevitable; it can be avoided by
not includeing <stdint.h> if you don't want to use it.)
I'm not saying int32_t is the name I'd choose if I were designing a new
language; it almost certainly isn't. But it's what we have, and adding
yet another layer of abbreviated obfuscation on top of that is not
helpful.
>>> So in all, there could dozens of ways of declaring the same 32-bit int
>>> type. Perhaps my 4 or 5 variations aren't so many after all!
>>
>> Certainly 4 or 5 is less than, say, 19. But surely 1 is better than 4
>> or 5. What exactly do you gain by having more than one name for the
>> same type, when the different names convey no extra information? Why
>> settle for being a little simpler than C when you can be a lot simpler
>> than C?
>
> I thought I explained all that. The main method of denoting width is by
> specifying the number of bits or bytes. So that's two methods, but
> really the same one. The alias "int32" is just for convenience, while
> "i32" is mainly used when generating code. For this purpose, having a
> short name is more efficient, and usually no-one will be reading it, but
> it needs to be supported.
>
> But I also like providing a choice. For example, where one of my
> if-statements is expected to be written if...end if, I also allow
> if...endif, if...end and if...fi.
I disagree that providing *meaningless* choice like this is useful.
(Just my opinion; it's your language, and I'm unlikely to have an
opportunity to use it.)
How exactly is the name "i32" easier for code generation than "int32"?
If I were a user of your language, what meaningful criteria would I use
to decide whether to write "i32", "int32", "int:32", or whatever?
I understand why C has 19 different ways to write "long long"; it
evolved that way, via features built on top of an earlier version of the
language that didn't have that problem. (And in practice, I rarely see
it causing any actual problems; I've never seen anyone use "int long
signed long" in real code.)
I don't understand why you'd build that kind of mess into a language
that you're designing from scratch.
--
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 | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2014-12-14 16:03 -0800 |
| Message-ID | <20f05442-c163-4df1-8c00-526334085f74@googlegroups.com> |
| In reply to | #54517 |
as to chars quite natural seem to use short char, char and long char (though here is a bit a problem as traditionally char is a short char)
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-15 00:54 +0000 |
| Message-ID | <hjqjw.49660$8q6.26925@fx25.am4> |
| In reply to | #54517 |
On 14/12/2014 23:55, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> I thought I explained all that. The main method of denoting width is by >> specifying the number of bits or bytes. So that's two methods, but >> really the same one. The alias "int32" is just for convenience, while >> "i32" is mainly used when generating code. For this purpose, having a >> short name is more efficient, and usually no-one will be reading it, but >> it needs to be supported. >> >> But I also like providing a choice. > I disagree that providing *meaningless* choice like this is useful. I disagree that it's meaningless. int:N is the official way of specifying an exact width type, in the same way that "end if" is the official way of ending an if-statement. int:N will always work, and also allows sub-byte types to be defined (1, 2 and 4-bits). However, you can appreciate that it is bit of a pig having to write int:32 and word:8 throughout a program. So aliases such as int32 (or just int) and byte are used. The aliases are defined /on top/ of the :N syntax. /So the :N syntax is mainly though there so that you can use it to create aliases!/ Except that a standard set of aliases are predefined. (There is also int*N, a hangover from older languages. This is the only real choice, to define widths as bytes, or as bits.) > (Just my opinion; it's your language, and I'm unlikely to have an > opportunity to use it.) I can tell you that in real code, it's rare to ever use ":N". It's also rare for me to use "end if", and even rarer to use a semicolon, even though statements are separated by semicolons (because EOLs usually do that job). It's just one of those languages. (This first link is of a C module which implements a big int library. Parts are auto-generated, eg. the .cl header file contains the static function prototypes. But it's still C: http://pastebin.com/3czMBgiW (note not compilable) The second link is that same module converted to my language. Because it's not original code, it's pretty much the same as C apart from details of syntax. But you won't see ":N", "end if", or ";" used! There might be the odd "i64" because I'd used that (perhaps unwisely) in the C: http://pastebin.com/d0xt2hfc ) > I don't understand why you'd build that kind of mess into a language > that you're designing from scratch. Compared with C it's not a mess. With two basic types: "int" and "word", one mechanism to control the width: ":N" or "*N", and two attribute tags: ".minvalue" and ".maxvalue", it replaces dozens of C types and macros. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-16 10:55 +0000 |
| Message-ID | <mcUjw.80873$EJ7.27981@fx18.am4> |
| In reply to | #54517 |
On 14/12/2014 23:55, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 14/12/2014 20:44, Keith Thompson wrote:
>>> IMHO int32_t is short enough.
>>
>> Sorry, no. It has the "_t" which is not really needed nor wanted (I
>> notice your proposals don't include it!). It also has the "32" which is
>> needed in C but not C#, but because of this, having "i32" instead of
>> "int32" has some appeal.
>
> Sorry, yes.
>
> int32_t and friends are standard; I know *exactly* what they mean. The
> names were chosen to avoid conflicting with existing typedefs like
> "int32", "i32", etc. (Some conflict is inevitable; it can be avoided by
> not includeing <stdint.h> if you don't want to use it.)
This is an actual example posted recently (in "C program. run time
abend, range fault" by Shiva):
long long int funcA (long long int pA, long long int pB,long long
int pC,long long int pD, long long int pF, long long int pN)
I guess you would say there is nothing really wrong with this (it's
standard C and you know exactly what each type is). For me however it's
so cluttered with longs that I can hardly see the names of the
parameters; even the function name is half-lost! And is there maybe a
single long hidden amongst the long longs? I have to check very carefully!
You don't think a carefully chosen typedef would help here?
But even using 'i64', the parameters names are too mixed up with each other:
i64 funcA (i64 pA, i64 pB, i64 pC, i65 pD, i64 pE, i64 pF);
(Actual typo deliberately left in). What it needs is another little
enhancement (since the sub-thread was discussing alternate type
denotations) to be able to write it is:
i64 funcA (i64 pA, pB, pC, pD, pE, pF);
Now suddenly, the parameter list comes to life! And in fact, now the
actual typename is less intrusive, we can use one of the official names:
int64_t funcA (int64_t pA, pB, pC, pD, pE, pF);
and it's still far more readable than the original.
(I understand the original example came from Fortran. There, the
parameter list would be presented in an even clearer manner.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-16 11:11 +0000 |
| Message-ID | <0sUjw.79224$AC.75119@fx29.am4> |
| In reply to | #54656 |
BartC wrote:
> On 14/12/2014 23:55, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 14/12/2014 20:44, Keith Thompson wrote:
>
>>>> IMHO int32_t is short enough.
>>>
>>> Sorry, no. It has the "_t" which is not really needed nor wanted (I
>>> notice your proposals don't include it!). It also has the "32" which is
>>> needed in C but not C#, but because of this, having "i32" instead of
>>> "int32" has some appeal.
>>
>> Sorry, yes.
>>
>> int32_t and friends are standard; I know *exactly* what they mean. The
>> names were chosen to avoid conflicting with existing typedefs like
>> "int32", "i32", etc. (Some conflict is inevitable; it can be avoided by
>> not includeing <stdint.h> if you don't want to use it.)
>
> This is an actual example posted recently (in "C program. run time
> abend, range fault" by Shiva):
>
> long long int funcA (long long int pA, long long int pB,long long
> int pC,long long int pD, long long int pF, long long int pN)
>
> I guess you would say there is nothing really wrong with this (it's
> standard C and you know exactly what each type is). For me however it's
> so cluttered with longs that I can hardly see the names of the
> parameters; even the function name is half-lost! And is there maybe a
> single long hidden amongst the long longs? I have to check very carefully!
>
> You don't think a carefully chosen typedef would help here?
indent is your friend.
long long int funcA(long long int pA,
long long int pB,
long long int pC,
long long int pD,
long long int pF,
long long int pN)
I think you're going to need a better excuse than that. :-)
<snip>
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-15 14:01 +1300 |
| Message-ID | <cf6q7pFqitpU1@mid.individual.net> |
| In reply to | #54502 |
Keith Thompson wrote: > > Anyway, I've never argued that C's use of multiple forms for the name of > the same type (there are 19 valid names for long long, for example) is a > good idea. It evolved by the gradual addition of qualifiers to the > existing types. Early C (based on a manual from 1974) didn't have the > "unsigned", "short", or "long" keywords; the only integer types were > char and int. Maybe it's more in the tradition of C type names to at some symmetry by adding short short int for char? Then we could have 20 valid names for char.. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-12-15 10:09 +0100 |
| Message-ID | <m6m8fe$qom$1@dont-email.me> |
| In reply to | #54442 |
On 13/12/14 02:40, Jorgen Grahn wrote: > On Fri, 2014-12-12, BartC wrote: >> On 12/12/2014 12:59, Richard Heathfield wrote: >>> David Brown wrote: >> >>>> and they don't give good enough >>>> specifications of the sizes for applications that need to know exact >>>> types. >>> >>> This is probably where we're going to fall out. I would argue that >>> applications don't need to know exact sizes. You only need to know that the >>> type is, or is not, big enough to express the range of values that you wish >>> to store in it. >> >> You haven't been writing the right sorts of applications then. >> >> For example, you sometimes have to create a struct where the fields >> match exactly those used in a foreign function or across some interface. > > Even if the exact-size types are available, you cannot guarantee that > will succeed since you don't control padding or ordering. People do > this kind of stuff too often. > I make a point of manually adding padding, keeping fields naturally aligned (when I am able to control the structure definition). Conceivably there could be targets for which the relevant fixed-size types exist and for which extra padding is added, but it is hard to imagine them - and they are not something I come across in my work. Then to double-check, I use static assertions on the size of the complete struct. This gives you something you can rely on to work on almost all systems, and to fail noisily if there is a problem. >> Or you really need to minimise storage where a 16-bit int would be >> perfect, but just using 'short' won't guarantee anything. > > I agree with some of the other points though. The exact-size types > /are/ useful quite frequently. Underusing them sucks just as much as > overusing them. > > /Jorgen >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-12-12 15:58 +0100 |
| Message-ID | <m6evqv$pid$1@dont-email.me> |
| In reply to | #54371 |
On 12/12/14 13:59, Richard Heathfield wrote: > David Brown wrote: > >> On 12/12/14 13:43, Richard Heathfield wrote: >>> David Brown wrote: >>> >>>> On 12/12/14 12:52, Richard Heathfield wrote: >>>> >>>>> One man's obvious is another man's obscure. For example, it is obvious >>>>> to me that the new int types in C99 (I refer specifically to long long >>>>> int and the various intn_t types) were unnecessary and pointless, but I >>>>> doubt very much whether it's obvious to everybody. >>>>> >>>> >>>> As a great fan of the standardised intN_t types, and a hater of >>>> home-made fixed size types, I am very curious about why you think they >>>> are obviously unnecessary and pointless. >>> >>> We already had int, short int, and long int. (We didn't actually need >>> short int or long int, either.) >>> >> >> But those don't cover the range of integer types supported by modern >> processors or modern cpus, > > There is no upper limit on the size of int. It must be at least 16 bits, but > can be as wide as you like. If you need a smaller type, char must be at > least 8 bits. If you need a smaller type than 8 bits, you're out of luck > even with the C99 types. As for modern processors or modern cpus, the C > Standard doesn't trouble itself with such trivialities. :-) Are you trying to say that no one should ever need integer values outside the range of the processor's fastest type (of at least 16 bit), or that compilers should make their "int" as big as the largest integer anyone needs, regardless of the speed and size costs? Because those are the only two options if "int" is the only integer type available. > >> and they don't give good enough >> specifications of the sizes for applications that need to know exact >> types. > > This is probably where we're going to fall out. I would argue that > applications don't need to know exact sizes. You only need to know that the > type is, or is not, big enough to express the range of values that you wish > to store in it. Then I would argue that you live (as a programmer) in a very small world. Roughly put, whenever you have to transfer binary data into or out of a program, you need exact sizes for the transfers. That means you either need to pass everything through char pointers, with all the complications and inefficiencies that involves, or you need to use sized integer types. This applies to anything working with files, or using binary network protocols. Of course it also applies to low-level code, and to practically everything in embedded programming. It also applies to shared libraries or any other situation where code might involving combining parts that may be generated by different types of I agree that most of the time it only matters that the range is big enough - but sometimes exact size is also critical. > >> >> Compilers have always been free to implement "extended integer types" >> providing such features - the <stdint.h> types gave a standard defined >> way to name these types (when they exist on the target). >> >> It would have been possible for the C standards to specify that a char >> is 8-bit, short is 16-bit, int is 32-bit and long is 64-bit. > > I think that would have been a mistake, but yes, it could have worked. I agree that it would have been a mistake. I think the right thing would have been to define the fixed size types at the start, and make "int" a typedef for int_fast16_t. I would have preferred the C specs to have insisted on two's complement power-of-two sized integers as the basic types, and allowed additional types only as "extended integer types". > And > if so, then when the inevitable time came for a 128-bit type, it should have > been called very long, not long long. (Thereafter, you can have very very > long, very very very long, and so on.) No, it can be called something like "__int128_t", as that is a reserved name. Then <stdint.h> can typedef it to int128_t. > >> Then we >> would not need the <stdint.h> types (at least, not until 128-bit types >> become common). But that's not the way the C standards are written. > > No. They're written in such a way that the implementor is free to offer a > 4096-bit int type if need be. (The day may well come when this won't sound > quite so ludicrous as it does at the time of writing.) >
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-12 15:41 +0000 |
| Message-ID | <c1Eiw.90786$be7.8963@fx14.am4> |
| In reply to | #54391 |
David Brown wrote: > On 12/12/14 13:59, Richard Heathfield wrote: >> David Brown wrote: >> >>> On 12/12/14 13:43, Richard Heathfield wrote: >>>> David Brown wrote: >>>> >>>>> On 12/12/14 12:52, Richard Heathfield wrote: >>>>> >>>>>> One man's obvious is another man's obscure. For example, it is >>>>>> obvious to me that the new int types in C99 (I refer specifically to >>>>>> long long int and the various intn_t types) were unnecessary and >>>>>> pointless, but I doubt very much whether it's obvious to everybody. >>>>>> >>>>> >>>>> As a great fan of the standardised intN_t types, and a hater of >>>>> home-made fixed size types, I am very curious about why you think they >>>>> are obviously unnecessary and pointless. >>>> >>>> We already had int, short int, and long int. (We didn't actually need >>>> short int or long int, either.) >>>> >>> >>> But those don't cover the range of integer types supported by modern >>> processors or modern cpus, >> >> There is no upper limit on the size of int. It must be at least 16 bits, >> but can be as wide as you like. If you need a smaller type, char must be >> at least 8 bits. If you need a smaller type than 8 bits, you're out of >> luck even with the C99 types. As for modern processors or modern cpus, >> the C Standard doesn't trouble itself with such trivialities. :-) > > Are you trying to say that no one should ever need integer values > outside the range of the processor's fastest type (of at least 16 bit), > or that compilers should make their "int" as big as the largest integer > anyone needs, regardless of the speed and size costs? Because those are > the only two options if "int" is the only integer type available. No, I don't think I'm trying to say that. I think I'm trying to say that the abstract machine that "is" C doesn't need to trouble itself with such things. Nor did the absence of such types stop programmers from achieving what they needed to achieve. >>> and they don't give good enough >>> specifications of the sizes for applications that need to know exact >>> types. >> >> This is probably where we're going to fall out. I would argue that >> applications don't need to know exact sizes. You only need to know that >> the type is, or is not, big enough to express the range of values that >> you wish to store in it. > > Then I would argue that you live (as a programmer) in a very small world. I think we all do, don't we? We live in the world of our own personal experience, and that is very large to us, but very small to people looking in from outside. But a program that does *not* depend on specific integer sizes can run in more environments than one that does depend on them, and so it might be argued that such a program's world is actually larger than that of a program that nails itself to particular integer sizes. > Roughly put, whenever you have to transfer binary data into or out of a > program, you need exact sizes for the transfers. And yet, 99.99034% of the time, you need the exact sizes that you already have (int, and perhaps long and short int). The time at which it is most likely to become a problem is when you have to transfer data from one machine to another, at which point integer sizes are the least of your problems, because you have to worry about endianness, struct padding, and so on. To get around these problems, you're probably going to be using unsigned char * anyway. > That means you either > need to pass everything through char pointers, with all the > complications and inefficiencies that involves, or you need to use sized > integer types. This applies to anything working with files, or using > binary network protocols. Of course it also applies to low-level code, > and to practically everything in embedded programming. It also applies > to shared libraries or any other situation where code might involving > combining parts that may be generated by different types of > > I agree that most of the time it only matters that the range is big > enough - but sometimes exact size is also critical. I'll grant "sometimes". Sometimes exact file size is critical, too, but we have to rely on the implementation to provide a way to do that, because the ISO folks don't consider it important enough to standardise. I can't help wishing they'd felt the same way about exact-size integer types. >>> Compilers have always been free to implement "extended integer types" >>> providing such features - the <stdint.h> types gave a standard defined >>> way to name these types (when they exist on the target). >>> >>> It would have been possible for the C standards to specify that a char >>> is 8-bit, short is 16-bit, int is 32-bit and long is 64-bit. >> >> I think that would have been a mistake, but yes, it could have worked. > > I agree that it would have been a mistake. I think the right thing > would have been to define the fixed size types at the start, and make > "int" a typedef for int_fast16_t. I would have preferred the C specs to > have insisted on two's complement power-of-two sized integers as the > basic types, and allowed additional types only as "extended integer > types". If we're going to rewrite history so as to include fixed widths, my choice would be: byte - 8 bits int - 16 bits lint - 32 bits vlint - 64 bits vvlint - 128 bits vvvlint - 256 bits (etc) with v*lint being optional for the implementor (in C90) but reserved for that purpose alone. > >> And >> if so, then when the inevitable time came for a 128-bit type, it should >> have been called very long, not long long. (Thereafter, you can have very >> very long, very very very long, and so on.) > > No, it can be called something like "__int128_t", as that is a reserved > name. Then <stdint.h> can typedef it to int128_t. Yes, I know - but it's so *ugly*. -- 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 | 2014-12-12 18:27 +0000 |
| Message-ID | <YrGiw.77697$fX6.64326@fx26.am4> |
| In reply to | #54398 |
On 12/12/2014 15:41, Richard Heathfield wrote:
> David Brown wrote:
>
>> On 12/12/14 13:59, Richard Heathfield wrote:
>>> This is probably where we're going to fall out. I would argue that
>>> applications don't need to know exact sizes. You only need to know that
>>> the type is, or is not, big enough to express the range of values that
>>> you wish to store in it.
>>
>> Then I would argue that you live (as a programmer) in a very small world.
>
> I think we all do, don't we? We live in the world of our own personal
> experience, and that is very large to us, but very small to people looking
> in from outside. But a program that does *not* depend on specific integer
> sizes can run in more environments than one that does depend on them, and so
> it might be argued that such a program's world is actually larger than that
> of a program that nails itself to particular integer sizes.
>
>> Roughly put, whenever you have to transfer binary data into or out of a
>> program, you need exact sizes for the transfers.
>
> And yet, 99.99034% of the time, you need the exact sizes that you already
> have (int, and perhaps long and short int). The time at which it is most
> likely to become a problem is when you have to transfer data from one
> machine to another, at which point integer sizes are the least of your
> problems, because you have to worry about endianness, struct padding, and so
> on. To get around these problems, you're probably going to be using unsigned
> char * anyway.
My experience has been in directly dealing with hardware (in creating
and implementing languages to do so), and also having those languages
deal with OSes and other libraries all using interfaces specified in
different languages from mine.
Then the small matter of the width of an integer type, for example, is
absolutely crucial. I suppose if you spend all your time writing in the
same language then you can afford to ignore such minor details.
Turn that around, and imagine that it is C having to use interfaces
specified in a different language. Maybe you are spoilt in that many
interfaces (Win32 for example) are already in C (of sorts) and you've
never come across the problem.
The endianness thing won't matter on the same machine. The struct
padding needs to be addressed (and in fact C has some control over that).
What you don't want to do, out of obstinacy in refusing to use int16_t,
is having to write, on top of all the support needed:
a = getfield_s16(&r,field_offset);
putfield_s16(&r,field_offset,b);
instead of:
a = r.field;
r.field = b;
or not being able to initiliase a struct using {10,20,30,40}.
> If we're going to rewrite history so as to include fixed widths, my choice
> would be:
>
> byte - 8 bits
> int - 16 bits
> lint - 32 bits
> vlint - 64 bits
> vvlint - 128 bits
> vvvlint - 256 bits (etc)
Bad choices I think (considering most computers are going to have a
natural 32-bit type, with 16-bits either requiring a longer instruction,
or perhaps not supported at all).
You want a basic int size that is unspecified (or set to some default
determined by the compiler version), and at most one or two sizes that
are relative to that. But you also want absolute sizes.
(FWIW, in my latest language project I use this family of /signed/ int
types, with all the various ways of denoting them
8-bit int8 int:8 int*1 (int8_t in C)
16-bit int16 int:16 int*2 (int16_t)
32-bit int32 int:32 int*4 int (int32_t)
64-bit int64 int:64 int*8 dint (int64_t)
Here the default int type is just called 'int', and at the moment maps
to a 32-bit int, and there is one relative type 'dint'. The syntax
allows widths of any size to be specified too.
Notice I was able to easily quick a C version, which would have been
difficult without the intN_t types.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-13 08:42 +1300 |
| Message-ID | <cf0uppFqitnU1@mid.individual.net> |
| In reply to | #54398 |
Richard Heathfield wrote: > David Brown wrote: > >> Roughly put, whenever you have to transfer binary data into or out of a >> program, you need exact sizes for the transfers. > > And yet, 99.99034% of the time, you need the exact sizes that you already > have (int, and perhaps long and short int). The time at which it is most > likely to become a problem is when you have to transfer data from one > machine to another, at which point integer sizes are the least of your > problems, because you have to worry about endianness, struct padding, and so > on. To get around these problems, you're probably going to be using unsigned > char * anyway. The bigger problem is when you need to recompile your code from 16 to 32 bit and from 32 to 64 bit on the same system. Too much code made assumptions about the sizes of types (especially long), hence time wasted "porting" code to 64 bits. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-12 19:59 +0000 |
| Message-ID | <tOHiw.167130$MH.97233@fx12.am4> |
| In reply to | #54427 |
Ian Collins wrote: <snip> > The bigger problem is when you need to recompile your code from 16 to 32 > bit and from 32 to 64 bit on the same system. Too much code made > assumptions about the sizes of types (especially long), hence time > wasted "porting" code to 64 bits. This, I think, is the nub of the problem - people making unfounded assumptions about type sizes. This was actually a serious problem at Microsoft in, I think, the early 1990s. Steve Maguire wrote: '...so much of [their code] is littered with things like +2 instead of +sizeof(int), the comparison of unsigned values to 0xFFFF instead of to something like UINT_MAX, and the use of int in data structures when they really meant to use a 16-bit data type[1]... As one programmer put it a couple of years ago, "The compiler group would never change something that would break all of our code." That programmer was wrong.' [1] It seems Mr Maguire would approve of int16_t etc. :-) -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-12 07:39 -0800 |
| Message-ID | <23319781-0408-4d97-982b-dc22aae9311d@googlegroups.com> |
| In reply to | #54371 |
On Friday, December 12, 2014 12:59:11 PM UTC, Richard Heathfield wrote: > David Brown wrote: > > > and they don't give good enough > > specifications of the sizes for applications that need to know exact > > types. > > This is probably where we're going to fall out. I would argue that > applications don't need to know exact sizes. You only need to know that the > type is, or is not, big enough to express the range of values that you wish > to store in it. > Sometimes you need to convert between bits and numbers and back, efficiently. Generally, however, what you need to know is that an integer is big enough to index an array, and can hold a negative value of the same size.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2014-12-12 16:05 +0000 |
| Message-ID | <m6f3os$h10$1@news.xmission.com> |
| In reply to | #54397 |
In article <23319781-0408-4d97-982b-dc22aae9311d@googlegroups.com>, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >On Friday, December 12, 2014 12:59:11 PM UTC, Richard Heathfield wrote: >> David Brown wrote: >> >> > and they don't give good enough >> > specifications of the sizes for applications that need to know exact >> > types. >> >> This is probably where we're going to fall out. I would argue that >> applications don't need to know exact sizes. You only need to know that the >> type is, or is not, big enough to express the range of values that you wish >> to store in it. >> >Sometimes you need to convert between bits and numbers and back, efficiently. >Generally, however, what you need to know is that an integer is big enough >to index an array, and can hold a negative value of the same size. > Heathfield's comment implies a pretty narrow definition of "applications programmer". A common form of elitism. It is a smug attitude that most programmers do little that's any more advanced than "hello, world". Note that he is entirely correct in the implicit assertion that "hello, world" programmers do not need to know the sizes of anything. P.S. Now just wait for someone to go mining the source of the GNU version of "hello, world" and tell me that, yes, indeed, that version does do stuff that requires knowledge of sizes... -- Faith doesn't give you the answers; it just stops you from asking the questions.
[toc] | [prev] | [next] | [standalone]
Page 14 of 15 — ← Prev page 1 … 12 13 [14] 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web