Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #380602 > unrolled thread
| Started by | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2024-01-22 01:51 +0000 |
| Last post | 2024-01-25 15:02 +0100 |
| Articles | 20 on this page of 649 — 20 participants |
Back to article view | Back to comp.lang.c
iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 01:51 +0000
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-22 02:00 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 21:48 -0500
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 05:23 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-22 09:30 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-22 16:24 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 20:34 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-22 13:22 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 22:07 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-22 14:56 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 23:44 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 00:10 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 20:34 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-22 21:32 +0000
Re: iso646.h Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-22 23:08 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 23:37 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 00:12 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-23 06:54 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 06:05 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:34 +0100
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 15:43 +0000
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-22 20:23 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-23 06:47 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 21:50 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 08:59 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-23 09:24 +0100
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 21:30 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-23 22:03 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 08:53 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 07:58 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:11 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 12:23 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-24 21:55 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 07:22 +0100
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-24 20:25 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 00:17 +0000
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-25 00:50 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 01:23 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 18:30 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-25 01:33 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 21:20 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 16:56 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 18:07 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 18:12 +0100
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 21:08 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-24 10:03 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-23 11:54 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-23 16:32 +0000
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-23 17:21 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 21:49 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 21:52 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 14:51 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 23:33 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 16:16 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 00:39 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-24 11:53 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:15 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:02 +0100
C/CPP macro conventions (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 08:25 +0100
Re: C/CPP macro conventions (was Re: iso646.h) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 08:25 +0000
Re: C/CPP macro conventions (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 10:09 +0100
Re: C/CPP macro conventions (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-24 10:13 +0100
Re: C/CPP macro conventions (was Re: iso646.h) Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-25 23:05 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-23 18:34 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-23 18:52 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-23 14:23 -0500
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 20:32 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 21:52 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 22:09 +0000
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 22:37 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:10 +0100
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-24 12:24 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 18:38 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 18:42 +0100
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-24 17:49 +0000
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-24 18:40 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:15 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-24 22:01 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 11:52 -0800
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-24 20:03 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:14 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 21:11 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-25 00:01 -0500
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 13:43 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 14:19 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 15:20 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 16:40 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-25 13:43 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 16:11 +0100
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-03 11:35 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:09 +0100
Unix shell conditionals (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 08:38 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-23 21:28 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 22:00 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-23 22:33 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 23:46 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 14:49 -0800
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-23 19:45 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:28 +0100
Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 19:32 +0000
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-23 19:59 +0000
Re: Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 20:18 +0000
Re: Python (Re: iso646.h) Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2024-01-24 07:49 -0700
Re: Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-24 15:07 +0000
Re: Python (Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-24 15:17 +0000
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-24 15:46 +0000
Re: Python (Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-24 16:27 +0000
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-24 19:55 +0000
Re: Python (Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-24 20:57 +0000
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:17 +0000
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-25 12:13 +0000
Re: Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-25 14:57 +0000
Re: Python (Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-25 16:17 +0100
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-25 15:52 +0000
Re: Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-25 16:14 +0000
Re: Python (Re: iso646.h) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 11:27 -0800
Re: Python (Re: iso646.h) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 18:06 +0000
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-25 19:35 +0000
Re: Python (Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 15:56 +0000
Re: Python (Re: iso646.h) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 12:09 -0800
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 22:00 +0000
Re: Python (Re: iso646.h) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-01-27 22:12 +0000
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 00:29 +0000
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 21:55 +0000
Re: Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 22:47 +0000
Re: Python (Re: iso646.h) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 15:35 -0800
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 00:41 +0000
Re: Python (Re: iso646.h) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 03:13 +0000
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 23:37 +0000
Re: Python (Re: iso646.h) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-26 05:48 -0800
Re: Python (Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-01-23 23:51 +0000
Re: Python (Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-23 16:35 -0800
Re: Python (Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-23 16:40 -0800
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-24 00:06 +0000
Re: Python (Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-24 12:37 +0100
Re: Python (Re: iso646.h) Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-25 22:55 +0000
Re: Python (Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-24 13:30 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 12:13 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 22:01 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-23 22:45 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 23:39 +0000
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 22:54 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 15:10 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 23:40 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 16:27 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 00:47 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 17:32 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 02:42 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-23 23:56 -0500
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 05:24 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 21:43 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 06:35 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-24 14:14 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:19 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 07:34 -0800
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-23 23:26 -0500
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 20:53 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:41 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 08:15 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 19:32 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:06 +0100
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-24 14:17 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 08:30 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 21:00 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 22:13 +0000
Re: COBOL (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 00:44 +0000
Re: COBOL (was Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-01-25 01:37 +0000
Re: COBOL (was Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-25 02:20 +0000
Re: COBOL (was Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 18:23 -0800
Re: COBOL (was Re: iso646.h) bart <bc@freeuk.com> - 2024-01-25 11:58 +0000
Re: COBOL (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 02:49 +0000
Re: COBOL (was Re: iso646.h) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 19:09 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 17:44 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 17:27 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:21 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 12:26 -0800
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-24 20:31 +0000
Re: COBOL (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 00:53 +0000
Re: COBOL (was Re: iso646.h) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 01:24 +0000
Re: COBOL (was Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 18:21 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 22:09 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 23:20 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 15:56 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-24 12:20 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-24 13:00 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 14:22 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-24 14:54 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 08:27 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 20:50 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 14:01 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-25 13:53 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 16:48 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 09:57 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 21:07 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 20:18 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 15:59 +0100
Re: Compose Key (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-26 21:22 +0000
Re: Compose Key (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-27 16:17 +0100
Re: Compose Key (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 21:28 +0000
Re: Compose Key (was Re: iso646.h) Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-27 22:38 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 20:08 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-25 20:30 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 21:13 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 20:06 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 21:04 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-25 21:16 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 22:01 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 02:11 +0100
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-26 01:19 +0000
Operators (Algol 68) (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 02:08 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-25 00:52 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 17:07 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 07:48 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 14:07 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 14:35 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 16:53 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 17:11 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 21:11 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 02:21 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 17:01 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 18:31 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 19:59 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-26 12:27 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 22:01 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 22:30 +0100
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-26 20:22 -0500
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 16:43 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 20:14 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 14:09 +0100
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-26 20:10 -0500
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 16:44 +0100
Re: Functional Programming (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 20:49 +0000
Re: Functional Programming (was Re: iso646.h) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 00:22 +0000
Re: Functional Programming (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 01:18 +0000
Re: Functional Programming (was Re: iso646.h) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 02:06 +0000
Re: Functional Programming (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-28 12:35 +0100
Re: Functional Programming (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 20:40 +0000
Re: Functional Programming (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-29 09:52 +0100
Re: Functional Programming (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 05:13 +0000
Re: Functional Programming (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-02-02 09:21 +0100
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-28 01:31 -0500
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 12:40 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-26 21:16 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 22:46 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-26 22:41 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-26 15:41 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-26 23:51 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 01:17 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-27 16:25 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 18:46 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-26 23:52 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 01:27 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 00:38 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 11:09 +0100
Re: Localization (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 20:58 +0000
Re: Localization (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 15:57 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 16:58 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-27 17:26 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 18:53 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-27 19:39 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 17:31 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 12:50 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 20:59 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 17:34 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 01:50 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 17:53 -0800
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-27 18:47 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 12:53 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 20:43 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-28 14:49 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-29 00:03 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-29 01:24 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-28 17:48 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-29 02:17 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 17:06 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 17:05 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-29 23:56 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 13:35 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-29 16:23 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 18:40 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 16:33 -0800
Re: iso646.h bart <bc@freeuk.com> - 2024-01-27 00:42 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 03:16 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-27 17:24 +0000
Re: Java (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 21:04 +0000
[OT] Re: Java (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 17:42 +0100
Re: [OT] Re: Java (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 20:44 +0000
[OT] Usefulness of OO/C++/features (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 17:18 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 03:11 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 03:24 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 11:43 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 11:13 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 12:53 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 20:17 +0000
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-27 21:40 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 00:31 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 18:22 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 22:55 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-28 15:00 -0800
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-29 12:09 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-29 19:33 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-29 12:48 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-29 23:51 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-29 12:10 -0500
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-29 12:53 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 21:06 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 00:35 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 01:22 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 17:26 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 01:59 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 13:00 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 16:09 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 18:06 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 19:24 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 19:49 +0000
Re: Binary Pipelines (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 20:48 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-28 14:54 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 17:18 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-29 18:47 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 21:06 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-29 13:00 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 18:29 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 20:23 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-30 12:06 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 21:04 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:04 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 08:59 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 12:53 +0200
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 14:21 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 14:02 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 14:05 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 14:35 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 11:30 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 18:35 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 22:41 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 01:59 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-29 23:55 +0000
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-29 12:10 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-29 22:14 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-29 22:24 +0000
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-29 23:27 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 09:13 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 14:03 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 15:49 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 16:06 +0000
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-30 16:12 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 16:33 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 16:54 +0000
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-30 19:39 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:12 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-31 01:39 -0500
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:20 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 14:47 +0100
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-31 19:43 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 12:14 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-31 20:25 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 13:26 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-01 01:23 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 01:34 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-01 16:28 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 23:25 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 15:34 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 01:58 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 18:27 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 14:52 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 16:01 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 01:13 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 02:15 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 05:08 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 15:28 +0000
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-02 16:50 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-01 00:52 -0500
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-01 00:45 -0500
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 17:25 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 16:55 +0000
Creation era of stdin, stdout, stderr (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-30 19:06 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 20:29 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-30 20:24 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-30 12:55 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 21:42 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:10 +0000
Re: iso646.h dave_thompson_2@comcast.net - 2024-02-26 04:20 -0500
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 17:34 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 18:43 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-30 20:54 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:07 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 14:45 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:20 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 08:38 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 19:05 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 00:08 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 02:10 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 02:12 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 03:42 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 03:47 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 20:02 -0800
Re: iso646.h dave_thompson_2@comcast.net - 2024-02-26 04:18 -0500
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 15:00 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 15:21 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 15:53 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:03 +0000
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 15:28 +0200
Re: iso646.h bart <bc@freeuk.com> - 2024-01-30 15:30 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 15:54 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-30 16:10 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 17:49 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-30 18:22 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 18:44 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 20:46 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 12:22 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 14:58 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 15:39 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 18:39 +0000
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-30 19:45 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-30 11:59 -0800
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-30 16:16 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 12:35 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 15:09 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 15:46 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 19:11 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 10:35 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 11:34 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 17:24 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 22:46 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:29 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 08:41 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 17:06 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:00 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:15 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-30 11:50 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:02 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 12:43 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 13:58 +0200
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 13:35 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 15:10 +0200
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 18:19 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 19:53 +0200
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:49 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:17 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-31 11:20 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 18:06 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:52 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 08:30 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:16 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:06 +0000
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-30 23:18 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 08:36 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 15:21 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:22 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 19:15 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 16:25 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:58 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 17:17 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 17:05 +0000
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 18:26 +0200
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 18:27 +0200
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 19:01 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 19:24 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 02:18 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 19:20 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 02:48 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 07:16 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 13:17 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 16:04 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 08:33 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 23:48 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 16:49 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 01:10 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 17:36 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 02:23 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 18:30 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 00:49 +0000
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-01 05:24 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 15:07 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 12:18 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 23:57 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 13:34 +0100
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-03 11:27 -0800
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 12:43 +0200
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 12:15 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 13:49 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 17:03 +0200
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:49 +0000
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 18:04 +0200
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 16:54 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 09:16 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 17:21 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 15:53 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 17:29 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 19:36 +0200
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 19:47 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:25 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 16:33 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 17:42 +0200
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:58 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 17:05 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 18:18 +0200
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 17:47 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 17:20 +0000
[OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 20:11 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 19:28 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 13:12 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) bart <bc@freeuk.com> - 2024-02-01 12:50 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 04:57 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 07:18 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-03 01:44 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-02-02 09:34 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) bart <bc@freeuk.com> - 2024-02-02 10:57 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-03 01:43 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 12:47 -0800
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-04 22:36 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 15:26 -0800
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-05 01:49 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 18:08 -0800
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 15:04 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 16:16 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-31 20:16 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Michael S <already5chosen@yahoo.com> - 2024-01-31 22:22 +0200
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 20:50 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Michael S <already5chosen@yahoo.com> - 2024-01-31 23:00 +0200
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-31 21:20 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 13:27 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 13:16 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-02-01 13:21 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-02-01 11:45 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 13:03 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 04:58 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-01 05:22 -0800
[meta] Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 15:38 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 05:00 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 19:22 +0100
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-01 05:17 -0800
Re: Alternative Shells (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 05:04 +0000
Re: iso646.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-01-31 23:36 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 00:21 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 00:47 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 01:29 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 14:42 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 15:50 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 17:06 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 23:02 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 22:56 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 03:13 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-02 09:44 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 01:08 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 15:35 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 15:32 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 12:23 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 03:26 +0100
Re: iso646.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-02 23:41 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 01:53 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 14:45 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 14:57 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 16:47 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 16:22 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 15:55 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 15:41 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 17:15 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 19:36 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-01 19:50 +0000
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-01 20:03 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 23:06 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 22:38 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-02 09:51 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 13:28 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-02 15:47 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 15:38 +0000
Re: iso646.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-02 23:38 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-02 23:59 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 05:24 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 14:02 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 13:26 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 16:07 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 15:50 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 16:30 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 18:03 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 12:09 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 20:59 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 21:25 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-01 13:34 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 22:25 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-01 14:40 -0800
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 15:31 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 22:24 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 12:41 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-02 08:39 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 12:33 +0100
Re: iso646.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-02 21:40 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 05:14 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 16:48 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 16:19 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 14:53 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 18:02 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-24 19:33 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 19:45 +0000
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-24 19:48 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 00:30 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-25 03:56 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 05:25 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 07:02 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 14:46 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 14:29 +0100
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-25 15:08 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-25 16:18 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 11:20 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-26 12:17 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-26 07:56 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-26 23:03 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 17:06 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 18:59 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 20:18 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-26 23:15 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-26 15:55 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 17:07 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 17:34 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 13:02 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 01:12 +0100
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-26 20:43 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 11:21 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 03:05 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 11:34 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 11:02 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 12:36 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-29 18:32 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 19:48 +0100
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-29 19:35 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 21:10 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-29 22:27 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 10:05 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 17:46 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 20:16 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 17:20 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 10:48 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 21:51 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-24 19:48 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 19:52 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 13:00 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 00:26 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 01:25 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 12:09 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-25 03:46 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 19:59 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 05:39 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-25 09:55 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 15:19 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 07:26 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 17:12 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-25 16:22 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 15:02 +0100
Page 12 of 33 — ← Prev page 1 … 10 11 [12] 13 14 … 33 Next page →
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-26 18:31 +0100 |
| Message-ID | <up0qad$2v1n8$1@dont-email.me> |
| In reply to | #380995 |
All what you wrote below targets at your last sentense "those side-effects could be executed in any order". For the examples we had, like (informally) cout<<a<<b<<c; this is undisputed for the SIDE EFFECTS of "a", etc. You had "hidden" those side effects in "one()", I gave in an earlier post the more obvious example c++ in the context of cout << c++ << c++ << c++ << endl; as side effects. All side effects can be a problem (and should be avoided unless "necessary"). My point was that the order of '<<' with its arguments is NOT corrupted. I interpreted your previous posting that you'd have heard that to be an issue. If you haven't meant to say that there's nothing more to say about the issue, since the other things you filled your post with is only distracting from the point in question. Janis On 26.01.2024 17:01, David Brown wrote: > On 26/01/2024 02:21, Janis Papanagnou wrote: >> On 25.01.2024 21:11, David Brown wrote: >>> On 25/01/2024 17:11, Janis Papanagnou wrote: > >>>> Is or was there any compiler that implemented that in the "unexpected" >>>> order? >>>> >>> >>> There were indeed such real-world cases, complaints were made, >> >> Complaints that the rule was not clear in its definition? >> Or complaints that their compiler did not support cout<<a<<b<<c; >> correctly? - I would be astonished about the latter. > > The pre-C++17 rule was perfectly clear - there was no specified order of > execution for the operands. (And I thought I'd made /that/ perfectly > clear already.) Compilers all worked correctly - they can hardly have > fallen foul of a rule that did not exist. > > The complaints (at least, the ones based on facts rather than > misunderstandings) were about the lack of a rule that enforced > evaluation order in certain cases. > > So C++17 added rules for evaluation orders in some circumstances, but > not others. In C++17, but not before (and not in C), the evaluation of > the expression "one" (and any side-effects) must come before the > evaluation of "two" for, amongst other things : > > one << two > one >> two > one[two] > two = one > > There is still /no/ ordering for > > one * two > one + two > > and many other cases. > > And of course there are cases where there has always been a sequence > point, and therefore an order of evaluation (a logical order, that is - > if the compiler can see it makes no difference to the observable > effects, it can always re-arrange anything). > > <https://en.cppreference.com/w/cpp/language/eval_order> > <https://en.cppreference.com/w/c/language/eval_order> > > >> This is so fundamental a construct and so frequently used that any >> compiler would have been withdrawn in the week after it came out. >> That is my expectation. So I would be grateful if you could provide >> some evidence that I can look up. > > <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf> > > For an example in practice, where you can see the generated assembly: > > <https://www.godbolt.org/z/fWezzx1nd> > > If I remember correctly, gcc 7 implemented the ordering rules from C++17 > and back-ported them to previous C++ standards for user convenience (as > the order was previously unspecified, it was fine to do that). > > Look at the generated assembly and the order in which the calls to > one(), two(), three() and four() are made. For the operator "<<", they > are made in order one() to four(). For the operator "+", and for > function call parameters, they are generated in order four() to one() > for this case. (In other cases, that may be different - that's what > "unspecified" means.) > >> >> Mind that even if two() is evaluated before one(), it will not be >> output before the stream of the first expression op<<(cout, one()) >> is available, and for this one() must be evaluated. Then one() can >> be sent to the stream, and then also two() can be sent to the stream. >> (Am I missing something?) > > The output to the stream must be in the order given in the code - that > is true. But the values to be output could (prior to C++17) be > evaluated in any order. If one() and two() have side-effects, that is > critical - those side-effects could be executed in any order. > >> >> Janis >> >>> and the rules changed in C++17. >>> >>> Usually it doesn't matter what order arguments to functions (or operands >>> to operators) are evaluated. Some compilers have consistent ordering >>> (and it is often last to first, not first to last), others pick whatever >>> makes sense at the time. The ordering has been explicitly and clearly >>> stated as "unspecified" since around the beginning of time (which was, >>> as we all know, 01.01.1970). >> >> >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-26 19:59 +0100 |
| Message-ID | <up0vec$2vv0k$1@dont-email.me> |
| In reply to | #381000 |
On 26/01/2024 18:31, Janis Papanagnou wrote: > All what you wrote below targets at your last sentense > "those side-effects could be executed in any order". > For the examples we had, like (informally) cout<<a<<b<<c; > this is undisputed for the SIDE EFFECTS of "a", etc. You > had "hidden" those side effects in "one()", I gave in an > earlier post the more obvious example c++ in the context > of cout << c++ << c++ << c++ << endl; as side effects. > All side effects can be a problem (and should be avoided > unless "necessary"). My point was that the order of '<<' > with its arguments is NOT corrupted. I interpreted your > previous posting that you'd have heard that to be an issue. > If you haven't meant to say that there's nothing more to > say about the issue, since the other things you filled your > post with is only distracting from the point in question. > I said - repeatedly - that the order of evaluation of the operands to most operators is unspecified in C and C++. This could result in behaviour that was unexpected for some people, especially in connection with cout and other C++ streams, and was thus specified in C++17 for specific cases. A typical example would be : cout << "Start time: " << get_time() << "\n" << "Running tests... " << run_tests() << "\n" << "End time: " << get_time(); It was realistic - and indeed happened in some cases - for pre-C++17 compilers to generate the second "get_time()" call before "run_tests()", and finally do the first "get_time()" call. Alternatively, the compiler could call "get_time()" twice, with "run_tests()" called either before or after that pair. In all these cases, the user will see an output that was not at all what they intended, with time appearing to go backwards or the test apparently taking no time. This was the case regardless of whether or not "get_time()" and "run_tests()" had any side-effects. You are, quite obviously, guaranteed that in "cout << a << b << c", the output was in order a, b, c. But that is a totally different matter from the order of evaluation (and execution, for function calls) of the subexpressions a, b, and c. I have said exactly what I intended to say in this thread, but I suspect you have mistaken what the term "order of evaluation" means, and therefore misunderstood what I wrote. I hope this is all clear to you now. > > > On 26.01.2024 17:01, David Brown wrote: >> On 26/01/2024 02:21, Janis Papanagnou wrote: >>> On 25.01.2024 21:11, David Brown wrote: >>>> On 25/01/2024 17:11, Janis Papanagnou wrote: >> >>>>> Is or was there any compiler that implemented that in the "unexpected" >>>>> order? >>>>> >>>> >>>> There were indeed such real-world cases, complaints were made, >>> >>> Complaints that the rule was not clear in its definition? >>> Or complaints that their compiler did not support cout<<a<<b<<c; >>> correctly? - I would be astonished about the latter. >> >> The pre-C++17 rule was perfectly clear - there was no specified order of >> execution for the operands. (And I thought I'd made /that/ perfectly >> clear already.) Compilers all worked correctly - they can hardly have >> fallen foul of a rule that did not exist. >> >> The complaints (at least, the ones based on facts rather than >> misunderstandings) were about the lack of a rule that enforced >> evaluation order in certain cases. >> >> So C++17 added rules for evaluation orders in some circumstances, but >> not others. In C++17, but not before (and not in C), the evaluation of >> the expression "one" (and any side-effects) must come before the >> evaluation of "two" for, amongst other things : >> >> one << two >> one >> two >> one[two] >> two = one >> >> There is still /no/ ordering for >> >> one * two >> one + two >> >> and many other cases. >> >> And of course there are cases where there has always been a sequence >> point, and therefore an order of evaluation (a logical order, that is - >> if the compiler can see it makes no difference to the observable >> effects, it can always re-arrange anything). >> >> <https://en.cppreference.com/w/cpp/language/eval_order> >> <https://en.cppreference.com/w/c/language/eval_order> >> >> >>> This is so fundamental a construct and so frequently used that any >>> compiler would have been withdrawn in the week after it came out. >>> That is my expectation. So I would be grateful if you could provide >>> some evidence that I can look up. >> >> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf> >> >> For an example in practice, where you can see the generated assembly: >> >> <https://www.godbolt.org/z/fWezzx1nd> >> >> If I remember correctly, gcc 7 implemented the ordering rules from C++17 >> and back-ported them to previous C++ standards for user convenience (as >> the order was previously unspecified, it was fine to do that). >> >> Look at the generated assembly and the order in which the calls to >> one(), two(), three() and four() are made. For the operator "<<", they >> are made in order one() to four(). For the operator "+", and for >> function call parameters, they are generated in order four() to one() >> for this case. (In other cases, that may be different - that's what >> "unspecified" means.) >> >>> >>> Mind that even if two() is evaluated before one(), it will not be >>> output before the stream of the first expression op<<(cout, one()) >>> is available, and for this one() must be evaluated. Then one() can >>> be sent to the stream, and then also two() can be sent to the stream. >>> (Am I missing something?) >> >> The output to the stream must be in the order given in the code - that >> is true. But the values to be output could (prior to C++17) be >> evaluated in any order. If one() and two() have side-effects, that is >> critical - those side-effects could be executed in any order. >> >>> >>> Janis >>> >>>> and the rules changed in C++17. >>>> >>>> Usually it doesn't matter what order arguments to functions (or operands >>>> to operators) are evaluated. Some compilers have consistent ordering >>>> (and it is often last to first, not first to last), others pick whatever >>>> makes sense at the time. The ordering has been explicitly and clearly >>>> stated as "unspecified" since around the beginning of time (which was, >>>> as we all know, 01.01.1970). >>> >>> >> >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-26 12:27 -0800 |
| Message-ID | <87cytn3knn.fsf@nosuchdomain.example.com> |
| In reply to | #381004 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> You are, quite obviously, guaranteed that in "cout << a << b << c",
> the output was in order a, b, c. But that is a totally different
> matter from the order of evaluation (and execution, for function
> calls) of the subexpressions a, b, and c.
[...]
Perhaps I can help clarify this a bit (or perhaps muddy the waters
even further). I'll try to add a bit of C relevance at the bottom.
In `cout << a << b << c`, if a, b, and c are names of non-volatile
objects, the evaluation order doesn't matter. The values of a, b,
and c will be written to the standard output stream in that order,
in all versions of C++.
In `cout << x() << y() << z()`, it's also guaranteed that the
result of the call to `x()` will precede the result of the call to
`y()`, which will precede the result of the call to `z()`, in the
text written to the output stream. What's not guaranteed prior
to C++17 is the order in which the three functions will be called.
If none of the functions have side effects that affect the results
of the other two, or depend on non-local data, it doesn't matter.
If the functions return, say, a string representation of the current
time with nanosecond resolution, the three results can be in any
of 6 orders prior to C++17; in C++17 and later, the timestamps will
always be in increasing order.
C++ overloads the "<<" shift operator for output operations, so each
"<<" after `std::cout` is really a function call, but the rules for
sequencing and order of evaluation are the same as for the built-in
"<<" integer shift operation. C++ could have imposed sequencing
requirements only on overloaded "<<" and ">> operators, but that
would have been more difficult to specify in the standard.
C++17 added a new requirement that the evaluation of the left
operand of "<<" or ">>" is "sequenced before" the right operand,
meaning that any side effects of the evaluation of the left operand
must be complete before evaluation of the right operand begins
(though optimizations that don't change the visible behavior are
still allowed). It did not add such a requirement for the "+"
operator, which is overloaded for std::string concatenation.
Here's an example:
#include <iostream>
#include <string>
static std::string func() {
static std::string results[] = {
"zero", "one", "two", "three", "four"
};
static int index = 0;
return results[index++];
}
int main() {
std::cout << func() << ' ' << func() << '\n';
std::string s = func() + ' ' + func() + '\n';
std::cout << s;
}
Prior to C++17, the first line of output could be either "zero one"
or "one zero", and the second could be either "two three" or
"three two". In C++17 and later, the first line of output must
be "zero one", but the second can still be either "two three" or
"three two" (I get different results with g++ and clang++).
(This raises some interesting questions about C++ I/O manipulators,
but I won't get into that here.)
The relevance to C is that a future C standard *could* impose new
sequencing requirements for some or all operators and for function
arguments, but without C++-style operator overloading there are
fewer contexts in which it would matter. If the operands of "+"
were sequenced, then `i++ + i++` would have defined behavior (it's
currently undefined).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-26 22:01 +0100 |
| Message-ID | <up16k1$315ru$1@dont-email.me> |
| In reply to | #381008 |
On 26.01.2024 21:27, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> You are, quite obviously, guaranteed that in "cout << a << b << c", >> the output was in order a, b, c. But that is a totally different >> matter from the order of evaluation (and execution, for function >> calls) of the subexpressions a, b, and c. > [...] > > Perhaps I can help clarify this a bit (or perhaps muddy the waters > even further). I'll try to add a bit of C relevance at the bottom. > > In `cout << a << b << c`, if a, b, and c are names of non-volatile > objects, the evaluation order doesn't matter. The values of a, b, > and c will be written to the standard output stream in that order, > in all versions of C++. Please note that I used cout << a << b << c as a meta expression to _subsume_ in one expression the two variants that may have possible side effects; that with three functions, and that with three instances of c++. I hoped that got clear from the subsequent text, but obviously it confused the matter. Sorry about that. > > In `cout << x() << y() << z()`, it's also guaranteed that the > result of the call to `x()` will precede the result of the call to > `y()`, which will precede the result of the call to `z()`, in the > text written to the output stream. What's not guaranteed prior > to C++17 is the order in which the three functions will be called. > If none of the functions have side effects that affect the results > of the other two, or depend on non-local data, it doesn't matter. > If the functions return, say, a string representation of the current > time with nanosecond resolution, the three results can be in any > of 6 orders prior to C++17; in C++17 and later, the timestamps will > always be in increasing order. Yes. > > C++ overloads the "<<" shift operator for output operations, so each > "<<" after `std::cout` is really a function call, but the rules for > sequencing and order of evaluation are the same as for the built-in > "<<" integer shift operation. C++ could have imposed sequencing > requirements only on overloaded "<<" and ">> operators, but that > would have been more difficult to specify in the standard. Okay. > > C++17 added a new requirement that the evaluation of the left > operand of "<<" or ">>" is "sequenced before" the right operand, > meaning that any side effects of the evaluation of the left operand > must be complete before evaluation of the right operand begins > (though optimizations that don't change the visible behavior are > still allowed). It did not add such a requirement for the "+" > operator, which is overloaded for std::string concatenation. This is actually what I was asking for; what they changed. Thanks. (And as I suspected it's about "side effects of the evaluation".) > [ snip example and prospect ] And no, you haven't muddied the issue, au contraire, it's a very clear presentation. Janis
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-26 22:30 +0100 |
| Message-ID | <up188s$31e8n$1@dont-email.me> |
| In reply to | #381004 |
On 26.01.2024 19:59, David Brown wrote:
>
> I said - repeatedly - that the order of evaluation of the operands to
> most operators is unspecified in C and C++. [...]
Yes, and this was undisputed.
>
> A typical example would be :
>
> cout << "Start time: " << get_time() << "\n"
> << "Running tests... " << run_tests() << "\n"
> << "End time: " << get_time();
>
> It was realistic - and indeed happened in some cases - for pre-C++17
> compilers to generate the second "get_time()" call before "run_tests()",
> and finally do the first "get_time()" call.
Yes, we have no differences.
And the sample is fine to show how we should NOT implement such time
measurements (or similar logic)!
A computer scientist or a sophisticated programmer would know that
there are run-times associated in such expressions:
cout << "S1" << f1() << "S2" << f2() << "S3" << f3();
t1 t2 t3 t4 t5 t6 t7 t8 t9
and he would act accordingly and serialize the expression (see below).
> Alternatively, the compiler
> could call "get_time()" twice, with "run_tests()" called either before
> or after that pair. In all these cases, the user will see an output
> that was not at all what they intended, with time appearing to go
> backwards or the test apparently taking no time.
>
> This was the case regardless of whether or not "get_time()" and
> "run_tests()" had any side-effects.
We disagree here; it may not appear so to you but get_time() actually
has a "side effect" (I put it in quotes, because it's literally no
"effect" but for the argument of its _sequencing problem_ it's a
relevant externality). It obtains (probably from a hardware device)
the time when the call happened.
That's why somewhat experienced programmers would not write above
code that way; something like "run_tests()" is (typically) or can be
very time consuming, so they'd do
t0 = get_time(); res = run_tests(); t1 = get_time();
cout << ... etc.
(Note: This argument implies NOT that a language shouldn't be made as
bulletproof as possible and sensible.)
>
> You are, quite obviously, guaranteed that in "cout << a << b << c", the
> output was in order a, b, c. But that is a totally different matter
> from the order of evaluation (and execution, for function calls) of the
> subexpressions a, b, and c.
(It was meant as a "meta expression". I've addressed that in my
response to Keith already; please see there.)
>
> I have said exactly what I intended to say in this thread, but I suspect
> you have mistaken what the term "order of evaluation" means, and
> therefore misunderstood what I wrote. I hope this is all clear to you now.
The order of evaluation of the '<<' was what I spoke about. The order
of the arguments had never been an issue. The "problem" with the order
of the arguments becomes a problem (without quotes) when side effects
of the arguments are inherent to the arguments.
You had been focused on the evaluation of the arguments (where side
effects might lead to unexpected behavior). I wasn't.
Janis
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-01-26 20:22 -0500 |
| Message-ID | <up1lsf$33abt$1@dont-email.me> |
| In reply to | #381016 |
On 1/26/24 16:30, Janis Papanagnou wrote: ... > We disagree here; it may not appear so to you but get_time() actually > has a "side effect" (I put it in quotes, because it's literally no > "effect" but for the argument of its _sequencing problem_ it's a > relevant externality). It obtains (probably from a hardware device) > the time when the call happened. "Reading an object designated by a volatile glvalue (7.2.1), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment." (C++ 6.9.1p7) The term "side effect" is in italics in that sentence, an ISO convention indicating that the sentence in which it appears constitutes the official definition of that term. Everything that the C++ standard says about side effects traces back to that definition.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-27 16:43 +0100 |
| Message-ID | <up38aj$3ec59$1@dont-email.me> |
| In reply to | #381016 |
On 26/01/2024 22:30, Janis Papanagnou wrote: > On 26.01.2024 19:59, David Brown wrote: >> >> I said - repeatedly - that the order of evaluation of the operands to >> most operators is unspecified in C and C++. [...] > > Yes, and this was undisputed. > >> >> A typical example would be : >> >> cout << "Start time: " << get_time() << "\n" >> << "Running tests... " << run_tests() << "\n" >> << "End time: " << get_time(); >> >> It was realistic - and indeed happened in some cases - for pre-C++17 >> compilers to generate the second "get_time()" call before "run_tests()", >> and finally do the first "get_time()" call. > > Yes, we have no differences. > > And the sample is fine to show how we should NOT implement such time > measurements (or similar logic)! > There are, of course, many reasons why this is not a good way to implement time measurements - the order of evaluation is not the only one. > A computer scientist or a sophisticated programmer would know that > there are run-times associated in such expressions: > > cout << "S1" << f1() << "S2" << f2() << "S3" << f3(); > > t1 t2 t3 t4 t5 t6 t7 t8 t9 > The experienced or knowledgable C++ programmer (prior to C++17) would know that the parts here are not necessarily executed in the order you give. (It's not clear to me if these are the run times for different parts, or time-stamps.) Indeed, depending on the kinds of subexpressions you have, not only can the order of evaluation be changed for most operators, but their evaluation can be interleaved. (I could go through the details, but it is probably better to look them up on a reference site such as en.cppreference.com.) > and he would act accordingly and serialize the expression (see below). > If the programmer wants them to be executed in a particular order, he/she must use constructs in the language to force that. >> Alternatively, the compiler >> could call "get_time()" twice, with "run_tests()" called either before >> or after that pair. In all these cases, the user will see an output >> that was not at all what they intended, with time appearing to go >> backwards or the test apparently taking no time. >> >> This was the case regardless of whether or not "get_time()" and >> "run_tests()" had any side-effects. > > We disagree here; it may not appear so to you but get_time() actually > has a "side effect" (I put it in quotes, because it's literally no > "effect" but for the argument of its _sequencing problem_ it's a > relevant externality). It obtains (probably from a hardware device) > the time when the call happened. We don't disagree - I haven't said what "get_time()" does or how it works, or what concept of "time" it has. I agree that getting some real-world time from a hardware device would be a side-effect - as would most practical ways to get a useful idea of "time". I was making a general point - the operands to the << operator could be (pre-C++17) evaluated in any order regardless of whether or not they had side-effects. > > That's why somewhat experienced programmers would not write above > code that way; something like "run_tests()" is (typically) or can be > very time consuming, so they'd do > t0 = get_time(); res = run_tests(); t1 = get_time(); > cout << ... etc. > Of course. In practice, they could still be badly wrong even with that code - there's a lot of subtle points to consider when trying to time code, and my experience is that very few programmers get it entirely right. > (Note: This argument implies NOT that a language shouldn't be made as > bulletproof as possible and sensible.) > A language should be convenient to use and avoid surprising the programmer. But it should /not/ be a surprise to C or C++ programmers that the order of evaluation of subexpressions is usually unspecified. >> >> You are, quite obviously, guaranteed that in "cout << a << b << c", the >> output was in order a, b, c. But that is a totally different matter >> from the order of evaluation (and execution, for function calls) of the >> subexpressions a, b, and c. > > (It was meant as a "meta expression". I've addressed that in my > response to Keith already; please see there.) > >> >> I have said exactly what I intended to say in this thread, but I suspect >> you have mistaken what the term "order of evaluation" means, and >> therefore misunderstood what I wrote. I hope this is all clear to you now. > > The order of evaluation of the '<<' was what I spoke about. The order > of the arguments had never been an issue. The "problem" with the order > of the arguments becomes a problem (without quotes) when side effects > of the arguments are inherent to the arguments. > > You had been focused on the evaluation of the arguments (where side > effects might lead to unexpected behavior). I wasn't. > I'm afraid I can't quite follow you here. I can just hope that you understand that evaluation order is unspecified for most operators, that real compilers evaluate subexpressions in different orders in real code (so the re-ordering is not hypothetical), and that C++17 added special rules for << and >> to make things more convenient for programmers. If I have helped you see this, or if Keith's post helped you see it, then that's great.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-28 20:14 +0100 |
| Message-ID | <up692h$28q6$1@dont-email.me> |
| In reply to | #381051 |
On 27.01.2024 16:43, David Brown wrote: > On 26/01/2024 22:30, Janis Papanagnou wrote: >> On 26.01.2024 19:59, David Brown wrote: >>> >> A computer scientist or a sophisticated programmer would know that >> there are run-times associated in such expressions: >> >> cout << "S1" << f1() << "S2" << f2() << "S3" << f3(); >> >> t1 t2 t3 t4 t5 t6 t7 t8 t9 >> > > The experienced or knowledgable C++ programmer (prior to C++17) would > know that the parts here are not necessarily executed in the order you > give. And that was not intended in that representation. It was to show where "time factors" are "hidden". (And if I had the intention I could also have chosen 'dt1' instead of the inaccurate 't1' to indicate that.) Sorry if that confuses you. I hoped that together with the text it would be more informative (than confusing). If one sees the time demands, and has read about our consensus about evaluation order above (it was repeatedly stated!) there should be no misunderstanding (or so I thought at least). > [...] > >> That's why somewhat experienced programmers would not write above >> code that way; something like "run_tests()" is (typically) or can be >> very time consuming, so they'd do >> t0 = get_time(); res = run_tests(); t1 = get_time(); >> cout << ... etc. > > Of course. You can serialize (as I suggested previously as one example) or embed functions like take_time(run_tests()) as another example. > > In practice, they could still be badly wrong even with that code - > there's a lot of subtle points to consider when trying to time code, and > my experience is that very few programmers get it entirely right. Really? - I mostly had to do with folks, even newbies with a proper CS education, who had enough experience or knowledge. Most problems appeared in contexts where the used languages have inherent design issues; not in any case we could avoid use of such languages in the first place. Janis [...]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-29 14:09 +0100 |
| Message-ID | <up8830$ffni$1@dont-email.me> |
| In reply to | #381141 |
On 28/01/2024 20:14, Janis Papanagnou wrote:
> On 27.01.2024 16:43, David Brown wrote:
>> On 26/01/2024 22:30, Janis Papanagnou wrote:
>>
>>> That's why somewhat experienced programmers would not write above
>>> code that way; something like "run_tests()" is (typically) or can be
>>> very time consuming, so they'd do
>>> t0 = get_time(); res = run_tests(); t1 = get_time();
>>> cout << ... etc.
>>
>> Of course.
>
> You can serialize (as I suggested previously as one example) or
> embed functions like take_time(run_tests()) as another example.
>
>>
>> In practice, they could still be badly wrong even with that code -
>> there's a lot of subtle points to consider when trying to time code, and
>> my experience is that very few programmers get it entirely right.
>
> Really? - I mostly had to do with folks, even newbies with a
> proper CS education, who had enough experience or knowledge.
> Most problems appeared in contexts where the used languages
> have inherent design issues; not in any case we could avoid
> use of such languages in the first place.
>
Let's suppose you have a "get_time()" function that gets a time stamp
from somewhere, and that it correctly uses a volatile access from
hardware (or some OS-controlled time function that is volatile
somewhere). And suppose you are trying to time a function to test the
speed of recursion on your system :
unsigned int factorial(unsigned int x) {
if (x == 0) return 1;
return x * factorial(x - 1);
}
What happens when you write this? :
unsigned int x = 10;
double start = get_time();
unsigned int y = factorial(x);
double end = get_time();
printf("Time is %f seconds\n", end - start);
It looks reasonable enough, and because "get_time()" has observable
behaviour (a volatile access), it must be correct, right? It gives
shows a small but non-zero time, as expected.
But what you have actually measured is the overhead in the get_time()
function, because the compiler has removed the call to factorial because
the answer is not needed.
So you try :
unsigned int x = 10;
double pre_start = get_time();
double start = get_time();
unsigned int y = factorial(x);
double end = get_time();
double overhead = start - pre_start;
printf("Factorial %ui is %ui\n", x, y);
printf("Time is %f seconds\n", end - start - overhead);
to compensate for the overhead in the timing, and to force the compiler
to run factorial(10) because you observe its output. Now you get the
right answer for y, and the time is 0, because the compiler has
pre-calculated factorial x and substituted 3628800 for y.
So you take "x" from argv, so that the compiler can't pre-calculate the
result. And now the time is 0, because the compiler has re-arranged the
code as though it was :
unsigned int x = atoi(argv[1]);
double pre_start = get_time();
double start = get_time();
double end = get_time();
double overhead = start - pre_start;
unsigned int y = factorial(x);
printf("Factorial %ui is %ui\n", x, y);
printf("Time is %f seconds\n", end - start - overhead);
Making x and y both volatile gives you a time for the call to
factorial(x). It is still not measuring any recursion speed, because
the compiler has turned that function into a loop.
And that is before we start asking if you are measuring the speed of the
code, or of the memory and cache system on your PC.
I regularly see people failing to time or benchmark functions as they
expect - they don't understand how the compiler can re-arrange or
optimise things. A recurring problem is the belief that volatile
accesses force an order on other memory accesses, or on calculations,
which is not correct.
Then they decide to disable optimisation because "the optimiser messes
with my timing code", getting a result as useful as measuring the speed
of a race car stuck in first gear.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-01-26 20:10 -0500 |
| Message-ID | <up1l5p$337rb$1@dont-email.me> |
| In reply to | #381000 |
On 1/26/24 12:31, Janis Papanagnou wrote: ... > All what you wrote below targets at your last sentense > "those side-effects could be executed in any order". > For the examples we had, like (informally) cout<<a<<b<<c; > this is undisputed for the SIDE EFFECTS of "a", etc. You > had "hidden" those side effects in "one()", I gave in an > earlier post the more obvious example c++ in the context > of cout << c++ << c++ << c++ << endl; as side effect There's an important reason why he used one(), two(), and three(). "If a side effect on a memory location (6.7.1) is unsequenced relative to either another side effect on the same memory location or a value computation using the value of any object in the same memory location, and they are not potentially concurrent (6.9.2), the behavior is undefined." (C++ 6.9.1p10) "Two actions are potentially concurrent if (21.1)— they are performed by different threads, or (21.2)— they are unsequenced, at least one is performed by a signal handler, and they are not both performed by the same signal handler invocation." (C++ 6.9.2.1p21) So the exception for potentially concurrent side effects cannot apply to your version. All three of your c++ expressions have side effects on the same memory location, and all use the value stored in that location. Prior to the change which is being discussed, all three of those side effects would have been unsequenced from each other and from each other's value computations, so the behavior of such an expression would have been undefined. With this change, they are sequenced, and there is no longer a problem with such code. The function one(), two() and three() that he used could have side effects that effect each other without sharing a memory location, for instance by writing to and reading from a file. Therefore, such code would have worked both before and after that change - but it might have given different results before the change. > All side effects can be a problem (and should be avoided > unless "necessary"). Virtually everything useful that a computer program does qualifies as a side effect. Side effects cannot be avoided, they can only be controlled.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-27 16:44 +0100 |
| Message-ID | <up38cs$3ec59$2@dont-email.me> |
| In reply to | #381031 |
On 27/01/2024 02:10, James Kuyper wrote: > On 1/26/24 12:31, Janis Papanagnou wrote: >> All side effects can be a problem (and should be avoided >> unless "necessary"). > > Virtually everything useful that a computer program does qualifies as a > side effect. Side effects cannot be avoided, they can only be controlled. > Try telling that to Haskell programmers :-)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-27 20:49 +0000 |
| Subject | Re: Functional Programming (was Re: iso646.h) |
| Message-ID | <up3q8k$3hbk7$6@dont-email.me> |
| In reply to | #381052 |
On Sat, 27 Jan 2024 16:44:28 +0100, David Brown wrote: > On 27/01/2024 02:10, James Kuyper wrote: > >> On 1/26/24 12:31, Janis Papanagnou wrote: > >>> All side effects can be a problem (and should be avoided unless >>> "necessary"). >> >> Virtually everything useful that a computer program does qualifies as a >> side effect. Side effects cannot be avoided, they can only be >> controlled. >> > Try telling that to Haskell programmers :-) The dirty little secret of pure-functional programming is that I/O cannot be treated in a purely functional fashion.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-01-28 00:22 +0000 |
| Subject | Re: Functional Programming (was Re: iso646.h) |
| Message-ID | <up46nn$3jb0p$1@dont-email.me> |
| In reply to | #381068 |
On 27/01/2024 20:49, Lawrence D'Oliveiro wrote: > On Sat, 27 Jan 2024 16:44:28 +0100, David Brown wrote: > >> On 27/01/2024 02:10, James Kuyper wrote: >> >>> On 1/26/24 12:31, Janis Papanagnou wrote: >> >>>> All side effects can be a problem (and should be avoided unless >>>> "necessary"). >>> >>> Virtually everything useful that a computer program does qualifies as a >>> side effect. Side effects cannot be avoided, they can only be >>> controlled. >>> >> Try telling that to Haskell programmers :-) > > The dirty little secret of pure-functional programming is that I/O cannot > be treated in a purely functional fashion. > So the model is input - calculation - output. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-28 01:18 +0000 |
| Subject | Re: Functional Programming (was Re: iso646.h) |
| Message-ID | <up4a0t$3jopf$4@dont-email.me> |
| In reply to | #381083 |
On Sun, 28 Jan 2024 00:22:15 +0000, Malcolm McLean wrote: > On 27/01/2024 20:49, Lawrence D'Oliveiro wrote: > >> The dirty little secret of pure-functional programming is that I/O >> cannot be treated in a purely functional fashion. >> > So the model is input - calculation - output. So “functional” is really “procedural-functional-procedural”. And what happens with interactive code? You need a loop around that sequence--another procedural construct. And maybe a conditional exit--yet another procedural construct.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-01-28 02:06 +0000 |
| Subject | Re: Functional Programming (was Re: iso646.h) |
| Message-ID | <up4cr9$3k4b8$2@dont-email.me> |
| In reply to | #381090 |
On 28/01/2024 01:18, Lawrence D'Oliveiro wrote: > On Sun, 28 Jan 2024 00:22:15 +0000, Malcolm McLean wrote: > >> On 27/01/2024 20:49, Lawrence D'Oliveiro wrote: >> >>> The dirty little secret of pure-functional programming is that I/O >>> cannot be treated in a purely functional fashion. >>> >> So the model is input - calculation - output. > > So “functional” is really “procedural-functional-procedural”. > > And what happens with interactive code? You need a loop around that > sequence--another procedural construct. And maybe a conditional exit--yet > another procedural construct. > Exactly. Some programs essentially calculate something. The data is input, transformed, and you get output. But others don't. They provide a virual world which the user can manipulate. The calculations and data transformations are often pretty trivial, and all the programming effort is in supporting the user interface. And so you need a different conceptual model. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-28 12:35 +0100 |
| Subject | Re: Functional Programming (was Re: iso646.h) |
| Message-ID | <up5e54$3t99q$2@dont-email.me> |
| In reply to | #381068 |
On 27/01/2024 21:49, Lawrence D'Oliveiro wrote: > On Sat, 27 Jan 2024 16:44:28 +0100, David Brown wrote: > >> On 27/01/2024 02:10, James Kuyper wrote: >> >>> On 1/26/24 12:31, Janis Papanagnou wrote: >> >>>> All side effects can be a problem (and should be avoided unless >>>> "necessary"). >>> >>> Virtually everything useful that a computer program does qualifies as a >>> side effect. Side effects cannot be avoided, they can only be >>> controlled. >>> >> Try telling that to Haskell programmers :-) > > The dirty little secret of pure-functional programming is that I/O cannot > be treated in a purely functional fashion. It can - you just have to have the IO world as an input and an output to your function. I must admit that I have never done any IO in a functional programming language. All my usage has been with "pure" functions, and it is also quite out of date.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-28 20:40 +0000 |
| Subject | Re: Functional Programming (was Re: iso646.h) |
| Message-ID | <up6e34$2vq9$6@dont-email.me> |
| In reply to | #381108 |
On Sun, 28 Jan 2024 12:35:00 +0100, David Brown wrote: > On 27/01/2024 21:49, Lawrence D'Oliveiro wrote: > >> The dirty little secret of pure-functional programming is that I/O >> cannot be treated in a purely functional fashion. > > It can - you just have to have the IO world as an input and an output to > your function. You mean, carry around multiple copies of the entire Universe in individual variables?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-29 09:52 +0100 |
| Subject | Re: Functional Programming (was Re: iso646.h) |
| Message-ID | <up7p0t$csr3$1@dont-email.me> |
| In reply to | #381147 |
On 28/01/2024 21:40, Lawrence D'Oliveiro wrote: > On Sun, 28 Jan 2024 12:35:00 +0100, David Brown wrote: > >> On 27/01/2024 21:49, Lawrence D'Oliveiro wrote: >> >>> The dirty little secret of pure-functional programming is that I/O >>> cannot be treated in a purely functional fashion. >> >> It can - you just have to have the IO world as an input and an output to >> your function. > > You mean, carry around multiple copies of the entire Universe in > individual variables? No, you only need one copy at a time :-) And you only actually need a bit of the universe, covering your input and output streams. Another option is that your code does not actually do any IO, but returns a function that can be applied to the world to give the results you want. Real functional programming languages have smarter ways of doing this in an efficient way. The functions may be pure as you see them in code, but the generated results do IO just like any other generated code in other languages. This gives you the advantages of purity at the source level - it's far easier to have mathematical proofs of the code's correctness, multi-threading or asynchronous coding is easy because you have no state, therefore no shared state, therefore no race conditions. But the end result is efficient - perhaps not "well-written C" efficient, but close enough to be of practical use in the real world. The key challenge is that you have to understand monads! A much simpler idea in a similar vein is that functional programming languages don't have iterative loops - you use lists or recursion to express repetition. In C, having a recursive function that works through a linked list is massively inefficient compared to a for loop, in both run-time and stack space. In a functional programming language, lists and recursion make it simple and clear to express the code - and the compiler turns it all into an iterative loop in the generated code. (Facebook uses Haskell for their filters and other data handling. You may not think much about Facebook's algorithms, but it shows that pure functional programming works fine and efficiently for big IO applications. Major mobile phone systems are programmed in Erlang, which is a functional programming language, albeit an impure one which can "cheat".)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-02 05:13 +0000 |
| Subject | Re: Functional Programming (was Re: iso646.h) |
| Message-ID | <uphtmj$2fg0v$10@dont-email.me> |
| In reply to | #381167 |
On Mon, 29 Jan 2024 09:52:45 +0100, David Brown wrote: > (Facebook uses Haskell for their filters and other data handling. I’m sure that may work OK for a filter expressed as a pure function. How does it work for one where the filter has internal state which is changed as a result of prior input, and which alters the production of subsequent output?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-02 09:21 +0100 |
| Subject | Re: Functional Programming (was Re: iso646.h) |
| Message-ID | <upi8lr$2h7rf$1@dont-email.me> |
| In reply to | #381577 |
On 02/02/2024 06:13, Lawrence D'Oliveiro wrote: > On Mon, 29 Jan 2024 09:52:45 +0100, David Brown wrote: > >> (Facebook uses Haskell for their filters and other data handling. > > I’m sure that may work OK for a filter expressed as a pure function. How > does it work for one where the filter has internal state which is changed > as a result of prior input, and which alters the production of subsequent > output? I have no idea. You could ask in a Haskell group, but that is well beyond my knowledge and well outside this group's topicality. I can only tell you it is not only possible in Haskell, but practical and viewed by a big, rich and experienced company as the best language for the task. As for /how/ it works, you'll have to look elsewhere.
[toc] | [prev] | [next] | [standalone]
Page 12 of 33 — ← Prev page 1 … 10 11 [12] 13 14 … 33 Next page →
Back to top | Article view | comp.lang.c
csiph-web