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 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-13 19:19 +0100 |
| Message-ID | <qvican$dbh$1@news.albasani.net> |
| In reply to | #149043 |
> 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) No, hand-specialized code isn't faster than generically specialized > 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 You have too much phantasy which is feeded by your limited experiences. > c++ obviously as language for dumb people uses string.;.then you go to repeat that common bulshit of extremally lame shameless coders (yuck) C++ is a language for people who want to have fast and maintainable code with a magnitude less development-time as in C.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-13 10:21 -0800 |
| Message-ID | <dd4ace6a-4cfd-423b-8952-3ec3197903f9@googlegroups.com> |
| In reply to | #149044 |
W dniu poniedziałek, 13 stycznia 2020 19:19:11 UTC+1 użytkownik Bonita Montero napisał: > > 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) > > > No, hand-specialized code isn't faster than generically specialized > > > > 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 > > You have too much phantasy which is feeded by your limited experiences. > > > c++ obviously as language for dumb people uses string.;.then you go to repeat that common bulshit of extremally lame shameless coders (yuck) > > C++ is a language for people who want to have fast and maintainable code > with a magnitude less development-time as in C. ok anough of this stupidity, keep out shameles bulshitter
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-13 19:25 +0100 |
| Message-ID | <qvicmo$bko$1@news.albasani.net> |
| In reply to | #149045 |
You're just an unexperienced programmer with a limited horizon.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-13 10:46 -0800 |
| Message-ID | <c69baf3d-3490-460f-9cf3-5669e7fc96d7@googlegroups.com> |
| In reply to | #149046 |
W dniu poniedziałek, 13 stycznia 2020 19:25:36 UTC+1 użytkownik Bonita Montero napisał: > You're just an unexperienced programmer with a limited horizon. youre sentences repeater prof on proper bulshit validation - just like dik hodgin
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-13 08:02 -0800 |
| Message-ID | <58269117-e1f0-4e7e-a300-16e465027d8d@googlegroups.com> |
| In reply to | #149027 |
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
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-15 01:04 -0800 |
| Message-ID | <b277f715-b4f6-4a64-8b67-5ad0847b8a4d@googlegroups.com> |
| In reply to | #149031 |
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
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-15 01:25 -0800 |
| Message-ID | <cf1c97b9-f561-40a7-a34b-81ae5038d9c4@googlegroups.com> |
| In reply to | #149113 |
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]++;
}
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
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-15 06:37 -0800 |
| Message-ID | <82c42fe1-1645-4a1e-afd6-fd1393542d0b@googlegroups.com> |
| In reply to | #149114 |
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
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-15 10:49 -0800 |
| Message-ID | <80e7c5ce-cf5f-4f9d-b23a-a7b803e13718@googlegroups.com> |
| In reply to | #149129 |
hovever i could also add it might and probably will allow to write also less eficient code, i think its becouse in c procedural way this is hard to write uneficient code becouse you simplt write the task to be done and you write it efficiently with this hipermodules one i think might project this module to give efect in various ways and it seems to me that its easier to provide that modules who will do things unefficiently (like counting something that then will be abandoned or not used, then recounting it on another call and things like that) i got not much to say on it speciffialy but it seems that things might do appear (hovever this is obviously to be tamed )
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-02-04 01:15 -0800 |
| Message-ID | <6797c24c-735a-4932-8196-00a799917ad8@googlegroups.com> |
| In reply to | #149129 |
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
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2020-02-04 01:48 -0800 |
| Message-ID | <chine.bleu-4FD172.01480104022020@reader.eternal-september.org> |
| In reply to | #149716 |
int c0[42]; int ours = c0-11; // ours goes from 11, ours[11]. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ The first law of discordiamism: The more energy This post / \ to make order is nore energy made into entropy. insults Islam. Mohammed
[toc] | [prev] | [next] | [standalone]
| 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]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web