Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #146566 > unrolled thread
| Started by | DFS <nospam@dfs.com> |
|---|---|
| First post | 2019-10-04 13:00 -0400 |
| Last post | 2019-10-15 11:19 -0700 |
| Articles | 20 on this page of 483 — 31 participants |
Back to article view | Back to comp.lang.c
Sort char array DFS <nospam@dfs.com> - 2019-10-04 13:00 -0400
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-04 17:06 +0000
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-04 21:55 +0300
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-04 19:24 -0400
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-05 13:08 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-04 21:06 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 01:21 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 01:23 +0100
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-04 20:49 -0400
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-04 20:45 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 13:14 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-05 14:35 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 17:12 +0100
Re: Sort char array luser droog <luser.droog@gmail.com> - 2019-10-05 09:26 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 17:51 +0100
Re: Sort char array chad <cdalten@gmail.com> - 2019-10-15 09:00 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-15 19:29 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-05 18:13 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 21:09 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-05 13:22 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 21:45 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-06 00:17 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 16:32 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-06 15:54 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-06 08:07 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-06 17:39 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-06 12:52 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-06 21:26 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-07 01:37 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 01:10 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-06 17:32 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 02:02 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 09:41 +0200
Re: Sort char array mark.bluemel@gmail.com - 2019-10-07 00:39 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 10:59 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-07 13:19 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 12:42 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 13:57 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 15:01 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-07 17:42 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 17:20 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-07 19:33 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 18:22 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 02:27 +0300
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-07 17:02 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 08:53 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 12:28 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-08 11:47 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 02:02 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 00:50 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-10 03:03 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 01:51 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-10 10:31 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 11:57 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-10 14:24 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 14:41 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-10 16:17 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 18:09 +0100
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-10 17:38 +0000
Re: Sort char array already5chosen@yahoo.com - 2019-10-10 01:37 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-10 11:05 -0700
Re: Sort char array Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-10-10 14:33 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-10 12:20 -0700
Re: Sort char array Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-10-10 16:00 -0400
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-10 23:43 +0300
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-10 14:12 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-11 01:04 +0300
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-10 22:17 +0000
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-10 15:24 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 12:57 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-11 00:53 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-11 00:50 +0100
Re: Sort char array Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2019-10-12 03:42 +0800
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-11 22:16 +0100
Re: Sort char array raltbos@xs4all.nl (Richard Bos) - 2019-10-14 16:08 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 19:20 +0100
Re: Sort char array Ian Collins <ian-news@hotmail.com> - 2019-10-15 07:40 +1300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 20:24 +0100
Re: Sort char array Ian Collins <ian-news@hotmail.com> - 2019-10-15 08:33 +1300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 20:52 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-14 16:18 -0700
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-14 23:42 +0000
Re: Sort char array Ian Collins <ian-news@hotmail.com> - 2019-10-15 16:40 +1300
Re: Sort char array chad <cdalten@gmail.com> - 2019-10-15 05:10 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-14 12:00 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 12:33 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 14:22 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 15:35 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 16:15 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 20:24 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 20:42 +0100
Re: Sort char array already5chosen@yahoo.com - 2019-10-09 10:40 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 20:31 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-09 12:02 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 22:21 +0200
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-09 21:31 +0000
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-09 15:35 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-10 00:32 +0300
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-10 10:40 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-10 10:42 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-10 15:58 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-13 21:37 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 19:56 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-14 00:56 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 11:04 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 13:33 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-18 10:57 +0100
Re: Sort char array mark.bluemel@gmail.com - 2019-10-18 05:56 -0700
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-18 06:10 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-18 15:24 +0200
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-18 09:41 -0400
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-18 07:20 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-18 15:29 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-19 06:04 -0700
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-18 13:36 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-18 15:17 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-18 16:44 +0100
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-18 08:49 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-18 17:56 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-18 09:03 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-18 19:14 +0200
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-18 23:45 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-18 23:06 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-18 23:45 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 00:49 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-19 01:19 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 11:16 +0100
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-19 03:56 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-19 13:29 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-19 08:44 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 14:05 +0100
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-19 07:35 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 18:01 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-19 20:14 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 23:12 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-20 00:45 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 10:24 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 14:39 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-20 06:11 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 15:36 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 14:36 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 16:47 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 19:16 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 21:37 +0200
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-20 09:54 -0400
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-19 13:24 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 13:40 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-19 13:13 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-19 13:57 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 15:04 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-20 06:21 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 15:40 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-20 07:29 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 16:49 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 15:10 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 21:26 +0200
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 19:56 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 23:06 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 23:08 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-21 00:25 +0200
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 22:33 +0000
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 22:57 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-21 00:14 +0100
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 23:48 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-21 11:20 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-21 12:36 +0100
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 22:48 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-21 01:20 +0200
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-22 18:00 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-22 10:51 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-22 19:19 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 21:27 +0100
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-20 14:46 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 23:34 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-18 16:35 +0100
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-18 17:01 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-18 19:15 +0200
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-18 19:01 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 13:14 +0200
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 11:25 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 15:07 +0200
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-18 16:58 +0000
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 08:06 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 19:55 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-15 03:24 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-15 12:39 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-15 04:03 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-15 14:30 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-18 05:59 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-19 00:31 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-23 04:46 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-14 12:06 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-11 10:30 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-11 02:26 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-11 12:41 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-11 11:34 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 12:06 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-12 11:55 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-13 13:23 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-13 13:30 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-14 16:13 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-11 02:00 +0300
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-11 10:33 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-10 01:01 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-10 11:19 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 12:18 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-10 16:15 +0100
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-10 15:32 +0000
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-10 21:03 +0100
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-10 20:36 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 17:16 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-11 03:25 +0100
Re: Sort char array David Kleinecke <dkleinecke@gmail.com> - 2019-10-10 22:36 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-11 12:10 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-12 00:26 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 00:44 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 12:18 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 12:42 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 15:00 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 15:29 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 19:13 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 19:04 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 20:13 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 01:36 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 22:52 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-12 23:06 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 10:25 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-13 16:42 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 18:03 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-13 19:50 +0200
Re: Sort char array already5chosen@yahoo.com - 2019-10-14 12:27 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-15 10:26 +0200
Re: Sort char array Ike Naar <ike@sdf.lonestar.org> - 2019-10-14 21:02 +0000
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-14 01:39 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 01:51 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 12:16 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 10:45 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 13:16 +0300
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-14 03:34 -0700
Lack of language I/O support (was Re: Sort char array, many posts ago) mark.bluemel@gmail.com - 2019-10-14 03:54 -0700
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) scott@slp53.sl.home (Scott Lurndal) - 2019-10-14 13:36 +0000
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-10-14 09:49 -0400
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) mark.bluemel@gmail.com - 2019-10-14 07:15 -0700
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) scott@slp53.sl.home (Scott Lurndal) - 2019-10-14 14:55 +0000
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) mark.bluemel@gmail.com - 2019-10-14 08:10 -0700
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) scott@slp53.sl.home (Scott Lurndal) - 2019-10-14 16:21 +0000
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) Siri Cruise <chine.bleu@yahoo.com> - 2019-10-14 09:25 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 14:57 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 08:24 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 16:40 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-14 16:17 +0200
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-14 23:45 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-15 00:03 +0100
Re: Sort char array Thiago Adams <thiago.adams@gmail.com> - 2019-10-14 05:30 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 16:05 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 07:55 -0700
Re: Sort char array Thiago Adams <thiago.adams@gmail.com> - 2019-10-14 10:58 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 14:36 +0100
Re: Sort char array Thiago Adams <thiago.adams@gmail.com> - 2019-10-14 11:03 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 19:28 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 08:17 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-15 00:26 +0300
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-15 11:55 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-16 04:24 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-16 07:19 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-16 18:17 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-17 05:43 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-17 18:01 +0300
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-19 00:39 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-19 06:00 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-11-08 18:38 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 22:03 -0800
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 18:49 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 00:25 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 23:44 -0400
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-12 13:45 +0100
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-13 19:05 -0400
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-12 13:16 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-13 00:12 +0100
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-13 14:18 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 23:10 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-14 23:52 -0400
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-15 11:48 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-15 18:14 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-15 20:31 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-15 20:11 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-15 20:34 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-15 22:05 +0200
Re: Sort char array already5chosen@yahoo.com - 2019-10-15 13:27 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-16 10:11 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-16 12:42 +0200
Re: Sort char array already5chosen@yahoo.com - 2019-10-16 04:02 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-17 05:51 -0700
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-18 10:18 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-18 12:05 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-23 05:42 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-23 05:02 -0700
Re: Sort char array raltbos@xs4all.nl (Richard Bos) - 2019-10-14 15:32 +0000
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 08:57 -0700
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-14 10:13 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-14 23:59 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-17 06:08 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-10 01:20 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-10 20:15 -0400
Re: Sort char array already5chosen@yahoo.com - 2019-10-11 04:00 -0700
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-11 07:53 -0400
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-11 11:20 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-11 11:16 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-11 14:43 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-11 11:51 -0700
Re: Sort char array raltbos@xs4all.nl (Richard Bos) - 2019-10-12 07:46 +0000
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 09:49 -0400
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 12:29 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 12:20 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 13:38 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-12 12:17 -0700
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 20:20 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-12 20:39 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-13 21:32 +0300
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-14 07:38 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 08:13 -0700
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-15 07:45 -0400
Re: Sort char array chad <cdalten@gmail.com> - 2019-10-15 05:12 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-15 13:04 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-17 10:14 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-15 12:24 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-16 04:12 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-16 14:21 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-16 19:12 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-16 16:33 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-16 19:48 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-18 06:57 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-13 21:22 +0300
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-11 01:02 +0300
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 17:01 +0200
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 12:24 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 12:18 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 14:11 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 15:22 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 17:17 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 20:52 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 00:45 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-07 15:57 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 02:32 +0300
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 10:06 +0200
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 03:21 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 00:34 +0300
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 11:23 +0200
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 09:59 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 11:39 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 14:05 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 15:06 +0100
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-08 14:38 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 17:34 +0200
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-08 16:38 +0000
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-08 07:55 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 18:31 +0300
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-08 16:39 +0000
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 19:57 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 18:09 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 22:16 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 23:58 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 22:19 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 17:39 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 00:12 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-09 09:48 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 19:49 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 17:29 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 17:56 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 22:25 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 00:02 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 13:41 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 14:03 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 15:53 +0200
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-09 14:39 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 15:58 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 22:43 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-11 01:45 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-11 01:00 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 12:01 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 20:35 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-13 21:17 +0300
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-14 07:45 -0400
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 14:53 +0300
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-09 02:02 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 10:36 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-07 09:05 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-07 08:59 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-07 09:00 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 17:02 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-06 19:57 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 06:38 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 17:14 +0100
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-05 13:06 -0400
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 02:24 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 05:13 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 16:04 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 07:13 -0700
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-06 18:23 -0400
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 15:41 +0300
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-06 12:46 -0700
Re: Sort char array Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2019-10-07 04:00 +0800
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 09:46 +0200
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-07 22:49 -0400
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 12:24 +0300
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-08 09:28 -0400
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 23:49 +0300
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-08 18:18 -0400
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 03:34 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 14:36 +0300
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 15:34 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 05:54 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 16:01 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 06:31 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 00:30 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-09 10:14 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 06:26 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-05 02:46 +0100
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-05 00:19 -0400
Re: Sort char array Barry Schwarz <schwarzb@dqel.com> - 2019-10-04 22:26 -0700
Re: OT Re: Sort char array Barry Schwarz <schwarzb@delq.com> - 2019-10-05 06:33 -0700
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-05 16:46 +0200
Re: Sort char array "Oliver S." <Follow.Me@gmx.net> - 2019-10-05 16:54 +0200
Re: Sort char array "Oliver S." <Follow.Me@gmx.net> - 2019-10-05 17:14 +0200
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-05 11:34 -0400
Re: Sort char array Mateusz Viste <mateusz@wont.tell> - 2019-10-05 15:43 +0000
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-05 17:29 -0400
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 02:14 -0700
Re: Sort char array Mateusz Viste <mateusz@wont.tell> - 2019-10-06 09:58 +0000
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 03:11 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 03:35 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 15:57 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-06 16:12 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 02:06 -0700
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-07 07:28 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 17:51 +0100
Re: Sort char array Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2019-10-08 18:31 +0800
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 03:59 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 02:14 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 14:34 +0300
Re: Sort char array Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2019-10-08 22:41 +0800
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 02:03 -0700
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 13:25 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 15:45 +0300
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 14:59 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 16:11 +0300
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 15:15 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 16:20 +0300
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 15:35 +0200
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-06 13:04 -0400
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 08:44 -0700
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 18:01 +0200
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 09:42 -0700
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 19:21 +0200
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-06 21:51 +0100
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-07 04:41 +0200
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 16:45 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-07 19:11 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 21:10 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 00:43 +0300
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-07 15:51 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 01:48 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-07 00:42 -0400
Re: Sort char array John Bode <jfbode1029@gmail.com> - 2019-10-07 16:05 -0700
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-07 20:06 -0400
Re: Sort char array John Bode <jfbode1029@gmail.com> - 2019-10-08 08:34 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-08 01:09 +0100
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-07 20:12 -0400
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-08 01:44 +0100
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-07 22:02 -0400
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-08 03:24 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-09 01:42 +0100
Re: Sort char array John Bode <jfbode1029@gmail.com> - 2019-10-09 11:14 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-10 00:52 +0300
Re: Sort char array John Bode <jfbode1029@gmail.com> - 2019-10-08 08:20 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 00:20 +0300
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-08 18:48 -0400
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 02:07 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 02:29 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 09:43 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-09 09:37 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 02:22 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-15 11:19 -0700
Page 14 of 25 — ← Prev page 1 … 12 13 [14] 15 16 … 25 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-14 08:17 -0700 |
| Message-ID | <86imor73wp.fsf@linuxsc.com> |
| In reply to | #146926 |
Anton Shepelev <anton.txt@gmail.com> writes: > Can C's va_arg facilily be extended with the ability to > query the type of each argument rather than to require it? > This would make it possible to implement a typed tprintf() > without type specifiers: > > tprintf( "My name is %, and I am % years old.\n", "Bob", 8 ); This example, and others like it, can already be done in standard C11 using _Generic and variadic macros (and of course defining an underlying function to do the actual printing). No extension to varargs is needed.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-15 00:26 +0300 |
| Message-ID | <20191015002630.213bbd842f2f5aa17c73015d@gmail.com> |
| In reply to | #146953 |
Tim Rentsch to Anton Shepelev: > > tprintf( "My name is %, and I am % years old.\n", "Bob", 8 ); > > Why don't you try writing one, in standard C11 using the > existing C preprocessor? See how far you can get. > [...] > This example, and others like it, can already be done in > standard C11 using _Generic and variadic macros (and of > course defining an underlying function to do the actual > printing). No extension to varargs is needed. I found the C preprocessor so hard that I failed to write even a simple macro for the generation of function names with a custom prefix, e.g. MY_Func1, MY_Func2 vs. HIS_Func1 and HIS_Func2, where MY and HIS may be #define'd. I became stuck at macro concatenation and stringizing via # and ##. Maybe I should have tried harder. As to trpintf(), I don't have the remotest idea of how it could be done. The macro should read the parameters, analyse their types with _Generic, construct a list or array of their types, pass it to another function that should add the necessary type specifiers to the format string and somehow call the native printf()? But can a macro loop though its arguments, process each with _Generic and concatenate the result into a comma-separated list? I don't think the preprocessor has a concept of loops and variables... -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2019-10-15 11:55 +0300 |
| Message-ID | <20191015115554.645b7e6dbec83bfeccc9aaa8@g{oogle}mail.com> |
| In reply to | #146976 |
I wrote: >I found the C preprocessor so hard that I failed to write >even a simple macro for the generation of function names >with a custom prefix, e.g. MY_Func1, MY_Func2 vs. HIS_Func1 >and HIS_Func2, where MY and HIS may be #define'd. I became >stuck at macro concatenation and stringizing via # and ##. >Maybe I should have tried harder. I grew ashemed and wrote this yestertday. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-16 04:24 -0700 |
| Message-ID | <867e5553x0.fsf@linuxsc.com> |
| In reply to | #146985 |
Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> I wrote:
>
>> I found the C preprocessor so hard that I failed to write
>> even a simple macro for the generation of function names
>> with a custom prefix, e.g. MY_Func1, MY_Func2 vs. HIS_Func1
>> and HIS_Func2, where MY and HIS may be #define'd. I became
>> stuck at macro concatenation and stringizing via # and ##.
>> Maybe I should have tried harder.
>
> I grew ashemed and wrote this yestertday.
It takes courage to admit (especially in this forum) when there
is something one doesn't know or doesn't understand. Rather
than feel ashamed, take pride for being courageous here.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-16 07:19 -0700 |
| Message-ID | <8636fs6adz.fsf@linuxsc.com> |
| In reply to | #146976 |
Anton Shepelev <anton.txt@gmail.com> writes:
> Tim Rentsch to Anton Shepelev:
>
>>> tprintf( "My name is %, and I am % years old.\n", "Bob", 8 );
>>
>> Why don't you try writing one, in standard C11 using the
>> existing C preprocessor? See how far you can get.
>> [...]
>> This example, and others like it, can already be done in
>> standard C11 using _Generic and variadic macros (and of
>> course defining an underlying function to do the actual
>> printing). No extension to varargs is needed.
>
> I found the C preprocessor so hard that I failed to write
> even a simple macro for the generation of function names
> with a custom prefix, e.g. MY_Func1, MY_Func2 vs. HIS_Func1
> and HIS_Func2, where MY and HIS may be #define'd. I became
> stuck at macro concatenation and stringizing via # and ##.
> Maybe I should have tried harder.
The C preprocessor is tricky. I don't think I would have figured
out the patterns needed to make this stuff work if I had tried to
deduce them from first principles. Fortunately there are lots of
smart people out there who can figure them out and sometimes they
post about them. Looking at your specific case, what I think you
mean is definitions something like this:
#define DECLARE_FUNCTIONS_1(who) int who ## _f1(), who ## _f2()
#define MY fred
#define HIS barney
DECLARE_FUNCTIONS_1( MY );
DECLARE_FUNCTIONS_1( HIS );
Unfortunately this doesn't do what we want. Expanding these
lines with gcc -std=c99 -pedantic -E gives
int MY_f1(), MY_f2();
int HIS_f1(), HIS_f2();
so the macro arguments have not been expanded. This result
occurs because of how the ## operator is defined. The trick is
to invoke another level of macro call, to give the arguments a
chance to expand:
#define DECLARE_FUNCTIONS_2(who) DECLARE_FUNCTIONS_1(who)
DECLARE_FUNCTIONS_2( MY );
DECLARE_FUNCTIONS_2( HIS );
Using the second macro, which simply invokes the first, does what
we want:
int fred_f1(), fred_f2();
int barney_f1(), barney_f2();
Try tracing through what happens during macro processing, using
the descriptions in the C standard for how expansion works, and
see if it makes sense what is going on and why.
> As to trpintf(), I don't have the remotest idea of how it
> could be done. The macro should read the parameters,
> analyse their types with _Generic, construct a list or array
> of their types, pass it to another function that should add
> the necessary type specifiers to the format string and
> somehow call the native printf()?
Let's pause here and pursue this idea. For simplicity let's
assume the call to trprintf() has at least one argument besides
the format string. So a trprintf() macro would look something
like this (disclaimer: typed in, not compiled or tested in any
way):
#define trprint( format, ... ) ( \
printf( FIX_FORMAT( format, __VA_ARGS__ ), __VA_ARGS__ ) \
)
#define FIX_FORMAT( f, ... ) ( \
adjust_format_string( \
f, \
HOW_MANY( __VA_ARGS__ ), \
TYPE_CODES( __VA_ARGS__ ) \
) \
)
const char *adjust_format_string( const char *, int, int[] );
This definition looks like it will do the job, provided we can
give suitable definitions for the HOW_MANY() and TYPE_CODES()
macros. The writing of adjust_format_string() is a fairly
straightforward exercise in ordinary C string processing.
Continuing below...
> But can a macro loop
> though its arguments, process each with _Generic and
> concatenate the result into a comma-separated list? I don't
> think the preprocessor has a concept of loops and
> variables...
The C preprocessor cannot do looping. (I feel obliged to say
that I remember reading somewhere once that maybe it can, but
I've never been able to find or figure out how, so let's take
it as given that looping is not possible.)
If we can't handle the general case, let's try something more
modest. Suppose we limit ourselves to allowing up to nine
printf values. If we do that, a HOW_MANY() macro can be
defined as follows:
#define HOW_MANY( ... ) \
JUST_10th( __VA_ARGS__, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 )
#define JUST_10th( _1, _2, _3, _4, _5, _6, _7, _8, _9, it, ... ) it
This idea allows us to find how many arguments there are, as long
as there is at least one and no more than nine.
Now how about the type codes? At the bottom we need a base case:
#define TYPE_CODE_1( a ) _Generic( (a), /*...*/ )
I expect you can fill in the /*...*/ suitably, at least for all
the usual cases.
We can define specific type code macros for each specific case of
how many arguments are present. To make the definitions simpler
we can use (disclaimer: not tested!) variadic parameters:
#define TCODEx_9( a, ... ) TYPE_CODE_1( a ), TCODE_8x( __VA_ARGS__ )
#define TCODEx_8( a, ... ) TYPE_CODE_1( a ), TCODE_7x( __VA_ARGS__ )
#define TCODEx_7( a, ... ) TYPE_CODE_1( a ), TCODE_6x( __VA_ARGS__ )
#define TCODEx_6( a, ... ) TYPE_CODE_1( a ), TCODE_5x( __VA_ARGS__ )
#define TCODEx_5( a, ... ) TYPE_CODE_1( a ), TCODE_4x( __VA_ARGS__ )
#define TCODEx_4( a, ... ) TYPE_CODE_1( a ), TCODE_3x( __VA_ARGS__ )
#define TCODEx_3( a, ... ) TYPE_CODE_1( a ), TCODE_2x( __VA_ARGS__ )
#define TCODEx_2( a, ... ) TYPE_CODE_1( a ), TCODE_1x( __VA_ARGS__ )
#define TCODEx_1( a, ... ) TYPE_CODE_1( a )
We are now very close to being done. The TYPE_CODES() macro can
be defined to produce a compound literal:
#define TYPE_CODES( ... ) (int){ TCODEx( ... ) }
Somehow we need to get the TCODEx() macro to invoke the right one
of the TCODEx_{N} macros. To do that, we use the HOW_MANY() macro
and preprocessor concatenation:
#define TCODEx( ... ) \
JOIN_TWO( TCODEx_, HOW_MANY( __VA_ARGS__ ) ) ( __VA_ARGS__, XXX )
#define JOIN_TWO( a, b ) JOIN_TWO_x( a, b )
#define JOIN_TWO_x( a, b ) a ## b
The JOIN_TWO() macro uses the trick of an extra level of macro
call to get the expansion of HOW_MANY() to work. The extra
argument XXX in the call to a TCODEx_{N} macro is there so the
variadic parameter always has at least one argument (and the
extra argument is ignored at the bottom of the call chain).
Try putting all this together and making it work for between one
and nine arguments. If you can do that, extend it so it works
with up to 63 arguments (the C preprocessor must accept at least
127), which should be straightforward, if a bit tedious. After
that, if you're feeling brave, try extending it so it works with
just a format string and no additional arguments.
I've tried to cover all the tricky point you'll need, but if
anything is still confusing please ask.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2019-10-16 18:17 +0300 |
| Message-ID | <20191016181735.50831f7a43e770182ac09123@g{oogle}mail.com> |
| In reply to | #147009 |
Tim Rentsch to Anton Shepelev: >>I found the C preprocessor so hard that I failed to write >>even a simple macro for the generation of function names >>with a custom prefix, e.g. MY_Func1, MY_Func2 vs. >>HIS_Func1 and HIS_Func2, where MY and HIS may be >>#define'd. I became stuck at macro concatenation and >>stringizing via # and ##. Maybe I should have tried >>harder. > >The C preprocessor is tricky. Thank you for the post, Tim. This is a quick note that I have actually made it, as I wrote earler: >I grew ashemed and wrote this yestertday. I meant I had written a solution to my problem. GCC online documentaiton turned out quite useful in the part about the preprocessor. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-17 05:43 -0700 |
| Message-ID | <86y2xj4k65.fsf@linuxsc.com> |
| In reply to | #147010 |
Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> Tim Rentsch to Anton Shepelev:
>
>>> I found the C preprocessor so hard that I failed to write
>>> even a simple macro for the generation of function names
>>> with a custom prefix, e.g. MY_Func1, MY_Func2 vs.
>>> HIS_Func1 and HIS_Func2, where MY and HIS may be
>>> #define'd. I became stuck at macro concatenation and
>>> stringizing via # and ##. Maybe I should have tried
>>> harder.
>>
>> The C preprocessor is tricky.
>
> Thank you for the post, Tim. This is a quick note that I
> have actually made it, as I wrote earler:
>
>> I grew ashemed and wrote this yestertday.
>
> I meant I had written a solution to my problem. GCC online
> documentaiton turned out quite useful in the part about the
> preprocessor.
Ahh I see. Excellent.
Since you have now learned how to solve the problem, and have
actually written a solution, do you have any comments or
feedback for me on my explanations?
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2019-10-17 18:01 +0300 |
| Message-ID | <20191017180132.3f8a4cc4a850f097e024220c@g{oogle}mail.com> |
| In reply to | #147015 |
Tim Rentsch: >Since you have now learned how to solve the problem, and >have actually written a solution, do you have any comments >or feedback for me on my explanations? I have been in a hurry and have not even read your comments about the typed printf. I will do that and then ask questions. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-19 00:39 +0300 |
| Message-ID | <20191019003905.826b918468a4ab42279e0ea4@gmail.com> |
| In reply to | #147009 |
Tim Rentsch: > [brick text preserved!] > The C preprocessor is tricky. I don't think I would have figured > out the patterns needed to make this stuff work if I had tried to > deduce them from first principles. Fortunately there are lots of > smart people out there who can figure them out and sometimes they > post about them. Looking at your specific case, what I think you > mean is definitions something like this: > > #define DECLARE_FUNCTIONS_1(who) int who ## _f1(), who ## _f2() > > #define MY fred > #define HIS barney > > DECLARE_FUNCTIONS_1( MY ); > DECLARE_FUNCTIONS_1( HIS ); What I meant is the ability to specify a single common prefix for all the funcions in a library in order to avoid potential name collision and keep the names short and comfortable. If no collisions are predicted, an empty prefix will do. > Unfortunately this doesn't do what we want. Expanding these > lines with gcc -std=c99 -pedantic -E gives > > int MY_f1(), MY_f2(); > int HIS_f1(), HIS_f2(); > > so the macro arguments have not been expanded. This result > occurs because of how the ## operator is defined. The trick is > to invoke another level of macro call, to give the arguments a > chance to expand: > > #define DECLARE_FUNCTIONS_2(who) DECLARE_FUNCTIONS_1(who) > > DECLARE_FUNCTIONS_2( MY ); > DECLARE_FUNCTIONS_2( HIS ); Thank you for the example. The solution I wrote applies to a single function: #define PREF MyPrefix_ /* a global setting */ #define FID( F ) FID1(PREF, F) #define FID1(P,F) FID2( P, F) #define FID2(P,F) P ## F > Try tracing through what happens during macro processing, using > the descriptions in the C standard for how expansion works, and > see if it makes sense what is going on and why. After reading about that in the standard, I still do not understand why my solution requires both FID1 and FID2 to expand PREF. As far as I have understood the starndard, PREF should be expanded during the rescan stage of FID expansion, but it is not. Why? P.S.: I pospone the harder tprintf problem to a later time. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-19 06:00 -0700 |
| Message-ID | <86v9skhotz.fsf@linuxsc.com> |
| In reply to | #147048 |
Anton Shepelev <anton.txt@gmail.com> writes:
> [..getting a macro argument to expand before token pasting..]
>
> The solution I wrote applies to a single function:
>
> #define PREF MyPrefix_ /* a global setting */
>
> #define FID( F ) FID1(PREF, F)
> #define FID1(P,F) FID2( P, F)
> #define FID2(P,F) P ## F
>
>> [I wrote:]
>> Try tracing through what happens during macro processing, using
>> the descriptions in the C standard for how expansion works, and
>> see if it makes sense what is going on and why.
>
> After reading about that in the standard, I still do not
> understand why my solution requires both FID1 and FID2 to
> expand PREF. As far as I have understood the starndard,
> PREF should be expanded during the rescan stage of FID
> expansion, but it is not. Why?
We start with a call to the FID() macro:
^ FID( some_name ) ...
The ^ indicates the scan arrow, the ... indicates the rest of the
file. Assuming the argument 'some_name' is already fully
expanded, the first level of expansion gives this:
^ FID1( PREF, some_name ) ...
(I have added some extra white space, but that doesn't change
anything important.)
In expanding this macro call, the argument PREF is expanded
before being substituted for P in the definition 'FID2( P, F )',
so we get
^ FID2( MyPrefix_, some_name ) ...
which upon one expansion gives
^ MyPrefix_some_name ...
at which point, assuming 'MyPrefix_some_name' is not defined as a
macro, leads to
MyPrefix_some_name ^ ...
which is what we want.
Now suppose the FID() macro had used FID2() rather than FID1().
Then the first level of expanding FID( some_name ) gives this:
^ FID2( PREF, some_name ) ...
At this point we need to replace a call to FID2(), which is
defined as
#define FID2(P,F) P ## F
The first argument, PREF, is substituted for P in the definition.
But how is it substituted? The specification for that is given in
section 6.10.3.1. Paragraph 1 of that section starts
After the arguments for the invocation of a function-like
macro have been identified, argument substitution takes place.
A parameter in the replacement list, unless preceded by a # or
## preprocessing token or followed by a ## preprocessing token
(see below), is replaced by the corresponding argument after
all macros contained therein have been expanded.
Note the key second sentence: a macro parameter is replaced by
the expanded argument "unless preceded by a # or ## preprocessing
token or followed by a ## preprocessing token". In the definition
of FID2, the (single occurrence of the) parameter P is followed by
a ## operator. Therefore the first argument to the call of FID2()
is _not_ expanded but substituted as is. Therefore the call
to FID2() gives
^ PREFsome_name ...
but PREF has now been pasted onto some_name, so it doesn't expand
as the token PREF would.
We can test this theory by defining PREFsome_name:
#define PREFsome_name HOLY_SMOKES
#define PREF MYPrefix_
#define FID( F ) FID2(PREF, F)
#define FID2(P,F) P ## F
FID( some_name )
Running this example through gcc -E does indeed expand the call of
PREFsome_name to its definition, HOLY_SMOKES. Give it a try.
Does this explanation help you see what is going on and why?
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2019-11-08 18:38 +0300 |
| Message-ID | <20191108183821.6f16f39f6a377a873006fa01@g{oogle}mail.com> |
| In reply to | #147073 |
Tim Rentsch to Anton Shepelev:
> > #define FID( F ) FID1(PREF, F)
> > #define FID1(P,F) FID2( P, F)
> > #define FID2(P,F) P ## F
> >
> > After reading about that in the standard, I still do not
> > understand why my solution requires both FID1 and FID2
> > to expand PREF. As far as I have understood the
> > starndard, PREF should be expanded during the rescan
> > stage of FID expansion, but it is not. Why?
>
> We start with a call to the FID() macro:
>
> ^ FID( some_name ) ...
>
> The ^ indicates the scan arrow, the ... indicates the rest
> of the file. Assuming the argument 'some_name' is already
> fully expanded, the first level of expansion gives this:
>
> ^ FID1( PREF, some_name ) ...
>
> In expanding this macro call, the argument PREF is
> expanded before being substituted for P in the definition
> 'FID2( P, F )',
I fear it contradicts 6.10.3.1, which you quote below. The
paragraph says that expansion of the arguments takes place
*after* substution of them into the macro body (aka
replacement list). That said, PREF is first subsituted into
the defintion and then expanded:
FID2( PREF, some_name )
FID2( MyPrefix_, some_name )
Right?
> so we get
>
> ^ FID2( MyPrefix_, some_name ) ...
>
> which upon one expansion gives
>
> ^ MyPrefix_some_name ...
>
> at which point, assuming 'MyPrefix_some_name' is not
> defined as a macro, leads to
>
> MyPrefix_some_name ^ ...
>
> which is what we want.
Ok.
> Now suppose the FID() macro had used FID2() rather than
> FID1(). Then the first level of expanding
> FID( some_name ) gives this:
>
> ^ FID2( PREF, some_name ) ...
I think PREF is not expanded here because it is not a
argument to FID() and therefore not subject to 6.10.3.1.
> At this point we need to replace a call to FID2(), which
> is defined as
>
> #define FID2(P,F) P ## F
>
> The first argument, PREF, is substituted for P in the
> definition. But how is it substituted? The specification
> for that is given in section 6.10.3.1. Paragraph 1 of
> that section starts
>
> After the arguments for the invocation of a function-
> like macro have been identified, argument substitution
> takes place. A parameter in the replacement list,
> unless preceded by a # or ## preprocessing token or
> followed by a ## preprocessing token (see below), is
> replaced by the corresponding argument after all macros
> contained therein have been expanded.
I see: the preprocessor identifies the argument PREF but
does not expand it. Thanks!
> We can test this theory by defining PREFsome_name:
>
> #define PREFsome_name HOLY_SMOKES
> #define PREF MYPrefix_
>
> #define FID( F ) FID2(PREF, F)
> #define FID2(P,F) P ## F
>
> FID( some_name )
My understaning:
1. FID( some_name )
2. FID2( PREF, some_name )
(PREF not expanded because not an argument to FID)
3. PREF ## somename
4. PREFsome_name
(PREF and some_name not expanded becase of ##)
5. HOLY_SMOKES
Do you agree?
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-11-08 22:03 -0800 |
| Message-ID | <8636exegc8.fsf@linuxsc.com> |
| In reply to | #147776 |
Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> Tim Rentsch to Anton Shepelev:
>
>>> #define FID( F ) FID1(PREF, F)
>>> #define FID1(P,F) FID2( P, F)
>>> #define FID2(P,F) P ## F
>>>
>>> After reading about that in the standard, I still do not
>>> understand why my solution requires both FID1 and FID2
>>> to expand PREF. As far as I have understood the
>>> starndard, PREF should be expanded during the rescan
>>> stage of FID expansion, but it is not. Why?
>>
>> We start with a call to the FID() macro:
>>
>> ^ FID( some_name ) ...
>>
>> The ^ indicates the scan arrow, the ... indicates the rest
>> of the file. Assuming the argument 'some_name' is already
>> fully expanded, the first level of expansion gives this:
>>
>> ^ FID1( PREF, some_name ) ...
>>
>> In expanding this macro call, the argument PREF is
>> expanded before being substituted for P in the definition
>> 'FID2( P, F )',
>
> I fear it contradicts 6.10.3.1, which you quote below. The
> paragraph says that expansion of the arguments takes place
> *after* substution of them into the macro body (aka
> replacement list). That said, PREF is first subsituted into
> the defintion and then expanded:
>
> FID2( PREF, some_name )
> FID2( MyPrefix_, some_name )
>
> Right?
I think you are misreading what the paragraph says. First here
is the whole paragraph of 6.10.3.1 p1, completely verbatim:
After the arguments for the invocation of a function-like
macro have been identified, argument substitution takes
place. A parameter in the replacement list, unless preceded
by a # or ## preprocessing token or followed by a ##
preprocessing token (see below), is replaced by the
corresponding argument after all macros contained therein
have been expanded. Before being substituted, each
argument's preprocessing tokens are completely macro
replaced as if they formed the rest of the preprocessing
file; no other preprocessing tokens are available.
Here is a summary, with my emphasis:
[...] A parameter in the replacement list, unless [some
cases that don't apply here], is replaced by the
corresponding argument AFTER ALL MACROS CONTAINED THEREIN
HAVE BEEN EXPANDED. BEFORE BEING SUBSTITUTED, each
argument's preprocessing tokens ARE COMPLETELY MACRO
REPLACED as if they formed the rest of the preprocessing
file; no other preprocessing tokens are available.
Parameter replacement by its argument happens AFTER that argument
has been macro expanded. The second sentence emphasizes this:
each argument's preprocessing tokens are completely macro
replaced BEFORE being substituted for the parameter.
Expansion of the argument happens first; substituting the
expanded argument for (each occurrence of) the corresponding
parameter happens second.
Maybe what's confusing you is that there are /two/ substitutions.
First (expanded) arguments are substituted for parameters in the
definition. Second the resulting sequence of tokens is substituted
back in place of the original (and now deleted) macro call. The
sequence of actions is
one: expand arguments
two: substitute arguments for parameters
three: do any stringizing or token pasting needed
four: substitute the resulting token sequence in place of the
original macro call
five: continue scanning with the token sequence just substituted
>> so we get
>>
>> ^ FID2( MyPrefix_, some_name ) ...
>>
>> which upon one expansion gives
>>
>> ^ MyPrefix_some_name ...
>>
>> at which point, assuming 'MyPrefix_some_name' is not
>> defined as a macro, leads to
>>
>> MyPrefix_some_name ^ ...
>>
>> which is what we want.
>
> Ok.
>
>> Now suppose the FID() macro had used FID2() rather than
>> FID1(). Then the first level of expanding
>> FID( some_name ) gives this:
>>
>> ^ FID2( PREF, some_name ) ...
>
> I think PREF is not expanded here because it is not a
> argument to FID() and therefore not subject to 6.10.3.1.
I don't know why you think that. The call to FID() has been
processed, leaving the expansion text 'FID2( PREF, some_name )'
to be rescanned. The first argument to the FID2() call is the
token PREF; that argument is treated as a macro argument under
the rules of 6.10.3.1 p1. The expansion of FID has been
substituted and is in the process of being rescanned. There is
a macro call to FID2 in the subsituted expansion, and it is
treated just the same as though the macro call were occurring
at the top level.
(I feel obliged to point out that there is an exception to what
I said in the last sentence, but it has no bearing on what we
are talking about in this discussion.)
In this case the argument PREF is not expanded before being
subsituted for the parameter P because P is immediately followed
by a ## operator. A parameter being followed by a ## operator
prevents the expansion of its argument /for that occurrence of
the parameter/. An easy way to see what's going on is this:
#define FOO BAS
#define AB(X) { X, #X }
AB(FOO)
Running this through gcc -E gives
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "<stdin>"
{ BAS, "FOO" }
The argument FOO is expanded for the _first_ occurrence of X,
because it has no # in front of it, but is /not/ expanded
for the _second_ occurrence of X, because that occurrence of the
parameter X /does/ have a # in front of it. The situation with
the ## token-pasting operator is similar.
>> At this point we need to replace a call to FID2(), which
>> is defined as
>>
>> #define FID2(P,F) P ## F
>>
>> The first argument, PREF, is substituted for P in the
>> definition. But how is it substituted? The specification
>> for that is given in section 6.10.3.1. Paragraph 1 of
>> that section starts
>>
>> After the arguments for the invocation of a function-
>> like macro have been identified, argument substitution
>> takes place. A parameter in the replacement list,
>> unless preceded by a # or ## preprocessing token or
>> followed by a ## preprocessing token (see below), is
>> replaced by the corresponding argument after all macros
>> contained therein have been expanded.
>
> I see: the preprocessor identifies the argument PREF but
> does not expand it. Thanks!
>
>> We can test this theory by defining PREFsome_name:
>>
>> #define PREFsome_name HOLY_SMOKES
>> #define PREF MYPrefix_
>>
>> #define FID( F ) FID2(PREF, F)
>> #define FID2(P,F) P ## F
>>
>> FID( some_name )
>
> My understaning:
>
> 1. FID( some_name )
> 2. FID2( PREF, some_name )
> (PREF not expanded because not an argument to FID)
> 3. PREF ## somename
> 4. PREFsome_name
> (PREF and some_name not expanded becase of ##)
> 5. HOLY_SMOKES
>
> Do you agree?
No, I disagree on item 2. The call to FID2 is right, but the
argument PREF is not expanded because of how FID2 is defined.
In particular, the only occurrence of the parameter P in the
definition of FID2 is immediately followed by a ## operator,
which prevents expanding the argument.
Also, what you say in item 4 is not quite right. It is true that
PREF and some_name aren't expanded before being token-pasted, but
there is no opportunity for them to /be/ expanded. The definition
of FID2 is
#define FID2(P,F) P ## F
so when the call FID2( PREF, some_name ) is seen, we first get an
expanded macro body
PREF ## some_name
which token pastes to
PREFsome_name
but this happens /before/ the resulting sequence of tokens is
substituted back in place of the call to FID2. It is only
/after/ that substitution occurs that the generated text is
re-scanned looking for further macro calls.
To say this another way, there is never an opportunity for the
sequence
PREF ## some_name
to be macro-expanded before the token pasting to
PREFsome_name
occurs.
Does this all make sense? I know it can be confusing.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-10-12 18:49 -0400 |
| Message-ID | <bMsoF.106202$hL1.44684@fx35.iad> |
| In reply to | #146894 |
On 10/12/19 10:29 AM, Bart wrote: > It's not even about new types, but the same type. The generic int32 type > can be represented in most desktop Cs as: > > int, long (sometimes) long long (possible?) int32_t > OK, this shows part of your disagreement with C. To C, you don't have the concept of a generic type for a given representation, but defines a couple generic integer types that adapt to the various machines that other types are matched to. You get the types char/signed char/unsigned character for characters and very small numbers short/unsigned short for 'small numbers' with a need to save space int/unsigned int for normal sized numbers long/unsigned long for bigger numbers long long/unsigned long long for very big numbers The problem with 'representation types' as your core is that they are inherently non-portable, as they may not efficiently exist on some machines (admittedly, this was more of an issue in the early days.) C chose to base its types on the above generic properties, and then let the programmer match then to the types they needed. You also show your lack of knowledge of C, as long long can NEVER have a 32 bit representation, as it must have at least 64 bits.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-13 00:25 +0100 |
| Message-ID | <6itoF.970941$Ro6.104888@fx38.am4> |
| In reply to | #146902 |
On 12/10/2019 23:49, Richard Damon wrote: > On 10/12/19 10:29 AM, Bart wrote: >> It's not even about new types, but the same type. The generic int32 type >> can be represented in most desktop Cs as: >> >> int, long (sometimes) long long (possible?) int32_t >> > > OK, this shows part of your disagreement with C. > > To C, you don't have the concept of a generic type for a given > representation, but defines a couple generic integer types that adapt to > the various machines that other types are matched to. > > You get the types char/signed char/unsigned character for characters and > very small numbers How small? I want to store numbers 0 to 999; an 8-bit char is too small, but should I think about the possibility of 'char' being 10 or 12 bits? Or is that pointless because char will almost certainly never be 10 or 12 bits unless it's the same width as 'short'? > short/unsigned short for 'small numbers' with a need to save space How much space? How will you know if the number will be big enough? > int/unsigned int for normal sized numbers Normal in what way, that you don't care about the range? A typical 32-bit int is not going to be big enough for file and disk sizes, for very large array bounds and indexing, to contain a 64-bit pointer value, for machine memory sizes, for the number of people on Earth, to contain the pattern of a 'double' value ... So you have to think twice about whether to use 'int' as a 'don't care' type. Especially if you have to consider that 'int' might also be 16 bits. (How many programs would fail when moved to such a machine; so much for portability. I also experimentally made 'int' 64 bits on my compiler; programs failed then too, although my tests were superficial.) > long/unsigned long for bigger numbers Long is a problem, as it is 32 bits on Win32, Win64 and Linux32, but 64 bits on Linux64. So someone using 'long' extensively (eg. see ScriptBasic sources), who doesn't need 64 bits, will find that on Linux64, it will take up unnecessary space, and take longer to calculate with. While if someone is using 'long' on Linux64, then when their program runs on anything else, it may not be sufficiently wide. > long long/unsigned long long for very big numbers > > The problem with 'representation types' as your core is that they are > inherently non-portable, as they may not efficiently exist on some > machines (admittedly, this was more of an issue in the early days.) C > chose to base its types on the above generic properties, and then let > the programmer match then to the types they needed. Unless someone specifically wants to use C on niche hardware, then they will have a choice of C, Java, C#, D, Rust etc, where the sizes of the basic types are fixed. That is much easier to work with; you just KNOW without any messing or speculation, whether a particular range of values will fit, including on any machine running that language. > You also show your lack of knowledge of C, as long long can NEVER have a > 32 bit representation, as it must have at least 64 bits. I put a question mark next to it, as I couldn't be bothered to go and look up the specs for C types. And THAT is part of the problem with types that don't have solid specifications. And, BTW, why are these lower bounds 8, 16, 32 and 64 bits, all powers of two? I thought C didn't get involved with real hardware. Why aren't they 6, 12, 24 and 48?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-10-12 23:44 -0400 |
| Message-ID | <j4xoF.67513$pe2.50142@fx34.iad> |
| In reply to | #146904 |
On 10/12/19 7:25 PM, Bart wrote: > On 12/10/2019 23:49, Richard Damon wrote: >> On 10/12/19 10:29 AM, Bart wrote: >>> It's not even about new types, but the same type. The generic int32 type >>> can be represented in most desktop Cs as: >>> >>> int, long (sometimes) long long (possible?) int32_t >>> >> >> OK, this shows part of your disagreement with C. >> >> To C, you don't have the concept of a generic type for a given >> representation, but defines a couple generic integer types that adapt to >> the various machines that other types are matched to. >> >> You get the types char/signed char/unsigned character for characters and >> very small numbers > > How small? I want to store numbers 0 to 999; an 8-bit char is too small, > but should I think about the possibility of 'char' being 10 or 12 bits? > Or is that pointless because char will almost certainly never be 10 or > 12 bits unless it's the same width as 'short'? signed char is defined to span at least -127 to 127, so if your numbers are that small you can use char. A number as big as 999 would need a short to be > >> short/unsigned short for 'small numbers' with a need to save space > > How much space? How will you know if the number will be big enough? > short is defined to handle at least -32767 to 32767, so you can use it if that is big enough. >> int/unsigned int for normal sized numbers > > Normal in what way, that you don't care about the range? > > A typical 32-bit int is not going to be big enough for file and disk > sizes, for very large array bounds and indexing, to contain a 64-bit > pointer value, for machine memory sizes, for the number of people on > Earth, to contain the pattern of a 'double' value ... 32 bit long was good enough for file access for quite a while, and on machines big enough to have file system bigger than that, it wouldn't have been unreasonable for long to migrate to being a 64 bit type. An int is almost always big enough to use as an index in an array (if you want to be sure, you can use size_t). Machines with 16 bit ints, tend not to support big arrays. > > So you have to think twice about whether to use 'int' as a 'don't care' > type. Especially if you have to consider that 'int' might also be 16 bits. > > (How many programs would fail when moved to such a machine; so much for > portability. I also experimentally made 'int' 64 bits on my compiler; > programs failed then too, although my tests were superficial.) Yes, you have to THINK about your use cases. If you have a know range of values, like the population of the world, you need to choose a size which is promised to be big enough. > >> long/unsigned long for bigger numbers > > Long is a problem, as it is 32 bits on Win32, Win64 and Linux32, but 64 > bits on Linux64. > > So someone using 'long' extensively (eg. see ScriptBasic sources), who > doesn't need 64 bits, will find that on Linux64, it will take up > unnecessary space, and take longer to calculate with. > > While if someone is using 'long' on Linux64, then when their program > runs on anything else, it may not be sufficiently wide. > If you use specifially needs something at least 32 bits wide, then the type is int_least32_t (or int_fast32_t), this is the sort of situation that those types were created for. My real guess is that if the application needed 32 bits on smaller machines to process the data there, then on bigger machines, you may at times want a bigger type. One reason Linux64 went to 64 bit longs was that a number of things that were defined as longs years ago were approaching the point that the limit was getting hit, so making long bigger solved a lot of issues. Windows didn't, in a large part, because too many of their programmers had baked in the assumption that long was 32 bits into their code. > >> long long/unsigned long long for very big numbers >> >> The problem with 'representation types' as your core is that they are >> inherently non-portable, as they may not efficiently exist on some >> machines (admittedly, this was more of an issue in the early days.) C >> chose to base its types on the above generic properties, and then let >> the programmer match then to the types they needed. > > Unless someone specifically wants to use C on niche hardware, then they > will have a choice of C, Java, C#, D, Rust etc, where the sizes of the > basic types are fixed. > > That is much easier to work with; you just KNOW without any messing or > speculation, whether a particular range of values will fit, including on > any machine running that language. > > Yes, and you can tell roughly when the langage was designed by the choices they made, and don't try running it on a machine smaller than that. For instance, since Java makes Integer be 32 bits big, Java programs run very slowly (if at all) on a 16 bit processor. THe languages also get crufty when when machine progress significantly beyond where the language was defined. >> You also show your lack of knowledge of C, as long long can NEVER have a >> 32 bit representation, as it must have at least 64 bits. > > I put a question mark next to it, as I couldn't be bothered to go and > look up the specs for C types. And THAT is part of the problem with > types that don't have solid specifications. That is YOUR problem, they DO have a very definite definition as to MINIMUM ranges. > > And, BTW, why are these lower bounds 8, 16, 32 and 64 bits, all powers > of two? I thought C didn't get involved with real hardware. Why aren't > they 6, 12, 24 and 48? > I don't know exactly why they chose it, but my guess is that in working on the initial version of the language, they didn't see a need to handle the antiquated machines that could only handle 6 bit (or smaller) character sets. ASCII, while a 7 bit character set, virtually always had an 8 bit byte for storage, so the smallest size for a char was 8 bits on any acceptable hardware, but it might be bigger. Once you are built on 8 bit or bigger bytes, then the larger sizes fall out from practical existing hardware. The language definition DID very much look at what hardware was available, and specifically gave freedom when hardware varied, as opposed to the other languages you mentioned which essentially said if your machine doesn't tightly match the specifications of the language, you can't compile for that machine or maybe it executes horribly slow. What C doesn't do is tie you program to specific hardware, unless you decide to use implementation dependent properties yourself. C is a very powerful tool, but one that requires a user to use due care. Maybe a bit like a chain saw. Used properly it is a very powerful tool that can do a lot. Don't be careful and it can cut you up badly. It isn't a fancy machine that takes a lot of the work away from you like some of the higher level languages, but by not being that, it gives you a lot of control.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-12 13:45 +0100 |
| Message-ID | <87zhi63zej.fsf@bsb.me.uk> |
| In reply to | #146883 |
Bart <bc@freeuk.com> writes: > On 12/10/2019 00:26, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> >>> 40 integer types (I counted exactly 40 plus those below), for the 8 >>> common hardware types, with varying degrees of compatibility. >> >> No, no, no. Numbers alone don't make an argument. > > How many types does it need then for /you/ to consider such a language > a joke? I was quite clear: the numbers are not the issue. If the types are introduced for significant and serious reasons, the result won't ever be "a joke" in my opinion. > If there were 10 times as many, the language designers can't be > serious, right? All I can say is that I can't see a serious reason to have 400 integer types so that seems likely. >> When people say that >> something is a joke they mean it is not to be taken seriously -- that >> it's frivolous or silly. You would need to show that the emergence of >> all these types are not the result of a very serious, and successful, >> endeavour indeed -- to keep C as one of the most widely used programming >> languages ever. > > It has certainly got itself ensconced. Then you look deep into the > innards of C system headers and it makes you want to cry. This ghastly > mess underpins much of the world's computer systems; seriously? It is > actually somewhat worrying. You might be surprised to hear that I agree with you. I am not sure that the legacy of C is, overall, a good one. (I am not the sort of person that makes strong claims about things I have not studied, so that's as strong a condemnation as I am prepared to make). However, the number of integer types in C does not even twitch the dial on my personal measure of things about C that might have had a negative effect. >>>> If you meant that you were supporting his overall argument (that it's >>>> ridiculous for C to have so many integer types when the hardware >>>> doesn't) you offered no support for that either. >>> >>> It's just common sense. >> >> Ah. Am I allowed to say that of my point of view? If so, consider it said. > > So what technical proof is necessary to consider that a language's > treatment of types is over the top, or messy or unwieldy? Ah, a change in claim: "messy" != "a joke". Am I allowed to to that too? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-10-13 19:05 -0400 |
| Message-ID | <qo0akd$j5m$1@dont-email.me> |
| In reply to | #146891 |
On 10/12/19 8:45 AM, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: ... >> How many types does it need then for /you/ to consider such a language >> a joke? > > I was quite clear: the numbers are not the issue. If the types are > introduced for significant and serious reasons, the result won't ever be > "a joke" in my opinion. > >> If there were 10 times as many, the language designers can't be >> serious, right? > > All I can say is that I can't see a serious reason to have 400 integer > types so that seems likely. To clarify: you consider it extremely unlikely to have "signficant and serious reasons" for supporting 400 different types, but if such reasons did in fact exist, supporting those types would not make the language that did so a "joke".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-12 13:16 -0700 |
| Message-ID | <05020370-4edc-457f-a038-f51efbb47cdf@googlegroups.com> |
| In reply to | #146882 |
On Saturday, 12 October 2019 00:27:09 UTC+1, Ben Bacarisse wrote: > > No, no, no. Numbers alone don't make an argument. When people say that > something is a joke they mean it is not to be taken seriously -- that > it's frivolous or silly. > It can be meant literally. "Piltdown man was a joke". Or it can be meant that something is presented as a serious proposal but is inherently flawed in some way which should be obvious to any observer but isn't obvious to to proposer. > > You would need to show that the emergence of > all these types are not the result of a very serious, and successful, > endeavour indeed -- to keep C as one of the most widely used programming > languages ever. > Something can be a side effect of a process which is broadly serious and indeed successful. There's a justification for each new type, and a counter-argument for rejecting it. In each case, the counter- argument has been either rejected for forgotten. It's the "red tape" effect - every regulation you introduce has an obvious benefit, and a non-obvious compliance cost. Eventually you introduce so many regulations that the compliance costs reach a threshold - they can no longer be simply absorbed and they start affecting business decisions. The basic argument against a new type for a general purpose integer (I'm not talking about types for integers like bar code numbers in a high level language) is that you create a N x N table of conversion possibilities. The higher N gets, the more confusing the mass of conversions in code written without some discipline to reduce the number of types used. When the code is written by different people working for different organisations on different libraries, it is impossible to impose that discipline.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-13 00:12 +0100 |
| Message-ID | <87tv8d4kys.fsf@bsb.me.uk> |
| In reply to | #146901 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Saturday, 12 October 2019 00:27:09 UTC+1, Ben Bacarisse wrote: >> >> No, no, no. Numbers alone don't make an argument. When people say that >> something is a joke they mean it is not to be taken seriously -- that >> it's frivolous or silly. >> > It can be meant literally. "Piltdown man was a joke". Obviously a joke can just be a joke, but that's not what you meant. > Or it can be > meant that something is presented as a serious proposal but is > inherently flawed in some way which should be obvious to any observer > but isn't obvious to to proposer. So you mean, very specifically, an "in joke" -- one amongst everyone but the various proposers of C's types. If this is what you meant, you don't present the right kind of evidence for it. My guess (and here I can't support it with evidence other than my own experience) is that everyone who knows C's integer type system is aware that it is inherently flawed. We can, it seems, ignore subtle or complex flaws. It's only the ones that should be obvious to any (though presumably informed) observer that contribute to C's integer types being a joke. Why do you think the various proposers were not aware of flaws that "should be obvious to any observer"? > The basic argument against a new type for a general purpose integer > (I'm not talking about types for integers like bar code numbers in > a high level language) is that you create a N x N table of conversion > possibilities. The higher N gets, the more confusing the mass of > conversions in code written without some discipline to reduce the > number of types used. When the code is written by different people > working for different organisations on different libraries, it > is impossible to impose that discipline. This is an argument that there /is/ a flaw. I think it is both well-known and almost universally accepted. Which "proposers" do you think are unaware of this flaw? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-13 14:18 -0700 |
| Message-ID | <fb1ac1a3-8110-4d0a-8e4c-9e762c701be6@googlegroups.com> |
| In reply to | #146903 |
On Sunday, 13 October 2019 00:12:44 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > This is an argument that there /is/ a flaw. I think it is both > well-known and almost universally accepted. Which "proposers" do you > think are unaware of this flaw? > Someone agreed to create a language with forty general-purpose integer types, as standard. I don't know who supported and who resisted this, but clearly there were enough supporters to get their way.
[toc] | [prev] | [next] | [standalone]
Page 14 of 25 — ← Prev page 1 … 12 13 [14] 15 16 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web