Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #148634 > unrolled thread
| Started by | T <T@invalid.invalid> |
|---|---|
| First post | 2019-12-31 20:08 -0800 |
| Last post | 2020-01-21 16:44 +0100 |
| Articles | 20 on this page of 202 — 21 participants |
Back to article view | Back to comp.lang.c
Do "C" arrays start a 0 or 1? T <T@invalid.invalid> - 2019-12-31 20:08 -0800
Re: Do "C" arrays start a 0 or 1? Paul <nospam@needed.invalid> - 2019-12-31 23:50 -0500
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-01 03:28 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-01 03:49 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 13:26 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-01 04:34 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 13:56 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-01 05:04 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 14:18 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-01 13:21 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 14:26 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-01 13:19 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 14:24 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-01 14:56 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 16:06 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-01 15:44 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 16:54 +0100
Re: Do "C" arrays start a 0 or 1? chad <cdalten@gmail.com> - 2020-01-01 08:07 -0800
Re: Do "C" arrays start a 0 or 1? Dan Purgert <dan@djph.net> - 2020-01-01 14:19 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 15:28 +0100
Re: Do "C" arrays start a 0 or 1? Dan Purgert <dan@djph.net> - 2020-01-02 11:06 +0000
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-02 10:19 +0100
Re: Do "C" arrays start a 0 or 1? gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-02 13:33 +0000
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-02 13:55 +0000
Raku (Was: Do "C" arrays start a 0 or 1?) gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-02 14:48 +0000
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-02 15:03 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-02 06:18 -0800
Re: Do "C" arrays start a 0 or 1? m.nasim85@gmail.com - 2020-01-02 01:26 -0800
Re: Do "C" arrays start a 0 or 1? F Russell <fr@random.info> - 2020-01-05 19:32 +0000
Re: Do "C" arrays start a 0 or 1? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-05 12:25 -0800
Re: Do "C" arrays start a 0 or 1? F Russell <fr@random.info> - 2020-01-07 00:33 +0000
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 01:11 +0000
Re: Do "C" arrays start a 0 or 1? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-06 22:32 -0800
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 10:08 +0000
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 06:24 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 06:30 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 06:42 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 12:47 -0800
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 21:20 +0000
Re: Do "C" arrays start a 0 or 1? gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-07 21:53 +0000
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 14:01 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 14:22 -0800
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 22:31 +0000
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-08 00:27 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-08 08:13 -0800
Re: Do "C" arrays start a 0 or 1? chad <cdalten@gmail.com> - 2020-01-07 06:33 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 06:38 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 06:49 -0800
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 16:38 +0000
Re: Do "C" arrays start a 0 or 1? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-07 10:31 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 10:44 -0800
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-07 19:54 +0100
Re: Do "C" arrays start a 0 or 1? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 10:24 -0800
Re: Do "C" arrays start a 0 or 1? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-11 14:23 -0800
Re: Do "C" arrays start a 0 or 1? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 04:21 -0800
Re: Do "C" arrays start a 0 or 1? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-21 05:06 -0800
Re: Do "C" arrays start a 0 or 1? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 07:58 -0800
Re: Do "C" arrays start a 0 or 1? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-22 09:01 -0800
Re: Do "C" arrays start a 0 or 1? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-27 19:52 -0700
Re: Do "C" arrays start a 0 or 1? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-22 11:29 -0800
Re: Do "C" arrays start a 0 or 1? luser droog <luser.droog@gmail.com> - 2020-02-22 19:02 -0800
Re: Do "C" arrays start a 0 or 1? luser droog <luser.droog@gmail.com> - 2020-02-22 19:16 -0800
Re: Do "C" arrays start a 0 or 1? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-27 19:54 -0700
Re: Do "C" arrays start a 0 or 1? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-27 20:19 -0700
Re: Do "C" arrays start a 0 or 1? gazelle@shell.xmission.com (Kenny McCormack) - 2020-03-28 05:39 +0000
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 10:59 -0800
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 19:21 +0000
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 11:36 -0800
Re: Do "C" arrays start a 0 or 1? Barry Schwarz <schwarzb@delq.com> - 2020-01-06 18:02 -0800
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-07 10:55 +0100
Re: Do "C" arrays start a 0 or 1? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-06 23:34 -0500
Re: Do "C" arrays start a 0 or 1? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-06 22:30 -0800
Re: Do "C" arrays start a 0 or 1? Richard Damon <Richard@Damon-Family.org> - 2020-01-05 16:30 -0500
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-06 02:07 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-06 07:57 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 08:03 +0100
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 08:11 +0100
Re: Do "C" arrays start a 0 or 1? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-07 10:09 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 11:12 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 11:09 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 13:45 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 13:06 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 14:14 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 16:27 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 17:53 +0100
Re: Do "C" arrays start a 0 or 1? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-07 08:55 -0800
Re: Do "C" arrays start a 0 or 1? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-07 05:19 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-11 19:11 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-11 19:09 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-11 20:18 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-11 20:00 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 07:02 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 00:32 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 09:38 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 01:09 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 10:48 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 01:57 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 11:02 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 02:09 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 12:45 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 03:54 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 13:13 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 04:35 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 13:38 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 04:44 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 13:49 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 04:59 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 14:03 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 05:21 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 14:35 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 05:46 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 15:11 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 06:41 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 16:15 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 08:11 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 08:19 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 17:42 +0100
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 17:40 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 09:04 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 18:05 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 09:13 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 18:16 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 09:25 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 18:26 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 09:21 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 18:25 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 09:31 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 18:33 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-12 13:21 +0000
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-13 09:16 +0100
Re: Do "C" arrays start a 0 or 1? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-13 04:28 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 13:36 +0100
Re: Do "C" arrays start a 0 or 1? Öö Tiib <ootiib@hot.ee> - 2020-01-13 04:39 -0800
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-13 15:22 +0100
Re: Do "C" arrays start a 0 or 1? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-13 05:10 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 15:10 +0100
Re: Do "C" arrays start a 0 or 1? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-13 07:31 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 16:34 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 06:59 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 16:32 +0100
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 17:17 +0100
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 18:13 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 09:19 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 18:22 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 09:29 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 18:34 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 09:40 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 18:42 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 09:56 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 19:19 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 10:21 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 19:25 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 10:46 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 08:02 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-15 01:04 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-15 01:25 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-15 06:37 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-15 10:49 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-02-04 01:15 -0800
Re: Do "C" arrays start a 0 or 1? Siri Cruise <chine.bleu@yahoo.com> - 2020-02-04 01:48 -0800
Re: Do "C" arrays start a 0 or 1? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-04 02:29 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-02-04 03:05 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-02-04 04:07 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-02-04 04:59 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 08:51 -0800
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-13 15:19 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 06:47 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 06:51 -0800
Re: Do "C" arrays start a 0 or 1? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-13 09:35 -0800
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-13 21:48 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 12:54 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 13:38 -0800
Re: Do "C" arrays start a 0 or 1? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-14 02:30 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-14 02:40 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-14 02:47 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-14 03:52 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-14 04:00 -0800
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-14 14:20 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 02:21 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 12:50 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 04:14 -0800
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-12 14:23 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 16:16 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 08:13 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 17:43 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-12 17:42 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 18:43 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-12 18:04 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 19:31 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-12 21:18 +0000
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 13:53 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 19:36 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-12 20:56 +0000
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 10:04 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 02:05 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 12:43 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 03:46 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 12:51 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 03:58 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 13:14 +0100
Re: Do "C" arrays start a 0 or 1? gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-07 13:03 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-21 16:44 +0100
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-02-04 02:29 -0800 |
| Message-ID | <87v9om3asx.fsf@nosuchdomain.example.com> |
| In reply to | #149717 |
Siri Cruise <chine.bleu@yahoo.com> writes:
> int c0[42];
>
> int ours = c0-11;
You probably meant
int *ours = c0-11;
But evaluating c0-11 has undefined behavior.
> // ours goes from 11, ours[11].
This:
int c0[42];
int *ours = c0+11;
would make the point. ours[i] is valid for i from -11 to +30
(and ours+31 is a valid address, but dereferencing it is UB).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-02-04 03:05 -0800 |
| Message-ID | <c5a2013b-decc-469b-bf23-a350defa201a@googlegroups.com> |
| In reply to | #149716 |
W dniu wtorek, 4 lutego 2020 10:15:52 UTC+1 użytkownik fir napisał:
> W dniu środa, 15 stycznia 2020 15:38:04 UTC+1 użytkownik fir napisał:
> > W dniu środa, 15 stycznia 2020 10:25:34 UTC+1 użytkownik fir napisał:
> > > W dniu środa, 15 stycznia 2020 10:04:24 UTC+1 użytkownik fir napisał:
> > > > W dniu poniedziałek, 13 stycznia 2020 17:02:37 UTC+1 użytkownik fir napisał:
> > > > > W dniu poniedziałek, 13 stycznia 2020 15:59:54 UTC+1 użytkownik fir napisał:
> > > > > >
> > > > > > well talking of that constructors is typical for c++ mess over something that in ca has about five lines of c
> > > > > >
> > > > > i may add hovever quicksort being so short is a short piece of code that can bring a lot of confusion (being lost)..there ase such pieces of code in c (i also got some like that, though different type of confusion in some pieces of my chunk codes).. i probably could name such pieces of code as a "tangled"
> > > > > unlike that most good code in c is block-to-block strighforward "orthogonal" code
> > > > >
> > > > > i recently thought if hiperodularity can bring c forward in comparable way c brought asm forward (by math expressions, typisation, portability, overall eleggance (provedural paradigm with ifs anfd fors i could probably exclude at least partially as asm is kinda procedural and supports branching itself))..and i dont know
> > > > >
> > > > >
> > > > > it seems there could be a gain becouse c is a bit in diostance to block-to-block paradigm as its modules are big-grained and its functions are sorta tangled/convoluted slightly, i mean functions dont acts ac blocks and most iof its definition is by its names ("do that or that") but not by its "blockness")...hipermodularity could potentially imptove it by far defining real small grained blocks thus making coding easier and clearer
> > > > >
> > > > > maybe.. as it is not yet througfully tested..one example that i thinked about was this mapper micromodule and eventually other blocks if defined (palette, iteration, pixel provider (?, pixel area?), screen (?, or bitmap, or vievport?)
> > > > >
> > > > > hipermodularity eventually can make coding much more orthogonal on smaller grained scale thus also easier to decopmpose/compose and edit
> > > > >
> > > > > hovever people would need to learnd how to do it
> > > >
> > > > hovever to grant that kind of big step forward i think this 'good things' like here that mentioned orthogonality in smalgrained size must not only be present but probably be massive
> > > >
> > > > other improvement i thinked of is also some improved kind of reusability..in c you got something you can name reusability just by using functions/function but the problem (as i thought yesterday on it) is that function not holds any state (i mean not any that varies among varius use places) and i think this limits that reusability a lot
> > > > (i mean function is like one type one value, is not differentiated by values)
> > > >
> > > > if some would use some module it could
> > > > ad hoc configure varius values in varius use places and that should grand much better (if not much much better) reusability..ind given that reusabiility might mean that you reuse code more (pieces are more generic) so you write it less (hopefully substantially less)
> > > >
> > > > i will later maybe inent some examples
> > >
> > >
> > >
> > > so i meant there is a hope/chance that small grained and lightweight hipermodularity will allow to
> > > 1) significantly decompose on orthogonal and small neat piees and thus improve ease (easability) of writing codes (make codes easier to decompose thus code and read)
> > > 2) significantly increase reusability thus allowing codes to be shorter
> > >
> > > one example i could get would be a module of file, you could use something like that maybe
> > >
> > > void main()
> > > {
> > > file("some.txt") f;
> > > f[f.size-1]++;
> > > }
> > >
> >
> >
> > btw some could say "it is like c++" or more worse (and false as i really hate oop (as i know it from cpp/java)) "youre repeating c++" but it is not like that - there are some even big resemblances but there are also some big differences making it quite other thing
> >
> > i already answered to that thing though i may answer it a bit more in that point
> >
> > forst thing, imo c++ is done like someone would take some printed book (of autorship of quite other people, maybe even in differnt language) take felt-tip
> > pen and wrote a "clesses" (that c++ classes pseudocode) over its pages (on printed ones and maybe on blank places)
> > (whose classes btw are also taken form sometjhing other afair)
> >
> > in this what i cal hipermodularity (hipermodular c) i rather feel like i take c rethinked it and changed the c, extended some of it concepts and this make another possibilities, thus i think i would say i changed c not added something to c (like c++ added those crap classes to c) where i changed ideas over
> > some concepts of c (mainly entities and idea of module) thats why it hat this buildin fractality in it which is not seen/ observable in c++
> >
> > i could yet mention two very big differences
> >
> > 1) one is that mentioned fractality which here is totally seen (built-in) (unlike c++)
> >
> > 2) the extreme difference as to this all pointers where what here i name as modules (sometimes those smaller as micromodules) is acesed just like all other entities, it is by labels where in
> > c++ you get big dose of extremally crap pointers attached to it
> >
> > thinking a bit on that i think it was becouse those creators of c++ (or something on which it was based maybe etc) got no idea of internally ram 'pools' based on static seeds and reallocks (and unique idea of "static that is attached to place of usage" not to place of definition, the idea i finally noticed) - thiose people not knowing that probably felt a need of mallock-like allocations based on heep, coz they knew that in general probably stack memory is not enough to 'host' all that ram then eventually needed - this way ptobably crappy new allocations was bor and thus extremally crappy attached pointers was born
> >
> > so dont say this is not a big difference ;c (though real difference is in internal thinking on it from which it was born)
> >
> > 3) maybe there are also other important differences but i yet not thinked on them to that point (some could be mention as like in kipermodular c i dont need any crappy idea of constructors or destructors etc, whan i would use such
> > syntaxes like
> >
> > int(10) a,b,c;
> > and
> >
> > int a(1), b(20), c(30)
> > (not yet fully decided as to this but consider this topic)
> >
> > those things in parentesis come from the resemblance between modules and functions
> > (when module may be also a function)
> > not denote constructors..etc..but this is smaller remark not such big point of difference... as i said i yet not quite inspected how differences show in real life code here (this is partially i avoid to use c++ and really not used it for long long yers, and back then when i used it i disliked it a lot and never learned my way into it)
> >
> > this not changes a side topic that this hipermodurality on which i say can be partially (not fully) simulated in c++
> > if soeone would define modules (structs containing functions) if he would not use
> > new and mallocks and try to use only static sized ones and try to do some things based on static seeds and reallocks, but it only van be done partially as c++ needs here also that thing what c clasks it is this new type of static that is created at the place of usage not by definition (at least things probably looks that way as i not tried that thing to see how things look like -
> > without that seeds one would need to pas out handles (yuck) or use some tricks (like internal static array of seeds etc)
> >
> > haovever all that should not stop me from discovering advantages of well done hipermodularity for now purely on paper until i will finish the compiler
> >
> >
> > hovever i may see this is sorta big thing imo, at least it looks like so a bit..new era in programming is coming .. (slowly ;c )
> >
> >
> >
> >
> >
> >
> > > i meant make (mallocked/heap based)
> > > ram pool (area) and read file from disk into it... then increase last charecter in it one up. then eventually save
> > >
> > > f.save();
> > >
> > > (there is design problem if it is not better to create it maybe more like
> > >
> > > file f;
> > > f.load("some.txt");
> > >
> > > bt this is secondary in that context
> > >
> > > or if to use
> > >
> > > file a("ala.txt"), b("bip.txt"), c("chip.txt"");
> > >
> > >
> > >
> > > what i mean here the syntax to do that in (hipermodular c) is so light as in c (no cprap pointer passing also as in c++) and the syntaktic capacity is rather big
> > >
> > > this capacity you could use by defining your own code pieces (thus making it as i said both very orthogonal,(also lightweight), and massively reusable)
> > >
> > > also as i think it would be massive increase (i mean kick/force) in direction of standarisation as many of that kind of mudules will probably born acepted patterns and kinda work like standarisation way
>
>
> ps i will add yet some thing to list why what i call hipermodularity difers from cpp OOP
>
> today i revrite emo c++ code and see what this crap c++ is again (after bot touching it 14 years or so)
>
> in c++ OOP you simply create complications and another set of your own microdependencies of which you may then care (and it is radically idiotic)
>
> for example in one method you set some field being pointer to something where in another method you use it
>
> beware if you do not carefully care if it is set (and this dependency is this devillish temporal one not spacial) you will get a crash :O this is espacially foony compared to those c++ nobrains that talk about void* so much when dealing with that crashes on pointer fields
>
> this is what this crap is doing to you,
> you create annoying web of dependencies
> on which you must then care which is nonsense
>
> (note i got almost no practical c++ experience thus i know it is a perspective of newb and can say more how i would deal with that writing this more,
> but its not on what i am talking here)
>
> here i only want to mention the 'opositional' differences between suh OOP crap and hipermodularity, hipermodularity
> not makes such additional burdening dependency nets of trash kind
note hipermodularity allows maybe answer on some problems relating to writing in c++
i got such object as food (this is food piece in snake game)
this food gets practically two methods
draw() and setRandomPosition() (should be moveToRandomPosition in fact)
both need to read window as one needs it
to draw other to know cliant size
so the relation is this
Window window(800, 600)
SnakeFood food
food.draw(window)
food.moveToRandomPosition(window)
the c++ heasitation i get is if i should
put the reference to window into food (as field) as c++ often if not usually do
SnakeFood food(window)
food.draw()
food.moveToRandomPosition()
is this propper/better from hipermodular view?
for me the answer form hipermodular wiev seem to be no, it seem to be kinda wrong becouse you spoil narrow stright specific connections into more 'general' side road one
i mean i find it as a generally somewhat wrong, though in some more special cases
it could be rethinked if not to be used for some purpose.. but as for now i would need to remember some reserve as to it
(aspecially as honestly this kind of connection is not so general anyway i mean draw needs not whole window probably (would need a moment to think on it) and
moveToRandomPosition dont need general window yet more, it only wants a rectangle area
as to c++ wrongness i may also add it not only expect you to build an extremally idiotic and burdening net of relation but i also noticedit not statically checks fully for correctnes of it, i just found another runtime explosion eben not based
on pointer fields,
(i made a mistake in something that should look like
Food::Food(sf::RenderWindow& w): window(w)
it was
Food::Food(sf::RenderWindow& w): window(window)
and he silently took it)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-02-04 04:07 -0800 |
| Message-ID | <ad6ae507-c5f5-41a3-9f01-b6865ecf08c3@googlegroups.com> |
| In reply to | #149719 |
W dniu wtorek, 4 lutego 2020 12:05:17 UTC+1 użytkownik fir napisał: > > > > > > ps i will add yet some thing to list why what i call hipermodularity difers from cpp OOP > > > > today i revrite emo c++ code and see what this crap c++ is again (after bot touching it 14 years or so) > > > > in c++ OOP you simply create complications and another set of your own microdependencies of which you may then care (and it is radically idiotic) > > > > for example in one method you set some field being pointer to something where in another method you use it > > > > beware if you do not carefully care if it is set (and this dependency is this devillish temporal one not spacial) you will get a crash :O this is espacially foony compared to those c++ nobrains that talk about void* so much when dealing with that crashes on pointer fields > > > > this is what this crap is doing to you, > > you create annoying web of dependencies > > on which you must then care which is nonsense > > > > (note i got almost no practical c++ experience thus i know it is a perspective of newb and can say more how i would deal with that writing this more, > > but its not on what i am talking here) > > > > here i only want to mention the 'opositional' differences between suh OOP crap and hipermodularity, hipermodularity > > not makes such additional burdening dependency nets of trash kind > > note hipermodularity allows maybe answer on some problems relating to writing in c++ > > i got such object as food (this is food piece in snake game) > > this food gets practically two methods > draw() and setRandomPosition() (should be moveToRandomPosition in fact) > > both need to read window as one needs it > to draw other to know cliant size > > so the relation is this > > Window window(800, 600) > > SnakeFood food > > food.draw(window) > food.moveToRandomPosition(window) > > the c++ heasitation i get is if i should > put the reference to window into food (as field) as c++ often if not usually do > > SnakeFood food(window) > > food.draw() > food.moveToRandomPosition() > > is this propper/better from hipermodular view? > > for me the answer form hipermodular wiev seem to be no, it seem to be kinda wrong becouse you spoil narrow stright specific connections into more 'general' side road one > > i mean i find it as a generally somewhat wrong, though in some more special cases > it could be rethinked if not to be used for some purpose.. but as for now i would need to remember some reserve as to it > > (aspecially as honestly this kind of connection is not so general anyway i mean draw needs not whole window probably (would need a moment to think on it) and > moveToRandomPosition dont need general window yet more, it only wants a rectangle area > hoever i may add it is yet some thing to consider to me... it is becouse this 'wrong generality' (in its both faces mentioned 1) pass opnce 2) pass window is kinda tempting at least in some (maybe wrong im not sure) cases: a) you simply do not pass many times b) you simply do not to pass specific i rest it for further rethinking
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-02-04 04:59 -0800 |
| Message-ID | <b4694ed8-a6a5-4ced-a6f0-210f59dddd64@googlegroups.com> |
| In reply to | #149720 |
yet another c++ doom i observe is tearing code out to places (im adding to completion as maybe somedey it could be sumarizing in some list)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-13 08:51 -0800 |
| Message-ID | <da782238-8f3a-4f51-8596-c2ae350ead39@googlegroups.com> |
| In reply to | #149027 |
W dniu poniedziałek, 13 stycznia 2020 15:59:54 UTC+1 użytkownik fir napisał:
>
> void Quicksort(chunks a)
> {
> int lo = 0;
> int hi = a.last - a.first ;
>
> int i = lo;
> int j = hi;
>
> while (i < hi)
> {
>
> chunk pivot = a.first[(lo+hi)/2];
> // Partition
> while (i <= j)
> {
> while ( Compare(a.first[i], pivot) < 0 )
> {
> i = i + 1;
> }
> while (Compare( a.first[j], pivot) > 0)
> {
> j = j - 1;
> }
> if (i <= j)
> {
> chunk t = a.first[i];
> a.first[i] = a.first[j];
> a.first[j] = t;
> i = i + 1;
> j = j - 1;
> }
> }
>
> // Recursion for quicksort
> if (lo < j)
> {
> chunks x = { a.first + lo, a.first + j };
> Quicksort(x);
> }
> lo = i;
> j = hi;
> }
> }
>
> hovever i remmember i was messing sometimes with that code and im not sure if its ok (though oriobably yes)
>
>
checked it slightly and it seem to be ok, its also faster than this upper versions with two stack calls (and i forgot about this version as some googlings dont shows that back then i found it then forgot)
i will update the boring thread about quicksort with this version and info on times
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-13 15:19 +0100 |
| Message-ID | <qvhua7$njh$1@dont-email.me> |
| In reply to | #149017 |
On 13/01/2020 13:28, Malcolm McLean wrote: > On Monday, 13 January 2020 08:16:12 UTC, David Brown wrote: >> >> I am not sure I should get involved here, but remember that C++ is >> approximately a superset of C. Baring a few minor points, if you can >> write something in C you can write it the same way in C++. So if you >> are happy with function-based solutions in a separately compiled unit in >> C, you can get exactly the same thing in C++. >> > But take qsort(), for example. In C, this function will sort pretty much > any array correctly, barring the rare case of arrays with internal > pointers. In C++, probably most arrays can't be safely sorted with > qsort() because moving memory disrupts the constructor / destructor > system. So you need a templated sort for your default general-purpose > sort routine. > It is /really/ simple. Any type that can be expressed in C, and sorted in C with qsort, can be written in exactly the same way in C++, and sorted in exactly the same way with qsort. If you have a type in C++ that you can't sort with qsort in C++, you could not sort it with qsort in C either. (Most likely, you couldn't even define it in C.) Baring a few features (like VLAs and designated initialisers), a few extra requirements for casts (like having to cast void* pointers), and a few other incompatibilities (like the type of 'a'), C is a subset of C++. If you can write the code in C, you can almost always compile it as C++ with little or no change. So assuming a suitable compiler exists for your target, if you can do something in C you can do the same thing in C++. It is not going to be idiomatic C++, but it will work.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-13 06:47 -0800 |
| Message-ID | <41158dfe-96df-436c-be07-117c9e123c41@googlegroups.com> |
| In reply to | #149023 |
W dniu poniedziałek, 13 stycznia 2020 15:19:59 UTC+1 użytkownik David Brown napisał: > On 13/01/2020 13:28, Malcolm McLean wrote: > > On Monday, 13 January 2020 08:16:12 UTC, David Brown wrote: > >> > >> I am not sure I should get involved here, but remember that C++ is > >> approximately a superset of C. Baring a few minor points, if you can > >> write something in C you can write it the same way in C++. So if you > >> are happy with function-based solutions in a separately compiled unit in > >> C, you can get exactly the same thing in C++. > >> > > But take qsort(), for example. In C, this function will sort pretty much > > any array correctly, barring the rare case of arrays with internal > > pointers. In C++, probably most arrays can't be safely sorted with > > qsort() because moving memory disrupts the constructor / destructor > > system. So you need a templated sort for your default general-purpose > > sort routine. > > > > It is /really/ simple. > > Any type that can be expressed in C, and sorted in C with qsort, can be > written in exactly the same way in C++, and sorted in exactly the same > way with qsort. you make sorta dumb assumption that if someone writes compares c and c++ they talk about this c++ that is a c itself people talk anout the specific c++ with its styles not in c and have that on mind so dont go dumb come and say they do not if you name c compiled in c++ as c++ its another discussion but its sorta logical error to name it as c++ in many contextes when i will take my c code and compile it in c++ mode (even if i use sole c++ feature it is const int for array sizes) it is still a c..idiots my talk its c++ formally but thats typical idiots life i dont want to be mixed with it
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-13 06:51 -0800 |
| Message-ID | <f727b2ee-49d1-4038-8f15-05acd51aa7d6@googlegroups.com> |
| In reply to | #149023 |
W dniu poniedziałek, 13 stycznia 2020 15:19:59 UTC+1 użytkownik David Brown napisał: > On 13/01/2020 13:28, Malcolm McLean wrote: > > On Monday, 13 January 2020 08:16:12 UTC, David Brown wrote: > >> > >> I am not sure I should get involved here, but remember that C++ is > >> approximately a superset of C. Baring a few minor points, if you can > >> write something in C you can write it the same way in C++. So if you > >> are happy with function-based solutions in a separately compiled unit in > >> C, you can get exactly the same thing in C++. > >> > > But take qsort(), for example. In C, this function will sort pretty much > > any array correctly, barring the rare case of arrays with internal > > pointers. In C++, probably most arrays can't be safely sorted with > > qsort() because moving memory disrupts the constructor / destructor > > system. So you need a templated sort for your default general-purpose > > sort routine. > > > > It is /really/ simple. > > Any type that can be expressed in C, and sorted in C with qsort, can be > written in exactly the same way in C++, and sorted in exactly the same > way with qsort. If you have a type in C++ that you can't sort with > qsort in C++, you could not sort it with qsort in C either. (Most > likely, you couldn't even define it in C.) > > Baring a few features (like VLAs and designated initialisers), a few > extra requirements for casts (like having to cast void* pointers), and a > few other incompatibilities (like the type of 'a'), C is a subset of > C++. If you can write the code in C, you can almost always compile it > as C++ with little or no change. > > So assuming a suitable compiler exists for your target, if you can do > something in C you can do the same thing in C++. It is not going to be > idiomatic C++, but it will work. i think you should limit that kind of dumb rematks youre not in kindergarten
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-01-13 09:35 -0800 |
| Message-ID | <95931957-9b6c-4960-abbc-10cfc1db54c0@googlegroups.com> |
| In reply to | #149023 |
On Monday, 13 January 2020 14:19:59 UTC, David Brown wrote: > > So assuming a suitable compiler exists for your target, if you can do > something in C you can do the same thing in C++. It is not going to be > idiomatic C++, but it will work. > That's the point. We can write a "general purpose sort" in C using only portable C code with no dependencies. However if we move to C++, it is no longer a general purpose sort. The C++ general purpose sort has to be written with templates. It's the only way of honouring the C++ constructor / destructor / move system.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-13 21:48 +0100 |
| Message-ID | <qvil2g$ef2$1@dont-email.me> |
| In reply to | #149040 |
On 13/01/2020 18:35, Malcolm McLean wrote: > On Monday, 13 January 2020 14:19:59 UTC, David Brown wrote: >> >> So assuming a suitable compiler exists for your target, if you can do >> something in C you can do the same thing in C++. It is not going to be >> idiomatic C++, but it will work. >> > That's the point. It certainly is not the point you tried to make earlier - it is, in fact, the opposite. > We can write a "general purpose sort" in C using only > portable C code with no dependencies. Yes. And the same code will work in C++ - (almost) anything you can do in C, you can do equally well in C++ because you can use exactly the same code. > However if we move to C++, it is > no longer a general purpose sort. Of course it is a general purpose sort. That applies whether you mean taking the general purpose C sort and compiling it as C++, or if you mean writing a C++ template-style sort. > The C++ general purpose sort has to > be written with templates. Nonsense. > It's the only way of honouring the C++ > constructor / destructor / move system. > Nonsense. Templates are the best - clearest and most efficient - way to write a general-purpose sort in C++ that works with non-POD types. But they are not the only way - you could happily write a generic sort function that takes a "compare" and a "swap" function pointer as parameters, and use it with types that have non-trivial constructors and destructors. And the whole point of this branch was that anything you can do in C, you can do in C++. If you have a type in C that can be sorted by qsort, then it can be sorted by qsort in C++. And if you have a type in C that can't be sorted by qsort (perhaps because it contains pointers that reference other parts of the same object), then you can't sort it by qsort in C++ either. But you /can/ sort it with a template-based sort. And you can sort it in either language with a more sophisticated sort function that includes a "swap function" parameter.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-13 12:54 -0800 |
| Message-ID | <09b274a4-73a5-4f6d-bf8c-8c606cb6be17@googlegroups.com> |
| In reply to | #149053 |
W dniu poniedziałek, 13 stycznia 2020 21:48:24 UTC+1 użytkownik David Brown napisał: > > And the whole point of this branch was that anything you can do in C, > you can do in C++. If you have a type in C that can be sorted by qsort, > then it can be sorted by qsort in C++. > that whole point is your trolling, yet you troll seriously which is double worse its like take C compiler say it sompiles new language E which is identical as C then troll everynone that anythink you can do in c you can also do in E so E is really great language comparable to c and better as you added also some shit to it
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-13 13:38 -0800 |
| Message-ID | <1f9d4b4b-9c3a-4ff9-a0c6-1bbc50023d08@googlegroups.com> |
| In reply to | #149054 |
W dniu poniedziałek, 13 stycznia 2020 21:54:49 UTC+1 użytkownik fir napisał: > W dniu poniedziałek, 13 stycznia 2020 21:48:24 UTC+1 użytkownik David Brown napisał: > > > > And the whole point of this branch was that anything you can do in C, > > you can do in C++. If you have a type in C that can be sorted by qsort, > > then it can be sorted by qsort in C++. > > > > that whole point is your trolling, yet you troll seriously which is double worse > > its like take C compiler say it sompiles new language E which is identical as C then troll everynone that anythink you can do in c you can also do in E so E is really great language comparable to c and better as you added also some shit to it btw it rises some legal questions as for example i would not be happy if someone would take my hipermodular c added some shit to it and name it great language of (hipermodular c)++ though also i would not like to be not able to extend c (as if it would be licensed/patented) c++ made terrible thing by taking most pure language and adding sticky shit to it, i wonder if this was not a precedence and languages before was born by taking something and glueing something other (worse) to it
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-01-14 02:30 -0800 |
| Message-ID | <87bb673b-73b6-4c6f-94ce-45c048bd4420@googlegroups.com> |
| In reply to | #149053 |
On Monday, 13 January 2020 20:48:24 UTC, David Brown wrote: > On 13/01/2020 18:35, Malcolm McLean wrote: > > On Monday, 13 January 2020 14:19:59 UTC, David Brown wrote: > >> > >> So assuming a suitable compiler exists for your target, if you can do > >> something in C you can do the same thing in C++. It is not going to be > >> idiomatic C++, but it will work. > >> > > That's the point. > > It certainly is not the point you tried to make earlier - it is, in > fact, the opposite. > > > We can write a "general purpose sort" in C using only > > portable C code with no dependencies. > > Yes. And the same code will work in C++ - (almost) anything you can do > in C, you can do equally well in C++ because you can use exactly the > same code. > > > However if we move to C++, it is > > no longer a general purpose sort. > > Of course it is a general purpose sort. That applies whether you mean > taking the general purpose C sort and compiling it as C++, or if you > mean writing a C++ template-style sort. > A general purpose sort sorts "pretty much anything". In C, that means arrays of structures. The sort won't work for linked lists, or for structures which contain pointers to internals, but those are comparatively rare. Basically, if we want to sort something in C, we can use qsort(). Now we move to C++. Obvioulsy if we simply make a few trivial changes to the code to make it compatible with C++, then all our structs are what C++ calls "PODs", or "plain old data types". But that's not idiomatic C++. If we are using C++< it is likely that the code will acumulate classes and std::vectors. Ability to use such facilities is likely the reason we moved to C++. So qsort is no longer a general purose sort. It won't sort "almost anything", but only the legacy C arrays. > > > The C++ general purpose sort has to > > be written with templates. > > Nonsense. > You could pass in the swap function, fair enough. That would have to take void pointers and cast them back to the appropriate types, so it would have to specially written. But it would work.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-14 02:40 -0800 |
| Message-ID | <999c2072-7c98-47a0-91a1-b57a4b855148@googlegroups.com> |
| In reply to | #149069 |
W dniu wtorek, 14 stycznia 2020 11:30:34 UTC+1 użytkownik Malcolm McLean napisał: > On Monday, 13 January 2020 20:48:24 UTC, David Brown wrote: > > On 13/01/2020 18:35, Malcolm McLean wrote: > > > On Monday, 13 January 2020 14:19:59 UTC, David Brown wrote: > > >> > > >> So assuming a suitable compiler exists for your target, if you can do > > >> something in C you can do the same thing in C++. It is not going to be > > >> idiomatic C++, but it will work. > > >> > > > That's the point. > > > > It certainly is not the point you tried to make earlier - it is, in > > fact, the opposite. > > > > > We can write a "general purpose sort" in C using only > > > portable C code with no dependencies. > > > > Yes. And the same code will work in C++ - (almost) anything you can do > > in C, you can do equally well in C++ because you can use exactly the > > same code. > > > > > However if we move to C++, it is > > > no longer a general purpose sort. > > > > Of course it is a general purpose sort. That applies whether you mean > > taking the general purpose C sort and compiling it as C++, or if you > > mean writing a C++ template-style sort. > > > A general purpose sort sorts "pretty much anything". In C, that means arrays > of structures. The sort won't work for linked lists, or for structures which > contain pointers to internals, but those are comparatively rare. Basically, > if we want to sort something in C, we can use qsort(). > Now we move to C++. Obvioulsy if we simply make a few trivial changes to > the code to make it compatible with C++, then all our structs are what > C++ calls "PODs", or "plain old data types". But that's not idiomatic C++. > If we are using C++< it is likely that the code will acumulate classes > and std::vectors. Ability to use such facilities is likely the reason we > moved to C++. So qsort is no longer a general purose sort. It won't sort > "almost anything", but only the legacy C arrays. > > > > > The C++ general purpose sort has to > > > be written with templates. > > > > Nonsense. > > > You could pass in the swap function, fair enough. That would have to take > void pointers and cast them back to the appropriate types, so it would > have to specially written. But it would work. in my opinion for normal coder c++ stl shit is out becouse of 'architectural' stupidity of that tthing...qsort is out becouse of being slow..simply take a pice of code i recently posted (mixed quickinsertsort) and go
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-14 02:47 -0800 |
| Message-ID | <eed1e7c0-ac4a-4f4e-867f-7570c4603cc9@googlegroups.com> |
| In reply to | #149070 |
W dniu wtorek, 14 stycznia 2020 11:40:58 UTC+1 użytkownik fir napisał: > W dniu wtorek, 14 stycznia 2020 11:30:34 UTC+1 użytkownik Malcolm McLean napisał: > > On Monday, 13 January 2020 20:48:24 UTC, David Brown wrote: > > > On 13/01/2020 18:35, Malcolm McLean wrote: > > > > On Monday, 13 January 2020 14:19:59 UTC, David Brown wrote: > > > >> > > > >> So assuming a suitable compiler exists for your target, if you can do > > > >> something in C you can do the same thing in C++. It is not going to be > > > >> idiomatic C++, but it will work. > > > >> > > > > That's the point. > > > > > > It certainly is not the point you tried to make earlier - it is, in > > > fact, the opposite. > > > > > > > We can write a "general purpose sort" in C using only > > > > portable C code with no dependencies. > > > > > > Yes. And the same code will work in C++ - (almost) anything you can do > > > in C, you can do equally well in C++ because you can use exactly the > > > same code. > > > > > > > However if we move to C++, it is > > > > no longer a general purpose sort. > > > > > > Of course it is a general purpose sort. That applies whether you mean > > > taking the general purpose C sort and compiling it as C++, or if you > > > mean writing a C++ template-style sort. > > > > > A general purpose sort sorts "pretty much anything". In C, that means arrays > > of structures. The sort won't work for linked lists, or for structures which > > contain pointers to internals, but those are comparatively rare. Basically, > > if we want to sort something in C, we can use qsort(). > > Now we move to C++. Obvioulsy if we simply make a few trivial changes to > > the code to make it compatible with C++, then all our structs are what > > C++ calls "PODs", or "plain old data types". But that's not idiomatic C++. > > If we are using C++< it is likely that the code will acumulate classes > > and std::vectors. Ability to use such facilities is likely the reason we > > moved to C++. So qsort is no longer a general purose sort. It won't sort > > "almost anything", but only the legacy C arrays. > > > > > > > The C++ general purpose sort has to > > > > be written with templates. > > > > > > Nonsense. > > > > > You could pass in the swap function, fair enough. That would have to take > > void pointers and cast them back to the appropriate types, so it would > > have to specially written. But it would work. > > in my opinion for normal coder c++ stl shit is out becouse of 'architectural' stupidity of that tthing...qsort is out becouse of being slow..simply take a pice of code i recently posted (mixed quickinsertsort) and go qsort is realy slow in my test it take 252 ms to sort 1e6 ints when this mixed quickinsertsort take 111 ms same as c++ std:sort (maybe 1 ms worse hard to see as it somewhat oscilates from run to run even on the identical input) i probably could beat this result (and thus std:sort) spending some hours on finding some improvements
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-14 03:52 -0800 |
| Message-ID | <2f6177dd-7a62-46e4-b3de-8abef3e7b6d5@googlegroups.com> |
| In reply to | #149071 |
W dniu wtorek, 14 stycznia 2020 11:47:20 UTC+1 użytkownik fir napisał: > W dniu wtorek, 14 stycznia 2020 11:40:58 UTC+1 użytkownik fir napisał: > > W dniu wtorek, 14 stycznia 2020 11:30:34 UTC+1 użytkownik Malcolm McLean napisał: > > > On Monday, 13 January 2020 20:48:24 UTC, David Brown wrote: > > > > On 13/01/2020 18:35, Malcolm McLean wrote: > > > > > On Monday, 13 January 2020 14:19:59 UTC, David Brown wrote: > > > > >> > > > > >> So assuming a suitable compiler exists for your target, if you can do > > > > >> something in C you can do the same thing in C++. It is not going to be > > > > >> idiomatic C++, but it will work. > > > > >> > > > > > That's the point. > > > > > > > > It certainly is not the point you tried to make earlier - it is, in > > > > fact, the opposite. > > > > > > > > > We can write a "general purpose sort" in C using only > > > > > portable C code with no dependencies. > > > > > > > > Yes. And the same code will work in C++ - (almost) anything you can do > > > > in C, you can do equally well in C++ because you can use exactly the > > > > same code. > > > > > > > > > However if we move to C++, it is > > > > > no longer a general purpose sort. > > > > > > > > Of course it is a general purpose sort. That applies whether you mean > > > > taking the general purpose C sort and compiling it as C++, or if you > > > > mean writing a C++ template-style sort. > > > > > > > A general purpose sort sorts "pretty much anything". In C, that means arrays > > > of structures. The sort won't work for linked lists, or for structures which > > > contain pointers to internals, but those are comparatively rare. Basically, > > > if we want to sort something in C, we can use qsort(). > > > Now we move to C++. Obvioulsy if we simply make a few trivial changes to > > > the code to make it compatible with C++, then all our structs are what > > > C++ calls "PODs", or "plain old data types". But that's not idiomatic C++. > > > If we are using C++< it is likely that the code will acumulate classes > > > and std::vectors. Ability to use such facilities is likely the reason we > > > moved to C++. So qsort is no longer a general purose sort. It won't sort > > > "almost anything", but only the legacy C arrays. > > > > > > > > > The C++ general purpose sort has to > > > > > be written with templates. > > > > > > > > Nonsense. > > > > > > > You could pass in the swap function, fair enough. That would have to take > > > void pointers and cast them back to the appropriate types, so it would > > > have to specially written. But it would work. > > > > in my opinion for normal coder c++ stl shit is out becouse of 'architectural' stupidity of that tthing...qsort is out becouse of being slow..simply take a pice of code i recently posted (mixed quickinsertsort) and go > > qsort is realy slow in my test it take 252 ms to sort 1e6 ints when this mixed quickinsertsort take 111 ms same as c++ std:sort (maybe 1 ms worse hard to see as it somewhat oscilates from run to run even on the identical input) > > i probably could beat this result (and thus std:sort) spending some hours on finding some improvements yet see info on sorting in other thread, and generally see, i repeat what i measured (i measure sorting 1e6 integers (positive from 0 to (2^24)-1 ) qsort - 252 ms my quicksort code snippet (this nice one) - 140 ms my quicksort + insert sort code snippet (provided) - 111.5 ms std:sort of c++ - 111 ms radix sort taken from some guy on stack - 27.5 ms for signed integers 26 ms for unsigned (you may delete 3.5 ms from all those values as its overhead of my time plots drawing system) (more details:it was measured on 32 bin xp old core 2 ps compiled on gcc 2015 or 2016 only with -O2 flag as to optimisations) (i use this older for purpose)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-14 04:00 -0800 |
| Message-ID | <4e9c7dd0-c4f6-45ad-b3bc-d98ca897b3e2@googlegroups.com> |
| In reply to | #149075 |
W dniu wtorek, 14 stycznia 2020 12:52:14 UTC+1 użytkownik fir napisał: > W dniu wtorek, 14 stycznia 2020 11:47:20 UTC+1 użytkownik fir napisał: > > W dniu wtorek, 14 stycznia 2020 11:40:58 UTC+1 użytkownik fir napisał: > > > W dniu wtorek, 14 stycznia 2020 11:30:34 UTC+1 użytkownik Malcolm McLean napisał: > > > > On Monday, 13 January 2020 20:48:24 UTC, David Brown wrote: > > > > > On 13/01/2020 18:35, Malcolm McLean wrote: > > > > > > On Monday, 13 January 2020 14:19:59 UTC, David Brown wrote: > > > > > >> > > > > > >> So assuming a suitable compiler exists for your target, if you can do > > > > > >> something in C you can do the same thing in C++. It is not going to be > > > > > >> idiomatic C++, but it will work. > > > > > >> > > > > > > That's the point. > > > > > > > > > > It certainly is not the point you tried to make earlier - it is, in > > > > > fact, the opposite. > > > > > > > > > > > We can write a "general purpose sort" in C using only > > > > > > portable C code with no dependencies. > > > > > > > > > > Yes. And the same code will work in C++ - (almost) anything you can do > > > > > in C, you can do equally well in C++ because you can use exactly the > > > > > same code. > > > > > > > > > > > However if we move to C++, it is > > > > > > no longer a general purpose sort. > > > > > > > > > > Of course it is a general purpose sort. That applies whether you mean > > > > > taking the general purpose C sort and compiling it as C++, or if you > > > > > mean writing a C++ template-style sort. > > > > > > > > > A general purpose sort sorts "pretty much anything". In C, that means arrays > > > > of structures. The sort won't work for linked lists, or for structures which > > > > contain pointers to internals, but those are comparatively rare. Basically, > > > > if we want to sort something in C, we can use qsort(). > > > > Now we move to C++. Obvioulsy if we simply make a few trivial changes to > > > > the code to make it compatible with C++, then all our structs are what > > > > C++ calls "PODs", or "plain old data types". But that's not idiomatic C++. > > > > If we are using C++< it is likely that the code will acumulate classes > > > > and std::vectors. Ability to use such facilities is likely the reason we > > > > moved to C++. So qsort is no longer a general purose sort. It won't sort > > > > "almost anything", but only the legacy C arrays. > > > > > > > > > > > The C++ general purpose sort has to > > > > > > be written with templates. > > > > > > > > > > Nonsense. > > > > > > > > > You could pass in the swap function, fair enough. That would have to take > > > > void pointers and cast them back to the appropriate types, so it would > > > > have to specially written. But it would work. > > > > > > in my opinion for normal coder c++ stl shit is out becouse of 'architectural' stupidity of that tthing...qsort is out becouse of being slow..simply take a pice of code i recently posted (mixed quickinsertsort) and go > > > > qsort is realy slow in my test it take 252 ms to sort 1e6 ints when this mixed quickinsertsort take 111 ms same as c++ std:sort (maybe 1 ms worse hard to see as it somewhat oscilates from run to run even on the identical input) > > > > i probably could beat this result (and thus std:sort) spending some hours on finding some improvements > > yet see info on sorting in other thread, and generally see, i repeat what i measured (i measure sorting 1e6 integers (positive from 0 to (2^24)-1 ) > > qsort - 252 ms > > my quicksort code snippet (this nice one) - 140 ms > > my quicksort + insert sort code snippet (provided) - 111.5 ms > > std:sort of c++ - 111 ms > > radix sort taken from some guy on stack - 27.5 ms for signed integers 26 ms for unsigned > > (you may delete 3.5 ms from all those values as its overhead of my time plots drawing system) > (more details:it was measured on 32 bin xp old core 2 ps compiled on gcc 2015 or 2016 only with -O2 flag as to optimisations) (i use this older for purpose) what does it mean in a contex of bulshitting bonita threads: it only means what you got in libraries or what yopu got not (or what you can write byself or what you cant), library my beat library but its a fight against libraries not languages not any way making c++ superior, nor making it less bloated, this is stup[id trash talk of lies (and c++ is inferior by stupidity of its design )
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-14 14:20 +0100 |
| Message-ID | <qvkf69$ltr$1@dont-email.me> |
| In reply to | #149069 |
On 14/01/2020 11:30, Malcolm McLean wrote: > On Monday, 13 January 2020 20:48:24 UTC, David Brown wrote: >> On 13/01/2020 18:35, Malcolm McLean wrote: >>> On Monday, 13 January 2020 14:19:59 UTC, David Brown wrote: >>>> >>>> So assuming a suitable compiler exists for your target, if you can do >>>> something in C you can do the same thing in C++. It is not going to be >>>> idiomatic C++, but it will work. >>>> >>> That's the point. >> >> It certainly is not the point you tried to make earlier - it is, in >> fact, the opposite. >> >>> We can write a "general purpose sort" in C using only >>> portable C code with no dependencies. >> >> Yes. And the same code will work in C++ - (almost) anything you can do >> in C, you can do equally well in C++ because you can use exactly the >> same code. >> >>> However if we move to C++, it is >>> no longer a general purpose sort. >> >> Of course it is a general purpose sort. That applies whether you mean >> taking the general purpose C sort and compiling it as C++, or if you >> mean writing a C++ template-style sort. >> > A general purpose sort sorts "pretty much anything". In C, that means arrays > of structures. The sort won't work for linked lists, or for structures which > contain pointers to internals, but those are comparatively rare. Basically, > if we want to sort something in C, we can use qsort(). > Now we move to C++. Obvioulsy if we simply make a few trivial changes to > the code to make it compatible with C++, then all our structs are what > C++ calls "PODs", or "plain old data types". But that's not idiomatic C++. Look back at my posts. Re-stating what I wrote does not make your original post correct, but it does show that you are beginning to understand the point. > If we are using C++< it is likely that the code will acumulate classes > and std::vectors. Ability to use such facilities is likely the reason we > moved to C++. So qsort is no longer a general purose sort. It won't sort > "almost anything", but only the legacy C arrays. >> >>> The C++ general purpose sort has to >>> be written with templates. >> >> Nonsense. >> > You could pass in the swap function, fair enough. That would have to take > void pointers and cast them back to the appropriate types, so it would > have to specially written. But it would work. > Yes, I know it would work. I also know it would not be idiomatic C++ (though it could be good in C).
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-12 02:21 -0800 |
| Message-ID | <82f6ef6e-7528-4833-b9bc-77cfdfb6838b@googlegroups.com> |
| In reply to | #148952 |
W dniu niedziela, 12 stycznia 2020 11:03:06 UTC+1 użytkownik Bonita Montero napisał: > >> In C you have to write a lot of boilerplate-code because the language > >> provides almost nothing. Look at the C++-containers; C provides not > >> even the simplest form of it, a string, as a natve type. > > > are you noob enough to not know libraries provide things? (you simply -l"libname") > > There's no library that helps handling strings like a native type > in C because C doesn't provide the base facilties like templates > and operator-overloading. > And look at even more advanced STL-classes like unordered_map. > You simply say std::unordered_map<key, value> and thereby specialize > unordered_map for certain types. Having the same performance through > specialization (boilerplate-code is magnitudes more common) in C is > at least a whole day's work. proove that there is something that dont allows you to use someting like void* a = CreateUnorderedMap(); UnorderedMapAddKey(a, "allala"); UnorderedMapAddValue(a, "ala"); //get your own style of names c gives you simple interface, it has some lacks but what it has to boilerplate ?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-12 12:50 +0100 |
| Message-ID | <qvf16c$1df$1@news.albasani.net> |
| In reply to | #148955 |
> void* a = CreateUnorderedMap(); > UnorderedMapAddKey(a, "allala"); > UnorderedMapAddValue(a, "ala"); > //get your own style of names And where do I get this function CreateUnorderedMap? In C++ it's in the STL and it can be specialized to certain types with just a line of code. In C I would have to do that on my own which takes at least a whole day. No one specializes algorithms for every datatype in C. Because of that you have algorithms like qsort, which are rather slow because of the shallow copying of the objects and the invocation of the comparison-function. There are other libraries which works similar in C like libavl. But they're not as fast as the STL's classes and algorithms, not typesafe and don't care about resource errors (in C++ you can f.e. throw an exception from a std::sort lamda). You have almost no real programming experience.
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web