Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #81271 > unrolled thread
| Started by | alessandro volturno <alessandro.volturno@libero.it> |
|---|---|
| First post | 2021-09-16 14:59 +0200 |
| Last post | 2021-09-24 02:48 -0700 |
| Articles | 20 on this page of 230 — 21 participants |
Back to article view | Back to comp.lang.c++
rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-16 14:59 +0200
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-16 16:40 +0300
Re: rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-16 18:24 +0200
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-16 17:05 +0000
Re: rational numbers Manfred <noname@add.invalid> - 2021-09-16 19:58 +0200
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-17 09:21 +0200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-17 10:34 +0200
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-17 15:55 +0200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-17 17:49 +0200
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-17 18:22 +0200
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-17 22:07 +1200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-17 13:32 +0200
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-18 09:15 +1200
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-17 14:06 +0000
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-16 20:41 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-16 21:11 +0100
Re: rational numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-16 21:26 +0100
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-16 21:54 +0100
Re: rational numbers "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-16 23:07 +0200
Re: rational numbers "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-16 23:27 +0200
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-16 23:12 +0300
Re: rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-17 09:50 +0200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-17 11:15 +0200
Re: rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-17 19:19 +0200
Re: rational numbers James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-17 19:00 -0400
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-18 11:39 +0200
Re: rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-18 11:56 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-18 11:01 +0100
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-17 05:36 +0000
Re: rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-17 09:55 +0200
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-17 11:16 +0000
Re: rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-17 18:33 +0200
Re: rational numbers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 13:06 -0700
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-17 14:03 +0000
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-17 17:12 +0200
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-17 17:16 +0200
Re: rational numbers Manfred <noname@add.invalid> - 2021-09-17 18:59 +0200
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-17 17:13 +0000
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-19 10:17 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-19 14:07 +0000
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-19 15:58 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-19 21:53 +0000
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-18 09:34 +1200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-18 12:00 +0200
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-18 14:54 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-18 17:36 +0100
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-18 23:29 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-19 01:09 +0100
Re: rational numbers red floyd <no.spam.here@its.invalid> - 2021-09-18 23:45 -0700
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-18 22:48 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-19 00:46 +0100
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-19 08:06 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-19 10:26 +0100
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-19 10:23 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-19 12:04 +0100
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-19 16:01 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-19 17:39 +0100
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-20 05:25 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-20 10:37 +0100
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-22 04:58 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-22 11:26 +0100
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-22 23:13 +1200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-22 13:45 +0100
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-24 21:37 +1200
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-22 15:29 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-23 07:26 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-19 21:54 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-20 00:31 +0100
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-20 08:33 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-20 16:11 +0100
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-20 18:08 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-20 18:39 +0100
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-20 19:49 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-20 19:04 +0100
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-20 21:35 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-20 21:38 +0100
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-21 10:28 +1200
Re: rational numbers Bo Persson <bo@bo-persson.se> - 2021-09-21 09:08 +0200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-21 09:39 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 11:12 +0100
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-21 15:45 +0300
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 14:37 +0100
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-21 17:09 +0300
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 16:26 +0100
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-21 18:04 +0200
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-21 11:51 -0700
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-22 11:09 +0200
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-21 15:38 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-21 15:36 +0000
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-21 15:49 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-21 16:21 +0000
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-22 09:21 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 17:45 +0100
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-21 17:02 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 18:16 +0100
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-21 11:53 -0700
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 20:48 +0100
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-21 20:23 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 23:29 +0100
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-21 13:47 -0700
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-21 20:11 +0300
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 18:33 +0100
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-21 20:43 +0300
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 18:59 +0100
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-21 21:20 +0300
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 20:32 +0100
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-21 20:24 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-21 18:52 +0000
Re: rational numbers Bo Persson <bo@bo-persson.se> - 2021-09-21 18:34 +0200
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-21 01:16 +0300
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-21 00:39 +0100
Re: rational numbers Manfred <noname@add.invalid> - 2021-09-22 23:45 +0200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-22 23:51 +0200
Re: rational numbers Manfred <noname@add.invalid> - 2021-09-23 18:42 +0200
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-23 21:52 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 00:17 +0100
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-23 02:03 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 11:18 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-23 10:26 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 12:21 +0100
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 12:40 +0100
Re: rational numbers Richard Damon <Richard@Damon-Family.org> - 2021-09-23 08:05 -0400
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 15:02 +0100
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-24 08:48 +1200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 23:05 +0100
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-23 23:47 +0000
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-23 16:56 -0700
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-24 01:58 +0100
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 01:40 +0000
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-23 19:35 -0700
Re: rational numbers "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-09-24 09:07 -0700
Re: rational numbers "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-09-24 09:21 -0700
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-23 14:58 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 17:02 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-23 16:21 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 18:31 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-24 09:12 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-24 12:10 +0100
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 11:23 +0000
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-24 15:19 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-24 17:25 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-25 09:27 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-25 11:07 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-25 10:14 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-25 11:53 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-25 11:23 +0000
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 12:34 +0000
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-25 15:37 +0300
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-25 15:46 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-25 15:19 +0000
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 17:16 +0000
Re: rational numbers Christian Gollwitzer <auriocus@gmx.de> - 2021-09-27 23:51 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-27 23:41 +0100
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-23 10:26 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-23 14:04 +0000
Re: rational numbers Manfred <noname@add.invalid> - 2021-09-23 17:47 +0200
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-23 17:07 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-23 17:08 +0000
Re: rational numbers Manfred <noname@add.invalid> - 2021-09-23 19:30 +0200
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-24 10:06 +1200
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-22 05:06 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-22 10:51 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-22 10:54 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-22 11:59 +0100
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-22 11:04 +0000
Re: rational numbers "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-22 14:17 +0200
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-22 14:32 +0100
Re: rational numbers "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-22 16:23 +0200
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-22 15:18 +0300
Re: rational numbers "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-22 16:16 +0200
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-22 15:15 +0000
Re: rational numbers "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-22 17:57 +0200
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-22 16:05 +0000
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-22 14:13 -0700
Re: rational numbers HorseyWorsey@the_stables.com - 2021-09-23 09:01 +0000
Re: rational numbers James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-23 12:08 -0400
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-23 10:55 -0700
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-22 20:46 +0300
Re: rational numbers "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-09-22 14:42 -0700
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-23 09:15 +0300
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-22 14:04 +0000
Re: rational numbers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-22 07:18 -0700
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-23 07:31 +0000
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-23 11:05 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-23 08:28 +0000
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-24 00:51 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-24 04:37 +0000
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 07:46 +0000
Re: rational numbers "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-09-24 08:59 -0700
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-24 22:49 +0300
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 00:55 +0000
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-24 12:17 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-27 05:25 +0000
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-27 11:37 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-28 04:49 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-23 11:29 +0100
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-24 04:38 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-24 11:15 +0100
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 10:19 +0000
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-27 05:34 +0000
Re: rational numbers scott@slp53.sl.home (Scott Lurndal) - 2021-09-23 14:07 +0000
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-23 14:50 +0000
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-20 05:20 +0000
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-24 21:45 +1200
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-25 16:15 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-27 05:36 +0000
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-27 11:19 +0300
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-27 21:27 +1300
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-27 15:49 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-28 04:53 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-28 10:16 +0100
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-29 12:10 +0000
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-29 14:34 +0100
Re: rational numbers Bart <bc@freeuk.com> - 2021-09-29 15:54 +0100
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-28 13:23 +0300
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-29 10:34 +1300
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-29 12:18 +0300
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-29 22:46 +1300
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-29 13:07 +0300
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-10-02 22:57 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-29 12:16 +0000
Re: rational numbers Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-29 20:15 +0300
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-30 04:46 +0000
Re: rational numbers Ian Collins <ian-news@hotmail.com> - 2021-09-19 11:03 +1200
Re: rational numbers Juha Nieminen <nospam@thanks.invalid> - 2021-09-19 10:12 +0000
Re: rational numbers Siri Cruise <chine.bleu@yahoo.com> - 2021-09-23 07:38 -0700
Re: rational numbers alessandro volturno <alessandro.volturno@libero.it> - 2021-09-24 09:45 +0200
Re: rational numbers Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 07:50 +0000
Re: rational numbers David Brown <david.brown@hesbynett.no> - 2021-09-24 10:58 +0200
Re: rational numbers Siri Cruise <chine.bleu@yahoo.com> - 2021-09-24 02:48 -0700
Page 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-21 15:45 +0300 |
| Message-ID | <sick4u$shq$1@dont-email.me> |
| In reply to | #81367 |
21.09.2021 13:12 Bart kirjutas: > What can 'cout' or 'printf' do that an easier-to-use and better designed > Print can't do? This is an example bit of C++ posted a couple of days ago: > > CMT: > > std::cout << sizeof(__int64) << "\n"; > std::cout << sizeof(__m128) << "\n"; > > std::cout << foo_64.is_lock_free() << "\n"; > std::cout << foo_128.is_lock_free() << "\n"; > > > I might be missing something, but is there any reason why something like: > > println sizeof(__int64); > println sizeof(__m128); > > println foo_64.is_lock_free(); > println foo_128.is_lock_free(); > > wouldn't cut it? Too sensible? Too uncluttered? Might leave too many > people thinking, where's the catch? Because all that extra crap in C++ > must do something important, right? In our codebase of hundreds of thousands lines of C++ code there are very few outputs to STDOUT, mostly because it's all libraries used by various client programs who would not like at all if a library polluted the console with some unwanted messages. Also, when running in Windows there typically is no console, so there is not much point in printing anything there. If I want to see the value of some variable during a program run, I put a breakpoint there and hover the mouse over the name. There are some messages to STDERR though, in critical conditions like memory exhaustion. How do you write a message to STDERR with your 'println'? It's not obvious at all, unlike for std::cout vs std::cerr. Printing to STDOUT seems to me a kind of niche facility which is used pretty rarely during large parts of C++ development. Why should such a facility get some special short name and simplified syntax?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-21 14:37 +0100 |
| Message-ID | <sicn7c$r2s$1@dont-email.me> |
| In reply to | #81369 |
On 21/09/2021 13:45, Paavo Helde wrote:
> 21.09.2021 13:12 Bart kirjutas:
>> What can 'cout' or 'printf' do that an easier-to-use and better
>> designed Print can't do? This is an example bit of C++ posted a couple
>> of days ago:
>>
>> CMT:
>>
>> std::cout << sizeof(__int64) << "\n";
>> std::cout << sizeof(__m128) << "\n";
>>
>> std::cout << foo_64.is_lock_free() << "\n";
>> std::cout << foo_128.is_lock_free() << "\n";
>>
>>
>> I might be missing something, but is there any reason why something like:
>>
>> println sizeof(__int64);
>> println sizeof(__m128);
>>
>> println foo_64.is_lock_free();
>> println foo_128.is_lock_free();
>>
>> wouldn't cut it? Too sensible? Too uncluttered? Might leave too many
>> people thinking, where's the catch? Because all that extra crap in C++
>> must do something important, right?
>
> In our codebase of hundreds of thousands lines of C++ code there are
> very few outputs to STDOUT, mostly because it's all libraries used by
> various client programs who would not like at all if a library polluted
> the console with some unwanted messages. Also, when running in Windows
> there typically is no console, so there is not much point in printing
> anything there. If I want to see the value of some variable during a
> program run, I put a breakpoint there and hover the mouse over the name.
A variety of Print is in pretty much every language; it's a fundamental
feature. Why try to justify a naff implementation of it? But at least
C++'s version is different! If little copied...
It doesn't necessary mean writing to STDOUT either. Most runtime calls
to Print are likely to be to a file, or will captured by redirection.
Others might be to a string.
(My biggest use of C's *printf routines via a FFI was to sprintf, to
assemble strings. But hardcoding format codes /outside of C/, which
varied across OSes anyway, was problematical. I now have my own
formatted print.)
> There are some messages to STDERR though, in critical conditions like
> memory exhaustion. How do you write a message to STDERR with your
> 'println'? It's not obvious at all, unlike for std::cout vs std::cerr.
I virtually never use STDERR, mainly because I've no idea how to do so
outside of C, or via fprintf from a FFI. Even when writing C, it's just
not a thing for me. STDOUT is already used for logging, error messages,
everthing.
However, in /my language/ (I'm not going to do a survey of a dozen
others) you define a destination like this:
print @dest, x
print @con, x # same as print x
Until you mentioned it, I didn't know about cerr at all. I guess there's
a different syntax again for a file.
In C++, how do you conditionally output to either STDOUT or STDERR? This
doesn't work:
auto F = (cond ? stdout : stderr);
F << "HELLO";
> Printing to STDOUT seems to me a kind of niche facility which is used
> pretty rarely during large parts of C++ development.
You can say that about lots of features. One of my favourite features of
my own is Stop:
stop # equivalent to stop 0
stop N
which may be implemented via exit(N) or ProcessExit or whatever. It
might be used a tiny number of times in a program, or none at all.
That doesn't mean it shouldn't be user-friendly. Now apply that thinking
to more features...
> Why should such a
> facility get some special short name and simplified syntax?
I explained why in my post. Because printing to the console is used
extensively during debugging.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-21 17:09 +0300 |
| Message-ID | <sicp21$7u5$1@dont-email.me> |
| In reply to | #81370 |
21.09.2021 16:37 Bart kirjutas:
> On 21/09/2021 13:45, Paavo Helde wrote:
> I virtually never use STDERR, mainly because I've no idea how to do so
> outside of C, or via fprintf from a FFI. Even when writing C, it's just
> not a thing for me. STDOUT is already used for logging, error messages,
> everthing.
Well that's just plain wrong.
> In C++, how do you conditionally output to either STDOUT or STDERR? This
> doesn't work:
>
> auto F = (cond ? stdout : stderr);
> F << "HELLO";
It works if you use C++ names and syntax:
#include <iostream>
int main() {
bool cond = false;
(cond ? std::cout : std::cerr) << "HELLO";
}
Or more commonly one defines function interfaces in terms of
std::ostream& references, which can be used for all kind of streams.
>
>> Printing to STDOUT seems to me a kind of niche facility which is used
>> pretty rarely during large parts of C++ development.
>
> You can say that about lots of features.
Yes I can. C++ has lots and lots of features.
> One of my favourite features of
> my own is Stop:
>
> stop # equivalent to stop 0
> stop N
>
> which may be implemented via exit(N) or ProcessExit or whatever. It
> might be used a tiny number of times in a program, or none at all.
>
> That doesn't mean it shouldn't be user-friendly. Now apply that thinking
> to more features...
Until someone wants to encode a nice loop like that:
stop = false;
while (!stop) {
// do something
}
Then it becomes clear you have hijacked a perfectly nice 4-letter name
so it cannot be used any more for other purposes.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-21 16:26 +0100 |
| Message-ID | <sictii$8tg$1@dont-email.me> |
| In reply to | #81371 |
On 21/09/2021 15:09, Paavo Helde wrote:
> 21.09.2021 16:37 Bart kirjutas:
>> On 21/09/2021 13:45, Paavo Helde wrote:
>
>> I virtually never use STDERR, mainly because I've no idea how to do so
>> outside of C, or via fprintf from a FFI. Even when writing C, it's
>> just not a thing for me. STDOUT is already used for logging, error
>> messages, everthing.
>
> Well that's just plain wrong.
>
>> In C++, how do you conditionally output to either STDOUT or STDERR?
>> This doesn't work:
>>
>> auto F = (cond ? stdout : stderr);
>> F << "HELLO";
>
> It works if you use C++ names and syntax:
>
> #include <iostream>
> int main() {
> bool cond = false;
> (cond ? std::cout : std::cerr) << "HELLO";
> }
>
> Or more commonly one defines function interfaces in terms of
> std::ostream& references, which can be used for all kind of streams.
This is what I initially tried:
auto fred=std::cout;
fred << "Hello, world!\n";
}
The point was to end up with a variable that refers to STDOUT or STDERR,
that can be passed to functions for example.
>> One of my favourite features of my own is Stop:
>>
>> stop # equivalent to stop 0
>> stop N
> Until someone wants to encode a nice loop like that:
>
> stop = false;
> while (!stop) {
> // do something
> }
>
> Then it becomes clear you have hijacked a perfectly nice 4-letter name
> so it cannot be used any more for other purposes.
You mean, like 'exit'?! 'exit' in my languages is used for loop break.
It causes problems when I want to use C's exit() as portable way to
terminate my program. "exit" is exported by the C library.
(I have to define it as `exit instead, which allows the use of reserved
words or case-sensitive names.)
Your example can be dealt with using a different tense (actual code):
repeat
khandlertable[pcptr^]^()
until stopped
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-21 18:04 +0200 |
| Message-ID | <sicvqr$q4e$1@dont-email.me> |
| In reply to | #81372 |
On 21/09/2021 17:26, Bart wrote:
> On 21/09/2021 15:09, Paavo Helde wrote:
>> 21.09.2021 16:37 Bart kirjutas:
>>> On 21/09/2021 13:45, Paavo Helde wrote:
>>
>>> I virtually never use STDERR, mainly because I've no idea how to do
>>> so outside of C, or via fprintf from a FFI. Even when writing C, it's
>>> just not a thing for me. STDOUT is already used for logging, error
>>> messages, everthing.
>>
>> Well that's just plain wrong.
>>
>>> In C++, how do you conditionally output to either STDOUT or STDERR?
>>> This doesn't work:
>>>
>>> auto F = (cond ? stdout : stderr);
>>> F << "HELLO";
>>
>> It works if you use C++ names and syntax:
>>
>> #include <iostream>
>> int main() {
>> bool cond = false;
>> (cond ? std::cout : std::cerr) << "HELLO";
>> }
>>
>> Or more commonly one defines function interfaces in terms of
>> std::ostream& references, which can be used for all kind of streams.
>
> This is what I initially tried:
>
> auto fred=std::cout;
> fred << "Hello, world!\n";
> }
>
> The point was to end up with a variable that refers to STDOUT or STDERR,
> that can be passed to functions for example.
>
"auto fred = std::cout;" will make "fred" a copy of the value of
"std::cout". What you want is a reference, so that you are referring to
the real output stream:
#include <iostream>
int main() {
bool cond = false;
auto& fred = (cond ? std::cout : std::cerr);
fred << "HELLO\n";
}
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-09-21 11:51 -0700 |
| Message-ID | <87lf3poj8q.fsf@nosuchdomain.example.com> |
| In reply to | #81378 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> "auto fred = std::cout;" will make "fred" a copy of the value of
> "std::cout".
No it won't. There's no assignment operator for std::basic_ostream.
> What you want is a reference, so that you are referring to
> the real output stream:
>
> #include <iostream>
> int main() {
> bool cond = false;
> auto& fred = (cond ? std::cout : std::cerr);
> fred << "HELLO\n";
> }
Right. And if you want to change fred later, you can use a pointer
(smart or otherwise).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-22 11:09 +0200 |
| Message-ID | <siert5$cn5$2@dont-email.me> |
| In reply to | #81389 |
On 21/09/2021 20:51, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> "auto fred = std::cout;" will make "fred" a copy of the value of
>> "std::cout".
>
> No it won't. There's no assignment operator for std::basic_ostream.
Sorry. I had assumed that Bart had compiled the code he posted. (I
don't use iostreams in my small-systems embedded code, so I don't know
all the details of code that I wouldn't write even if I did use them.)
>
>> What you want is a reference, so that you are referring to
>> the real output stream:
>>
>> #include <iostream>
>> int main() {
>> bool cond = false;
>> auto& fred = (cond ? std::cout : std::cerr);
>> fred << "HELLO\n";
>> }
>
> Right. And if you want to change fred later, you can use a pointer
> (smart or otherwise).
>
Yes.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-21 15:38 +0000 |
| Message-ID | <v%m2J.32477$6U3.2789@fx43.iad> |
| In reply to | #81371 |
Paavo Helde <myfirstname@osa.pri.ee> writes:
>21.09.2021 16:37 Bart kirjutas:
>Until someone wants to encode a nice loop like that:
>
>stop = false;
>while (!stop) {
> // do something
>}
>
>Then it becomes clear you have hijacked a perfectly nice 4-letter name
>so it cannot be used any more for other purposes.
>
He could resurrect COBOL's "STOP RUN" instead of Fortran's "STOP". :-)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-21 15:36 +0000 |
| Message-ID | <PZm2J.32476$6U3.26291@fx43.iad> |
| In reply to | #81370 |
Bart <bc@freeuk.com> writes: >On 21/09/2021 13:45, Paavo Helde wrote: >> There are some messages to STDERR though, in critical conditions like >> memory exhaustion. How do you write a message to STDERR with your >> 'println'? It's not obvious at all, unlike for std::cout vs std::cerr. > >I virtually never use STDERR, mainly because I've no idea how to do so >outside of C, or via fprintf from a FFI. Even when writing C, it's just >not a thing for me. STDOUT is already used for logging, error messages, >everthing. Another reason not to use your "language". hint: 'fprintf(stderr, ...' The utility guidelines require diagnostic messages go to stderr with non-diagnostic output to stdout. This is been the case for a half century for extremely good reasons.
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-21 15:49 +0000 |
| Message-ID | <sicuv5$16q7$1@gioia.aioe.org> |
| In reply to | #81373 |
On Tue, 21 Sep 2021 15:36:15 GMT scott@slp53.sl.home (Scott Lurndal) wrote: >Bart <bc@freeuk.com> writes: >>On 21/09/2021 13:45, Paavo Helde wrote: > >>> There are some messages to STDERR though, in critical conditions like >>> memory exhaustion. How do you write a message to STDERR with your >>> 'println'? It's not obvious at all, unlike for std::cout vs std::cerr. >> >>I virtually never use STDERR, mainly because I've no idea how to do so >>outside of C, or via fprintf from a FFI. Even when writing C, it's just >>not a thing for me. STDOUT is already used for logging, error messages, >>everthing. > >Another reason not to use your "language". > >hint: 'fprintf(stderr, ...' > >The utility guidelines require diagnostic messages go to stderr with >non-diagnostic output to stdout. This is been the case for a half >century for extremely good reasons. He's probably spent too long in an academic ivory tower and doesn't understand the use case for standard program output to go to one place while the error stream is directed elsewhere.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-21 16:21 +0000 |
| Message-ID | <0En2J.41232$ol1.4871@fx42.iad> |
| In reply to | #81377 |
HorseyWorsey@the_stables.com writes: >On Tue, 21 Sep 2021 15:36:15 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: >>Bart <bc@freeuk.com> writes: >>>On 21/09/2021 13:45, Paavo Helde wrote: >> >>>> There are some messages to STDERR though, in critical conditions like >>>> memory exhaustion. How do you write a message to STDERR with your >>>> 'println'? It's not obvious at all, unlike for std::cout vs std::cerr. >>> >>>I virtually never use STDERR, mainly because I've no idea how to do so >>>outside of C, or via fprintf from a FFI. Even when writing C, it's just >>>not a thing for me. STDOUT is already used for logging, error messages, >>>everthing. >> >>Another reason not to use your "language". >> >>hint: 'fprintf(stderr, ...' >> >>The utility guidelines require diagnostic messages go to stderr with >>non-diagnostic output to stdout. This is been the case for a half >>century for extremely good reasons. > >He's probably spent too long in an academic ivory tower and doesn't understand >the use case for standard program output to go to one place while the error >stream is directed elsewhere. People in the "academic ivory tower" are directly responsible for the state of the art today. Djikstra, Wirth, Atanasoff, Patterson, Diffie, Helman, Rivest, Shamir, Adelman, Aho, Ullman, the exceptional Leslie Lamport and thousands of others. Bart has never even been _close_ to an ivory tower.
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-22 09:21 +0000 |
| Message-ID | <siesje$1tj3$1@gioia.aioe.org> |
| In reply to | #81379 |
On Tue, 21 Sep 2021 16:21:16 GMT scott@slp53.sl.home (Scott Lurndal) wrote: >HorseyWorsey@the_stables.com writes: >>On Tue, 21 Sep 2021 15:36:15 GMT >>scott@slp53.sl.home (Scott Lurndal) wrote: >>>Bart <bc@freeuk.com> writes: >>>>On 21/09/2021 13:45, Paavo Helde wrote: >>> >>>>> There are some messages to STDERR though, in critical conditions like >>>>> memory exhaustion. How do you write a message to STDERR with your >>>>> 'println'? It's not obvious at all, unlike for std::cout vs std::cerr. >>>> >>>>I virtually never use STDERR, mainly because I've no idea how to do so >>>>outside of C, or via fprintf from a FFI. Even when writing C, it's just >>>>not a thing for me. STDOUT is already used for logging, error messages, >>>>everthing. >>> >>>Another reason not to use your "language". >>> >>>hint: 'fprintf(stderr, ...' >>> >>>The utility guidelines require diagnostic messages go to stderr with >>>non-diagnostic output to stdout. This is been the case for a half >>>century for extremely good reasons. >> >>He's probably spent too long in an academic ivory tower and doesn't understand > >>the use case for standard program output to go to one place while the error >>stream is directed elsewhere. > >People in the "academic ivory tower" are directly responsible for the >state of the art today. Djikstra, Wirth, Atanasoff, Patterson, >Diffie, Helman, Rivest, Shamir, Adelman, Aho, Ullman, the exceptional Leslie >Lamport >and thousands of others. And many who weren't. Dennis Richie and Stroustrup both worked at Bell labs, Unix was created by AT&T, SQL by IBM, Java by Sun, Bill Gates was a Harvard dropout etc.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-21 17:45 +0100 |
| Message-ID | <sid285$cjg$1@dont-email.me> |
| In reply to | #81373 |
On 21/09/2021 16:36, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 21/09/2021 13:45, Paavo Helde wrote: > >>> There are some messages to STDERR though, in critical conditions like >>> memory exhaustion. How do you write a message to STDERR with your >>> 'println'? It's not obvious at all, unlike for std::cout vs std::cerr. >> >> I virtually never use STDERR, mainly because I've no idea how to do so >> outside of C, or via fprintf from a FFI. Even when writing C, it's just >> not a thing for me. STDOUT is already used for logging, error messages, >> everthing. > > Another reason not to use your "language". > > hint: 'fprintf(stderr, ...' > > The utility guidelines require diagnostic messages go to stderr with > non-diagnostic output to stdout. This is been the case for a half > century for extremely good reasons. > Somebody should tell Microsoft then. Their CL compiler shows error messages on stdout no stderr. So does DMC, Walter Bright's C compiler. As does mine, since I consider the console the error device. However getting STDERR on Windows, if you're not using C, is not actually that easy. The WinAPI provides GetStdHandle to retrieve a suitable error handler, but that only works if also using WinAPI for all console output, using that handle. I like to do console output via printf in msvcrt.dll, but that doesn't provide a means that I can see, to get a compatible value of its stderr through its DLL interface. (Other than using non-portable means to directly access the FILE structures via __iob_func(), since on Windows, stdout etc are not just small integers.) However, this is not specifically about my language nor about Windows. Somebody asked, how to do STDERR output via a syntax based on 'print a,b,c'; and I showed how - same as doing output to a file.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-21 17:02 +0000 |
| Message-ID | <Neo2J.113131$lC6.52690@fx41.iad> |
| In reply to | #81381 |
Bart <bc@freeuk.com> writes:
>On 21/09/2021 16:36, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 21/09/2021 13:45, Paavo Helde wrote:
>>
>>>> There are some messages to STDERR though, in critical conditions like
>>>> memory exhaustion. How do you write a message to STDERR with your
>>>> 'println'? It's not obvious at all, unlike for std::cout vs std::cerr.
>>>
>>> I virtually never use STDERR, mainly because I've no idea how to do so
>>> outside of C, or via fprintf from a FFI. Even when writing C, it's just
>>> not a thing for me. STDOUT is already used for logging, error messages,
>>> everthing.
>>
>> Another reason not to use your "language".
>>
>> hint: 'fprintf(stderr, ...'
>>
>> The utility guidelines require diagnostic messages go to stderr with
>> non-diagnostic output to stdout. This is been the case for a half
>> century for extremely good reasons.
>>
>
>Somebody should tell Microsoft then.
Feel free. stdout and stderr, and the rules for their usage predate
MSDOS and were in existence long before microsoft produced a C compiler.
https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05
"At program start-up, three streams are predefined and need not be
opened explicitly: standard input (for reading conventional input),
standard output (for writing conventional output), and standard error
(for writing diagnostic output). When opened, the standard error stream
is not fully buffered; the standard input and standard output streams
are fully buffered if and only if the stream can be determined not to
refer to an interactive device."
C Standard, while not explicitly stating such, implies it.
n1256.pdf:
void error(char *function_name, char *format, ...)
{
va_list args;
va_start(args, format);
// print out name of function causing error
fprintf(stderr, "ERROR in %s: ", function_name);
// print out remainder of message
vfprintf(stderr, format, args);
va_end(args);
}
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-21 18:16 +0100 |
| Message-ID | <sid41u$rb1$1@dont-email.me> |
| In reply to | #81382 |
On 21/09/2021 18:02, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 21/09/2021 16:36, Scott Lurndal wrote: >>> Bart <bc@freeuk.com> writes: >>>> On 21/09/2021 13:45, Paavo Helde wrote: >>> >>>>> There are some messages to STDERR though, in critical conditions like >>>>> memory exhaustion. How do you write a message to STDERR with your >>>>> 'println'? It's not obvious at all, unlike for std::cout vs std::cerr. >>>> >>>> I virtually never use STDERR, mainly because I've no idea how to do so >>>> outside of C, or via fprintf from a FFI. Even when writing C, it's just >>>> not a thing for me. STDOUT is already used for logging, error messages, >>>> everthing. >>> >>> Another reason not to use your "language". >>> >>> hint: 'fprintf(stderr, ...' >>> >>> The utility guidelines require diagnostic messages go to stderr with >>> non-diagnostic output to stdout. This is been the case for a half >>> century for extremely good reasons. >>> >> >> Somebody should tell Microsoft then. > > Feel free. stdout and stderr, and the rules for their usage predate > MSDOS and were in existence long before microsoft produced a C compiler. > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05 > > "At program start-up, three streams are predefined and need not be > opened explicitly: standard input (for reading conventional input), > standard output (for writing conventional output), and standard error > (for writing diagnostic output). When opened, the standard error stream > is not fully buffered; the standard input and standard output streams > are fully buffered if and only if the stream can be determined not to > refer to an interactive device." It's not clear what that document is about, but seems to refer to a lot of C headers. In case of a C (or C++) compiler and where it writes its output, who's to say what language it might be written in. It might even be a cross-compiler running on a system where your document has no jurisdiction. > Feel free. stdout and stderr, and the rules for their usage predate > MSDOS and were in existence long before microsoft produced a C compiler. > Well I've never heard of any such rules. They probably emanated from the same place that inflicted case-sensivity and 0-baseness on everyone.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-09-21 11:53 -0700 |
| Message-ID | <87h7edoj4v.fsf@nosuchdomain.example.com> |
| In reply to | #81384 |
Bart <bc@freeuk.com> writes:
> On 21/09/2021 18:02, Scott Lurndal wrote:
[...]
>> Feel free. stdout and stderr, and the rules for their usage predate
>> MSDOS and were in existence long before microsoft produced a C compiler.
>
> Well I've never heard of any such rules.
[...]
So now you've learned something.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-21 20:48 +0100 |
| Message-ID | <sidcv5$ukn$1@dont-email.me> |
| In reply to | #81391 |
On 21/09/2021 19:53, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 21/09/2021 18:02, Scott Lurndal wrote: > [...] >>> Feel free. stdout and stderr, and the rules for their usage predate >>> MSDOS and were in existence long before microsoft produced a C compiler. >> >> Well I've never heard of any such rules. > [...] > > So now you've learned something. > Not really. The rules apply to what, exactly: a specific OS, ALL OSes, a specific language, ALL languages, some library..... I think somebody is making a few assumptions. The fact is, when I write an application then it does what I say. And /I/ decide how any error handling is to be performed.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-21 20:23 +0000 |
| Message-ID | <mbr2J.115516$rl3.2933@fx45.iad> |
| In reply to | #81393 |
Bart <bc@freeuk.com> writes: >On 21/09/2021 19:53, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >>> On 21/09/2021 18:02, Scott Lurndal wrote: >> [...] >>>> Feel free. stdout and stderr, and the rules for their usage predate >>>> MSDOS and were in existence long before microsoft produced a C compiler. >>> >>> Well I've never heard of any such rules. >> [...] >> >> So now you've learned something. >> > > >Not really. The rules apply to what, exactly: a specific OS, ALL OSes, a >specific language, ALL languages, some library..... > >I think somebody is making a few assumptions. You should stop doing that. > >The fact is, when I write an application then it does what I say. And >/I/ decide how any error handling is to be performed. It has already been pointed out to you the reasoning behind the rule. Specifically to support pipelining the output of one command into another without interleaving diagnostic messages. $ cat /path/to/file | egrep -w '^fred|^joe|^sam' > list-of-lines-starting-with-fred-joe-or-sam Any diagnostics from cat or grep will go to stderr, not to the pipeline.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-21 23:29 +0100 |
| Message-ID | <sidmd7$usi$1@dont-email.me> |
| In reply to | #81394 |
On 21/09/2021 21:23, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 21/09/2021 19:53, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >>>> On 21/09/2021 18:02, Scott Lurndal wrote: >>> [...] >>>>> Feel free. stdout and stderr, and the rules for their usage predate >>>>> MSDOS and were in existence long before microsoft produced a C compiler. >>>> >>>> Well I've never heard of any such rules. >>> [...] >>> >>> So now you've learned something. >>> >> >> >> Not really. The rules apply to what, exactly: a specific OS, ALL OSes, a >> specific language, ALL languages, some library..... >> >> I think somebody is making a few assumptions. > > You should stop doing that. > >> >> The fact is, when I write an application then it does what I say. And >> /I/ decide how any error handling is to be performed. > > It has already been pointed out to you the reasoning behind > the rule. Specifically to support pipelining the output of > one command into another without interleaving diagnostic > messages. > > $ cat /path/to/file | egrep -w '^fred|^joe|^sam' > list-of-lines-starting-with-fred-joe-or-sam > > Any diagnostics from cat or grep will go to stderr, not to the pipeline. > OK, so primarily to suit Unix utilities. That's fine. I don't use Unix. I don't write utilities that take text input from pipes and write output to another pipe. There's usually more going on and I make my own arrangements for generating and displaying any diagnostics.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-09-21 13:47 -0700 |
| Message-ID | <878rzpoduk.fsf@nosuchdomain.example.com> |
| In reply to | #81393 |
Bart <bc@freeuk.com> writes:
> On 21/09/2021 19:53, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 21/09/2021 18:02, Scott Lurndal wrote:
>> [...]
>>>> Feel free. stdout and stderr, and the rules for their usage predate
>>>> MSDOS and were in existence long before microsoft produced a C compiler.
>>>
>>> Well I've never heard of any such rules.
>> [...]
>> So now you've learned something.
>
> Not really. The rules apply to what, exactly: a specific OS, ALL OSes,
> a specific language, ALL languages, some library.....
Right, I shouldn't have assumed that you've learned something.
> I think somebody is making a few assumptions.
The distinction between standard output and standard error (stdout and
stderr in C, std::cout and std::cerr in C++) has been well established
for decades. It's not specific to C++, and therefore not specific to
this newsgroup. It originated in early UNIX, and possibly from
Fortran before that, and has been adopted by some other operating
systems including Windows, though Windows programs often don't make as
much use of either stdout or stderr as typical Unix/Linux programs do.
The distinction isn't always 100% clear. I would certainly call
printing error messages to stdout incorrect behavior. Usage messages
(the output of `some_command -h` or `some_command --help`, for example)
are sometimes a corner case, especially if they can be printed either as
the result of a specific request or because an option name was
misspelled.
I suggest you go off and do some research before telling us that we're
wrong about something we've been using for decades and you've only
recently learned about. There are even Wikipedia articles.
> The fact is, when I write an application then it does what I say. And
> /I/ decide how any error handling is to be performed.
Yes, and if you don't care about following long established conventions,
you can certainly do that.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
Back to top | Article view | comp.lang.c++
csiph-web