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 193 — 20 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? 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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-13 09:16 +0100 |
| Message-ID | <qvh904$tr$1@dont-email.me> |
| In reply to | #148974 |
On 12/01/2020 14:21, Bart wrote: > On 12/01/2020 12:49, Bonita Montero wrote: >>> besides where is the bloat? ... >> >> The bloat is in C, where you have to write magnitudes >> more code for the same effect. > > And you had to write a bunch of incomprehensible code to implement > n-based arrays, which in the end was a very poor solution, requiring a > lot of effort by the compiler. > > But function-based solutions in C don't have that overhead because they > can be compiled separately. You can't do that with C++ templates. > 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++. If you want to say you find C++ code, especially template code, hard to write, hard to understand, and very hard to debug, that's fair enough. It's a matter of opinion, preferences, and experience. But don't say "you can do this in C but not in C++", because that's almost invariably factually inaccurate.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-01-13 04:28 -0800 |
| Message-ID | <d2146829-4608-461a-bd43-4696967e2a8b@googlegroups.com> |
| In reply to | #149015 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-13 13:36 +0100 |
| Message-ID | <qvho93$uoa$1@news.albasani.net> |
| In reply to | #149017 |
> 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. ... Most arrays could be sorted because they are move-constructible or move-assignable or copy-constructible or copy-assignable. Every class you could build from the STL-components has this capabilities.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-01-13 04:39 -0800 |
| Message-ID | <a9ac4f79-8626-4835-bb42-45f46d83c5ff@googlegroups.com> |
| In reply to | #149017 |
On Monday, 13 January 2020 14:28:14 UTC+2, 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. Note that the templated std::sort of C++ standard library tends to be about 25% faster than qsort in optimized builds. Also arrays of objects that already have operator< or specialization of std::less do not need special ordering predicates for sorting with std::sort (unlike qsort).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-13 15:22 +0100 |
| Message-ID | <qvhufr$opn$1@dont-email.me> |
| In reply to | #149019 |
On 13/01/2020 13:39, Öö Tiib wrote: > On Monday, 13 January 2020 14:28:14 UTC+2, 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. > > Note that the templated std::sort of C++ standard library tends to be > about 25% faster than qsort in optimized builds. Also arrays of objects > that already have operator< or specialization of std::less do not need > special ordering predicates for sorting with std::sort (unlike qsort). > I know that - but it is irrelevant to the point. Bart was (as far as I could see) under the impression that the use of C++ means you /must/ use templates, header libraries, etc., instead of the separately compiled function-based solutions he suggests in C. All I am saying is that such solutions are perfectly valid for C too (even though most C++ programmers will agree with you that template solutions are likely to be a better choice in many cases).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-13 05:10 -0800 |
| Message-ID | <ba4b142e-94aa-45c7-bde5-a9226e450bd3@googlegroups.com> |
| In reply to | #149017 |
On Monday, January 13, 2020 at 7:28:14 AM UTC-5, 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. qsort() relies on the equivalent of calls to memcpy() to move around the items it sorts. Any C-style struct would, if ported to C++, qualify as "trivially copyable" (3.9p9). "For any trivially copyable type T, if two pointers to T point to distinct T objects obj1 and obj2, where neither obj1 nor obj2 is a base- class subobject, if the underlying bytes (1.7) making up obj1 are copied into obj2, 43 obj2 shall subsequently hold the same value as obj1." (3.9p3). The "43" in that sentence is in superscript, and is reference to footnote 43, which says: "By using, for example, the library functions (17.6.1.2) std::memcpy or std::memmove.". For types that are not trivially copyable, qsort() most certainly should not be used, even if the types are copy-constructible, move-assignable or copy-assignable (Bonita's claims to the contrary notwithstanding), since qsort() will NOT make use of the copy constructor, the move constructor, or the copy assignment operator overload. However, if you simply port C code to C++, the result will never involve a struct type that isn't trivially copyable. Note that you can use C to produce structures that contain the same features that C++ classes have that make qsort() inappropriate. For example, a struct might contain pointers that are supposed to point into itself; copying such a struct from one place to another would require reassigning those pointers. In C++, you would take care of such things in one of those special member functions. In C, you'd have to write your own function to do such things, and making sure that it gets called when needed will be your responsibility, not the compiler's. And since qsort() would NOT call that function, that would make qsort() unusable for such types. But that means that the C code you started with before porting it to C++ would NOT contain any qsort() calls on such arrays.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-13 15:10 +0100 |
| Message-ID | <qvhto2$he5$1@news.albasani.net> |
| In reply to | #149021 |
> For types that are not trivially copyable, qsort() most certainly should > not be used, even if the types are copy-constructible, move-assignable > or copy-assignable (Bonita's claims to the contrary notwithstanding), > since qsort() will NOT make use of the copy constructor, ... I talked about std::sort and not qsort()! And std::sort uses std::swap to swap the elements which uses move-construction and move-assignment if possible. That's rather fast.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-13 07:31 -0800 |
| Message-ID | <8e548075-1b91-4858-9481-a87d2820e5e7@googlegroups.com> |
| In reply to | #149022 |
Bonita Moreno wrote: > [Missing attribution to Malcolm McLean] > > 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. ... > > Most arrays could be sorted because they are move-constructible or > move-assignable or copy-constructible or copy-assignable. Every class > you could build from the STL-components has this capabilities. Later, Bonita Moreno wrote: > [missing attribution to James Kuyper] > > For types that are not trivially copyable, qsort() most certainly should > > not be used, even if the types are copy-constructible, move-assignable > > or copy-assignable (Bonita's claims to the contrary notwithstanding), > > since qsort() will NOT make use of the copy constructor, ... > > I talked about std::sort and not qsort()! No, you did not. You didn't mention std::sort() at all. As part of a sub-thread talking, in general, about the feasibility (not the desirability) of continuing to do things the C way in C++, and in particular about qsort(), all you mentioned was "sorting". You didn't specify any particular method for sorting. In such a context, the clear (and incorrect) meaning of what you wrote (as opposed to what you might have intended to write) was that your comments were applicable to sorting using qsort(). If they wasn't your intent, your comments weren't particularly relevant to the message you were nominally responding to. std::sort is an example of precisely the kind of templates sorting function he was talking about.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-13 16:34 +0100 |
| Message-ID | <qvi2mo$3rf$2@news.albasani.net> |
| In reply to | #149028 |
>> I talked about std::sort and not qsort()! > No, you did not. You didn't mention std::sort() at all. ... When I'm taking about sorting and all this kind of constructors and moving it's clear from the context that I'm talking about std::sort.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-13 06:59 -0800 |
| Message-ID | <2d7c0559-4b8d-4ef3-bbbf-ce6d076a0734@googlegroups.com> |
| In reply to | #149021 |
W dniu poniedziałek, 13 stycznia 2020 14:10:24 UTC+1 użytkownik James Kuyper napisał:
> On Monday, January 13, 2020 at 7:28:14 AM UTC-5, 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.
>
> qsort() relies on the equivalent of calls to memcpy() to move around the
> items it sorts. Any C-style struct would, if ported to C++, qualify as
> "trivially copyable" (3.9p9).
> "For any trivially copyable type T, if two pointers to T point to
> distinct T objects obj1 and obj2, where neither obj1 nor obj2 is a base-
> class subobject, if the underlying bytes (1.7) making up obj1 are copied
> into obj2, 43 obj2 shall subsequently hold the same value as obj1."
> (3.9p3).
>
> The "43" in that sentence is in superscript, and is reference to
> footnote 43, which says: "By using, for example, the library functions
> (17.6.1.2) std::memcpy or std::memmove.".
>
> For types that are not trivially copyable, qsort() most certainly should
> not be used, even if the types are copy-constructible, move-assignable
> or copy-assignable (Bonita's claims to the contrary notwithstanding),
> since qsort() will NOT make use of the copy constructor, the move
> constructor, or the copy assignment operator overload. However, if you
> simply port C code to C++, the result will never involve a struct type
> that isn't trivially copyable.
>
> Note that you can use C to produce structures that contain the same
> features that C++ classes have that make qsort() inappropriate. For
> example, a struct might contain pointers that are supposed to point into
> itself; copying such a struct from one place to another would require
> reassigning those pointers. In C++, you would take care of such things
> in one of those special member functions. In C, you'd have to write your
> own function to do such things, and making sure that it gets called when
> needed will be your responsibility, not the compiler's. And since
> qsort() would NOT call that function, that would make qsort() unusable
> for such types. But that means that the C code you started with before
> porting it to C++ would NOT contain any qsort() calls on such arrays.
well talking of that constructors is typical for c++ mess over something that in ca has about five lines of c
inline void swap(int* a, int* b) { int t = *a; *a=*b; *b=t; }
inline int SwipePartition (int* table, int lo, int hi) //seem to work
{
int pivot = table[(lo+hi)/2];
int i = lo-1;
int j = hi+1;
for(;;) {
do i++; while (table[i] < pivot);
do j--; while (table[j] > pivot);
if(i>=j) return j;
swap(&table[i], &table[j]);
}
}
void QuickSort(int* table, int lo, int hi)
{
if (lo < hi) {
int pivot_point = SwipePartition(table, lo, hi);
QuickSort(table, lo, pivot_point);
QuickSort(table, pivot_point + 1, hi);
}
}
hovever in my sickle.c sources i got other routine for sorting chunks, it is
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)
it also illustrates what i also mean when i say c is not bloat, this is simpel meat /core of things, unlike c++ trash when you talk on idiotic templates constructors and rest of this idiotic bloat
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-13 16:32 +0100 |
| Message-ID | <qvi2ij$3rf$1@news.albasani.net> |
| In reply to | #149027 |
Look at this comparison of std::sort and qsort():
#include <iostream>
#include <vector>
#include <algorithm>
#include <random>
#include <chrono>
#include <cstdlib>
using namespace std;
using namespace chrono;
size_t const N_ELEMENTS = 1'000'000;
double cppBenchmark()
{
mt19937_64 rg;
uniform_int_distribution<size_t> uidViSize( 1, 8 );
uniform_int_distribution<int> uidVi( 0, 10 );
vector<vector<int>> vvi;
vvi.reserve( N_ELEMENTS );
for( size_t i = 0; i != N_ELEMENTS; ++i )
{
vector<int> vi( uidViSize( rg ) );
for( size_t j = 0; j != vi.size(); ++j )
vi[j] = uidVi( rg );
vvi.emplace_back( vi );
}
time_point<high_resolution_clock> start = high_resolution_clock::now();
sort( vvi.begin(), vvi.end(),
[]( vector<int> &left, vector<int> &right ) -> bool
{
bool leftShorter = left.size() < right.size();
size_t shorterSize = leftShorter ? left.size() :
right.size();
for( size_t i = 0; i != shorterSize; ++i )
if( left[i] == right[i] )
continue;
else
return left[i] < right[i];
return leftShorter;
} );
return (double)duration_cast<nanoseconds>(
high_resolution_clock::now() - start ).count();;
}
#if defined(_MSC_VER)
#pragma warning(disable: 26451)
#endif
struct vec
{
int *begin;
size_t size;
};
int cComp( const void *left, const void *right )
{
vec *viLeft = (vec *)left,
*viRight = (vec *)right;
int shorter = viLeft->size < viRight->size ? -1 :
viRight->size < viLeft->size ? 1 : 0;
size_t shorterSize = shorter == -1 ? viLeft->size : viRight->size;
for( size_t i = 0; i != shorterSize; ++i )
if( viLeft->begin[i] == viRight->begin[i] )
continue;
else
if( viLeft->begin[i] < viRight->begin[i] )
return -1;
else
return 1;
return shorter;
}
double cBenchmark()
{
vec *vvi;
if( !(vvi = (vec *)malloc( N_ELEMENTS * sizeof(vec) )) )
return -1;
double ns = -1;
time_point<high_resolution_clock> start;
size_t vviEnd = 0;
for( vviEnd = 0; vviEnd != N_ELEMENTS; ++vviEnd )
{
size_t size = 1 + rand() % 8;
int *begin;
if( !(begin = (int *)malloc( size * sizeof(int) )) )
goto destruct;
vvi[vviEnd].begin = begin;
vvi[vviEnd].size = size;
for( size_t i = 0; i != size; ++i )
begin[i] = rand() % 11;
}
start = high_resolution_clock::now();
qsort( vvi, N_ELEMENTS, sizeof(vec), cComp );
ns = (double)duration_cast<nanoseconds>(
high_resolution_clock::now() - start ).count();;
destruct:
while( vviEnd > 0 )
free( vvi[--vviEnd].begin );
free( vvi );
return ns;
}
int main()
{
double ns;
ns = cppBenchmark();
cout << ns / 1.0e6 << "ms" << endl;
ns = cBenchmark();
cout << ns / 1.0e6 << "ms" << endl;
}
The C++-algorithm is 29 lines, the C-algorithm is 45 lines.
The C++-algorihm is about 48% faster on my computer (1800X).
The C++-algorithm is much more readable.
The C++-algorithm has clean error-handling though exceptions
whereas in C I would have to rely on ugly return-codes.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-13 17:17 +0100 |
| Message-ID | <qvi566$tvb$1@news.albasani.net> |
| In reply to | #149029 |
> double cppBenchmark()
> {
> mt19937_64 rg;
> uniform_int_distribution<size_t> uidViSize( 1, 8 );
> uniform_int_distribution<int> uidVi( 0, 10 );
> vector<vector<int>> vvi;
> vvi.reserve( N_ELEMENTS );
> for( size_t i = 0; i != N_ELEMENTS; ++i )
> {
> vector<int> vi( uidViSize( rg ) );
> for( size_t j = 0; j != vi.size(); ++j )
> vi[j] = uidVi( rg );
> vvi.emplace_back( vi );
vvi.emplace_back( (move( vi ) );
> }
> time_point<high_resolution_clock> start =
> high_resolution_clock::now();
> sort( vvi.begin(), vvi.end(),
> []( vector<int> &left, vector<int> &right ) -> bool
> {
> bool leftShorter = left.size() < right.size();
> size_t shorterSize = leftShorter ? left.size() :
> right.size();
> for( size_t i = 0; i != shorterSize; ++i )
> if( left[i] == right[i] )
> continue;
> else
> return left[i] < right[i];
> return leftShorter;
> } );
> return (double)duration_cast<nanoseconds>(
> high_resolution_clock::now() - start ).count();;
> }
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-13 18:13 +0100 |
| Message-ID | <qvi8et$r7d$1@news.albasani.net> |
| In reply to | #149029 |
> sort( vvi.begin(), vvi.end(),
And with this ...
sort( execution::parallel_policy(), vvi.begin(), vvi.end(),
... all cores are fully exploited in the system - with a change in 10s.
In C that's a day's work.
> []( vector<int> &left, vector<int> &right ) -> bool
> {
> bool leftShorter = left.size() < right.size();
> size_t shorterSize = leftShorter ? left.size() :
> right.size();
> for( size_t i = 0; i != shorterSize; ++i )
> if( left[i] == right[i] )
> continue;
> else
> return left[i] < right[i];
> return leftShorter;
> } );
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-13 09:19 -0800 |
| Message-ID | <dcf23d6f-cebd-49ae-a85c-0b4c97ee4067@googlegroups.com> |
| In reply to | #149035 |
W dniu poniedziałek, 13 stycznia 2020 18:13:10 UTC+1 użytkownik Bonita Montero napisał: > > sort( vvi.begin(), vvi.end(), > > And with this ... > sort( execution::parallel_policy(), vvi.begin(), vvi.end(), > ... all cores are fully exploited in the system - with a change in 10s. > In C that's a day's work. > in c as in c++ you got this in library or not, so maybe cut down that pathological stupidity propagation (as it depends on libraries not languages)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-13 18:22 +0100 |
| Message-ID | <qvi90e$jqm$1@news.albasani.net> |
| In reply to | #149036 |
>>> sort( vvi.begin(), vvi.end(), >> >> And with this ... >> sort( execution::parallel_policy(), vvi.begin(), vvi.end(), >> ... all cores are fully exploited in the system - with a change in 10s. >> In C that's a day's work. > in c as in c++ you got this in library or not, so maybe cut down that pathological stupidity propagation (as it depends on libraries not languages) There are a lot of library-fuctions in C++ for things which are used very often; in C there's nothing comparable.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-13 09:29 -0800 |
| Message-ID | <35ce5464-13ec-4840-9e99-df82d8931b4d@googlegroups.com> |
| In reply to | #149037 |
W dniu poniedziałek, 13 stycznia 2020 18:22:35 UTC+1 użytkownik Bonita Montero napisał: > >>> sort( vvi.begin(), vvi.end(), > >> > >> And with this ... > >> sort( execution::parallel_policy(), vvi.begin(), vvi.end(), > >> ... all cores are fully exploited in the system - with a change in 10s. > >> In C that's a day's work. > > > in c as in c++ you got this in library or not, so maybe cut down that pathological stupidity propagation (as it depends on libraries not languages) > > There are a lot of library-fuctions in C++ for things which are > used very often; in C there's nothing comparable. what is the source of this informations, do you know thet there are real big thousands of libraries for c? do you know them all? besides if you compare c++ libraries against c libraries say so and dont say that c++ languiege is better when you compare libraries at it is animal stupidity propagation
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-13 18:34 +0100 |
| Message-ID | <qvi9o0$idv$1@news.albasani.net> |
| In reply to | #149038 |
>> There are a lot of library-fuctions in C++ for things which are >> used very often; in C there's nothing comparable. > what is the source of this informations, do you know thet there are real big thousands of libraries for c? do you know them all? Show me a library that has the same semantics as qsort() but is fully parallelized. > besides if you compare c++ libraries against c libraries say so and dont say that c++ languiege is better when you compare libraries at it is animal stupidity propagation C++ is simply by magnitudes more powerful. The larger the project, the higher the advantages over bare C. Consider strings: C hasn't even a string-datatype. In C++ you have basic_string which is specialized through different variants for char, wchar_t, char16_t, char32_t .... And you can write your own collation sequences for your own specialization. Everything beyond that is already in the lib and comes for free. You have to manage your vectors by yourself doing malloc() over and over; that's plainly idiotic. And you have to manage resource -errors like malloc()-nulls by yourself. In C++ that's for free and you just have to catch your exceptions in a central place.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-13 09:40 -0800 |
| Message-ID | <0d468e9a-acda-4a1c-9cbd-8a668c95685e@googlegroups.com> |
| In reply to | #149039 |
W dniu poniedziałek, 13 stycznia 2020 18:35:06 UTC+1 użytkownik Bonita Montero napisał: > >> There are a lot of library-fuctions in C++ for things which are > >> used very often; in C there's nothing comparable. > > > what is the source of this informations, do you know thet there are real big thousands of libraries for c? do you know them all? > > Show me a library that has the same semantics as qsort() but is fully > parallelized. > google it, i dont know all the libraries in the world - unlike you who seems to be sure that there is no such libraray which in turn is silly (i never needed that so i didnt used it) > > besides if you compare c++ libraries against c libraries say so and dont say that c++ languiege is better when you compare libraries at it is animal stupidity propagation > > C++ is simply by magnitudes more powerful. > The larger the project, the higher the advantages over bare C. > Consider strings: C hasn't even a string-datatype. In C++ you have > basic_string which is specialized through different variants for > char, wchar_t, char16_t, char32_t .... And you can write your own > collation sequences for your own specialization. Everything beyond > that is already in the lib and comes for free. > You have to manage your vectors by yourself doing malloc() over > and over; that's plainly idiotic. And you have to manage resource > -errors like malloc()-nulls by yourself. In C++ that's for free > and you just have to catch your exceptions in a central place. bullshit again..
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-13 18:42 +0100 |
| Message-ID | <qvia6l$gsm$1@news.albasani.net> |
| In reply to | #149041 |
> google it, i dont know all the libraries in the world - unlike you who seems to be sure that there is no such libraray which in turn is silly > (i never needed that so i didnt used it) I've googled, and there's nothing generic. >> C++ is simply by magnitudes more powerful. >> The larger the project, the higher the advantages over bare C. >> Consider strings: C hasn't even a string-datatype. In C++ you have >> basic_string which is specialized through different variants for >> char, wchar_t, char16_t, char32_t .... And you can write your own >> collation sequences for your own specialization. Everything beyond >> that is already in the lib and comes for free. >> You have to manage your vectors by yourself doing malloc() over >> and over; that's plainly idiotic. And you have to manage resource >> -errors like malloc()-nulls by yourself. In C++ that's for free >> and you just have to catch your exceptions in a central place. > bullshit again.. Strong argumentation !
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-13 09:56 -0800 |
| Message-ID | <72f80448-7dac-46ae-95c5-039cf68c8a94@googlegroups.com> |
| In reply to | #149042 |
W dniu poniedziałek, 13 stycznia 2020 18:42:54 UTC+1 użytkownik Bonita Montero napisał: > > google it, i dont know all the libraries in the world - unlike you who seems to be sure that there is no such libraray which in turn is silly > > (i never needed that so i didnt used it) > > I've googled, and there's nothing generic. > generic is c++ word as far as i understood what i mean are you stupid enough dont knowing it, in c you write specific which obviously beat generic (being specific it can be extremly hacky and efficient) > >> C++ is simply by magnitudes more powerful. > >> The larger the project, the higher the advantages over bare C. > >> Consider strings: C hasn't even a string-datatype. In C++ you have > >> basic_string which is specialized through different variants for > >> char, wchar_t, char16_t, char32_t .... And you can write your own > >> collation sequences for your own specialization. Everything beyond > >> that is already in the lib and comes for free. > >> You have to manage your vectors by yourself doing malloc() over > >> and over; that's plainly idiotic. And you have to manage resource > >> -errors like malloc()-nulls by yourself. In C++ that's for free > >> and you just have to catch your exceptions in a central place. > > > bullshit again.. > > Strong argumentation ! do you think i want to teach you how to do string related work in c? if you criticize it it seems you should know that, but you dont know so bulshit detected and you should get back to learn and stop spreading lies on usenet (i may inform you how i do strings in c shortly, only to inform you i know what i sayin i will not waste my time to teach bulshit talkers good things: 1) in programming you mostly dont need a strings that are resizable and modificable, mostly you need what i call sometimes as labels - thsioe are fixed strings placed in inmutable ram .. in 99% cases like you would write game and need to print out communicates you use ionly that labels dont need to use crappy idea of strings at all 2) if you want to modify strings and work on teht it very often shows you also dont need to modify a strings at all, even though you need cooked output of mixed strings...mostly you only mark some pices you need using pointers on input marking input pieces you need then flush it to the output for example using printfs..thus you also avoid crap idea of mutalbe string at all 3) in extreme rare cases when you need to generate output string in ram not on output ypu may allocate array and generate into it c++ obviously as language for dumb people uses string.;.then you go to repeat that common bulshit of extremally lame shameless coders (yuck)
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web