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 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-21 20:11 +0300 |
| Message-ID | <sid3oa$oo1$1@dont-email.me> |
| In reply to | #81381 |
21.09.2021 19:45 Bart kirjutas: > 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. That's easy to check: c:\tmp>"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\bin\Hostx64\x64\CL.exe" /BLABLA >out.txt 2>err.txt c:\tmp>type out.txt c:\tmp>type err.txt Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29913 for x64 Copyright (C) Microsoft Corporation. All rights reserved. cl : Command line warning D9002 : ignoring unknown option '/BLABLA' cl : Command line error D8003 : missing source filename This shows CL compiler indeed reports errors to stderr, as it should. It also reports its name and copyright message to stderr, to avoid polluting stdout. This is common practice. Maybe you are confusing the errors appearing in the compiler with the diagnostic messages reported about the compiled programs? The latters constitute the compiler output, so indeed should appear in stdout (and they do).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-21 18:33 +0100 |
| Message-ID | <sid50m$2s2$1@dont-email.me> |
| In reply to | #81383 |
On 21/09/2021 18:11, Paavo Helde wrote:
> 21.09.2021 19:45 Bart kirjutas:
>> 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.
>
> That's easy to check:
>
> c:\tmp>"C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\bin\Hostx64\x64\CL.exe"
> /BLABLA >out.txt 2>err.txt
>
> c:\tmp>type out.txt
>
> c:\tmp>type err.txt
> Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29913 for x64
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> cl : Command line warning D9002 : ignoring unknown option '/BLABLA'
> cl : Command line error D8003 : missing source filename
>
>
> This shows CL compiler indeed reports errors to stderr, as it should. It
> also reports its name and copyright message to stderr, to avoid
> polluting stdout. This is common practice.
>
> Maybe you are confusing the errors appearing in the compiler with the
> diagnostic messages reported about the compiled programs? The latters
> constitute the compiler output, so indeed should appear in stdout (and
> they do).
Here's what I get:
C:\c>type c.c
int main(void) {
print a,b,c;
}
C:\c>cl c.c >out.txt 2>err.txt
C:\c>type out.txt
c.c
c.c(2): error C2065: 'print': undeclared identifier
c.c(2): error C2146: syntax error: missing ';' before identifier 'a'
c.c(2): error C2065: 'a': undeclared identifier
c.c(2): error C2065: 'b': undeclared identifier
c.c(2): error C2065: 'c': undeclared identifier
C:\c>type err.txt
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29337 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
> Maybe you are confusing the errors appearing in the compiler with the
> diagnostic messages reported about the compiled programs? The latters
> constitute the compiler output, so indeed should appear in stdout (and
> they do).
So what you are saying is that CL is doing the right thing? The
copyright messages go to STDERR, while actual program *error messages*
go to STDOUT?
Which is the opposite to what happens with gcc:
C:\c>gcc c.c --verbose >out.txt 2>err.txt
C:\c>type out.txt
C:\c>type err.txt
Using built-in specs.
COLLECT_GCC=gcc
.... <snip long output>
c.c: In function 'main':
c.c:2:5: error: unknown type name 'print'; did you mean 'int'?
2 | print a,b,c;
| ^~~~~
| int
Although that doesn't quite get it right either: it sends ALL its output
to STDERR, even informative messages, and nothing at all to STDOUT.
Two major compilers and /they/ don't know how to handle STDOUT and STDERR!
I said I'm not interested in separate output streams (when running GUI
programs I used a console for special messages; I didn't need two
consoles!), but if I was to use both STDOUT and STDERR, at least I would
get it right.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-21 20:43 +0300 |
| Message-ID | <sid5kt$7cm$1@dont-email.me> |
| In reply to | #81385 |
21.09.2021 20:33 Bart kirjutas: > > Two major compilers and /they/ don't know how to handle STDOUT and STDERR! Hint: if everybody else seems to drive on the wrong side of the highway, it might be a time for little self-contemplation.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-21 18:59 +0100 |
| Message-ID | <sid6he$dv1$1@dont-email.me> |
| In reply to | #81386 |
On 21/09/2021 18:43, Paavo Helde wrote: > 21.09.2021 20:33 Bart kirjutas: >> >> Two major compilers and /they/ don't know how to handle STDOUT and >> STDERR! > > Hint: if everybody else seems to drive on the wrong side of the highway, > it might be a time for little self-contemplation. So to be clear: * Copyright messages from CL belong in STDERR * Informative messages from gcc belong in STDERR * Program Error messages from CL belong in STDOUT * Program Error messages from gcc belong in STDERR You are saying this behaviour is correct, not crazy nor conflicting at all, and it's time for ME to do self-comtemplation? Just checking...
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-21 21:20 +0300 |
| Message-ID | <sid7q0$o69$1@dont-email.me> |
| In reply to | #81387 |
21.09.2021 20:59 Bart kirjutas: > On 21/09/2021 18:43, Paavo Helde wrote: >> 21.09.2021 20:33 Bart kirjutas: >>> >>> Two major compilers and /they/ don't know how to handle STDOUT and >>> STDERR! >> >> Hint: if everybody else seems to drive on the wrong side of the >> highway, it might be a time for little self-contemplation. > > > So to be clear: > > * Copyright messages from CL belong in STDERR > > * Informative messages from gcc belong in STDERR > > * Program Error messages from CL belong in STDOUT > > * Program Error messages from gcc belong in STDERR Error messages from compiler belong to STDERR. Diagnostic messages (errors and warnings) about compiled programs can be either way, depending on what is considered the main output from the compiler. > > You are saying this behaviour is correct, not crazy nor conflicting at > all, and it's time for ME to do self-comtemplation? Yes. These rules have a simple and sound reason: if the program is producing some output which can be potentially post-processed programmatically by another program, then everything not belonging to this output must be sent to stderr, to avoid garbling the output. Gcc manpage contains examples how to send assembler or other output to stdout, so it makes sense for them to send all diagnostics to stderr to avoid garbling.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-21 20:32 +0100 |
| Message-ID | <sidc15$nmd$1@dont-email.me> |
| In reply to | #81388 |
On 21/09/2021 19:20, Paavo Helde wrote: > 21.09.2021 20:59 Bart kirjutas: >> On 21/09/2021 18:43, Paavo Helde wrote: >>> 21.09.2021 20:33 Bart kirjutas: >>>> >>>> Two major compilers and /they/ don't know how to handle STDOUT and >>>> STDERR! >>> >>> Hint: if everybody else seems to drive on the wrong side of the >>> highway, it might be a time for little self-contemplation. >> >> >> So to be clear: >> >> * Copyright messages from CL belong in STDERR >> >> * Informative messages from gcc belong in STDERR >> >> * Program Error messages from CL belong in STDOUT >> >> * Program Error messages from gcc belong in STDERR > > Error messages from compiler belong to STDERR. Diagnostic messages > (errors and warnings) about compiled programs can be either way, > depending on what is considered the main output from the compiler. > >> >> You are saying this behaviour is correct, not crazy nor conflicting at >> all, and it's time for ME to do self-comtemplation? > > Yes. These rules have a simple and sound reason: if the program is > producing some output which can be potentially post-processed > programmatically by another program, then everything not belonging to > this output must be sent to stderr, to avoid garbling the output. > > Gcc manpage contains examples how to send assembler or other output to > stdout, so it makes sense for them to send all diagnostics to stderr to > avoid garbling. > > I'm still not clear. Is what MS' CL is doing correct or not: sending program error messages to STDOUT instead of STDERR as gcc does? Because I don't understand how they can both be right if they are doing opposite things; ONE of them must be wrong! I'm getting the feeling that someone here is winding me up...
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-21 20:24 +0000 |
| Message-ID | <ccr2J.115517$rl3.16198@fx45.iad> |
| In reply to | #81392 |
Bart <bc@freeuk.com> writes: > >I'm still not clear. Is what MS' CL is doing correct or not: sending >program error messages to STDOUT instead of STDERR as gcc does? As with most microsoft software, CL is broken if it behaves as you describe.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-21 18:52 +0000 |
| Message-ID | <SRp2J.43114$md6.9128@fx36.iad> |
| In reply to | #81387 |
Bart <bc@freeuk.com> writes: >On 21/09/2021 18:43, Paavo Helde wrote: >> 21.09.2021 20:33 Bart kirjutas: >>> >>> Two major compilers and /they/ don't know how to handle STDOUT and >>> STDERR! >> >> Hint: if everybody else seems to drive on the wrong side of the highway, >> it might be a time for little self-contemplation. > > >So to be clear: > > * Copyright messages from CL belong in STDERR > > * Informative messages from gcc belong in STDERR > > * Program Error messages from CL belong in STDOUT > > * Program Error messages from gcc belong in STDERR > >You are saying this behaviour is correct, not crazy nor conflicting at >all, and it's time for ME to do self-comtemplation? The output of GCC is an object file. Any other output is diagnostic output and rightly belongs on stderr.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2021-09-21 18:34 +0200 |
| Message-ID | <iqufrtFonc1U1@mid.individual.net> |
| In reply to | #81367 |
On 2021-09-21 at 12:12, Bart wrote: > On 21/09/2021 08:39, David Brown wrote: >> On 20/09/2021 22:38, Bart wrote: > >>> But to talk with some knowledge about how Print might be better >>> implemented in any language, you really need to have tried implementing >>> Print within a language, and specifically implementing it as a built-in >>> feature >> >> No one cares about how easy or hard it is to implement. > > You're changing the goalposts. You said my opinion wasn't an informed > one, when I was talking about the deficiences of both cout and printf > approaches. > > >> A BASIC-style print statement is fine >> for BASIC-style languages - typically designed to be quick and simple >> for easy tasks, but unsuitable for bigger work or more complex work, or >> programs that don't fit into the simple sequence of start program, read >> files and/or keyboard, print to screen and/or files, stop program. > > 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? Yes, it makes it extendable to new types. My types specifically. > > >> But for a language that supports multiple types, formatting, >> translations, redirected outputs, systems without a console, etc., then >> a simple print statement won't do. It is both too much, and too little. > > You're making this up aren't you? > > Simple Print doesn't mean an inability to do anything. It means being > able to do most of it, but in a simpler manner with a lot less typing! > So now we get one more way to do the exact same thing, just a bit shorter. I can already see the next post saying that C++ is now even bigger and harder too learn. And when I change a typedef, suddenly all my print statements stop working. Why?
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-21 01:16 +0300 |
| Message-ID | <sib176$b12$1@dont-email.me> |
| In reply to | #81348 |
20.09.2021 20:39 Bart kirjutas: > You don't need to know C++ inside out to have an opinion about it or > about language design, or for it to help you in knowing which avenues > not to pursue, since you can see how it's ended up: in a vastly complex > and cumbersome language near-impossible for an individual to implement. Well, that's the point. A lot of complexity is packed away in the language so that all programmers can make use of it and build upon it. There are valid concerns about C++ becoming too cumbersome or too complicated, but these are in no way related to how many individuals it takes to implement the language, that's just a non-goal. How many individuals it took to build the airplane you last used? Even your bicycle was most probably built by more than one person.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-21 00:39 +0100 |
| Message-ID | <sib62t$1ob$1@dont-email.me> |
| In reply to | #81357 |
On 20/09/2021 23:16, Paavo Helde wrote: > 20.09.2021 20:39 Bart kirjutas: >> You don't need to know C++ inside out to have an opinion about it or >> about language design, or for it to help you in knowing which avenues >> not to pursue, since you can see how it's ended up: in a vastly >> complex and cumbersome language near-impossible for an individual to >> implement. > > Well, that's the point. A lot of complexity is packed away in the > language so that all programmers can make use of it and build upon it. > > There are valid concerns about C++ becoming too cumbersome or too > complicated, but these are in no way related to how many individuals it > takes to implement the language, that's just a non-goal. > How many > individuals it took to build the airplane you last used? Even your > bicycle was most probably built by more than one person. Well, the pencil on my desk was probably also made by more than one person! While the bike probably /could/ be made by an individual. If the equivalent of my everyday Print task is going to the shops to buy some milk, then you will find a bicycle more apt for that purpose than an airplane. I just don't see the need for a programming language to be so complex that it takes many man-years to implement it. I like my tools lightweight. This is not just about Print either; everything in C++ seems designed to be the opposite of simple. That's why I said I look at C++ to find out how /not/ to do things.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-09-22 23:45 +0200 |
| Message-ID | <sig84u$14am$1@gioia.aioe.org> |
| In reply to | #81347 |
On 9/20/2021 6:08 PM, David Brown wrote: > On 20/09/2021 17:11, Bart wrote: <snip> >> >> My view is that basic Print is a fundamental feature that needs to be >> natively supported by the core language. Then it can be kept streamlined >> without wasting too much compiler time on it. > > That's your view. It is not unique to you, but it is not the view of > many other people. > Actually this view was (and still is) shared by the creators of C and of C++. In fact, that is the only reason (every language should have it as an unavoidable axiom) that I can see for C to have a function like printf: as a systems language, you don't need formatting support, you just need the ability to send chars to some device. But, since it is such a widely spread convenience, they decided to put something in the standard library. C++ tried to improve with iostreams, it was a genuine attempt, but the result proved unpleasant. (In other words, string formatting is properly a UI feature, so if you seriously need it, get some serious UI library, which has intentionally been left out of C and C++; or, if you have specific and limited needs, write it yourself) The key point is the word "basic" in Bart's sentence - it is the same as "easy to use", what does it mean? Definitions like this are obviously subjective, and they're a sure path to disagreement. I remember once some team was working on building support for some type of device into some system - integration would consist of controlling the device from C code, the system's language. The team was asked by management about the requirements for the device; the requirements came out along the lines of "it should be easy to use". The result was that management bought a device that could be driven by Excel.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-22 23:51 +0200 |
| Message-ID | <sig8gb$iph$1@dont-email.me> |
| In reply to | #81432 |
On 22/09/2021 23:45, Manfred wrote: > On 9/20/2021 6:08 PM, David Brown wrote: >> On 20/09/2021 17:11, Bart wrote: > <snip> >>> >>> My view is that basic Print is a fundamental feature that needs to be >>> natively supported by the core language. Then it can be kept streamlined >>> without wasting too much compiler time on it. >> >> That's your view. It is not unique to you, but it is not the view of >> many other people. >> > > Actually this view was (and still is) shared by the creators of C and of > C++. It is not part of the core language. It is part of the standard library. That's a very different thing. In particular, the great majority of printf implementations are written in C, the great majority of iostream implementations are written in C++. (Implementation-specific behaviour might be needed.) Printing is not a special statement in either language - it is handled by library functions that are optional (small embedded systems often don't use them, for example), and can be replaced by alternatives.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-09-23 18:42 +0200 |
| Message-ID | <siiapf$1g4h$1@gioia.aioe.org> |
| In reply to | #81433 |
On 9/22/2021 11:51 PM, David Brown wrote: > On 22/09/2021 23:45, Manfred wrote: >> On 9/20/2021 6:08 PM, David Brown wrote: >>> On 20/09/2021 17:11, Bart wrote: >> <snip> >>>> >>>> My view is that basic Print is a fundamental feature that needs to be >>>> natively supported by the core language. Then it can be kept streamlined >>>> without wasting too much compiler time on it. >>> >>> That's your view. It is not unique to you, but it is not the view of >>> many other people. >>> >> >> Actually this view was (and still is) shared by the creators of C and of >> C++. > > It is not part of the core language. It is part of the standard > library. That's a very different thing. In particular, the great > majority of printf implementations are written in C, the great majority > of iostream implementations are written in C++. > (Implementation-specific behaviour might be needed.) Printing is not a > special statement in either language - it is handled by library > functions that are optional (small embedded systems often don't use > them, for example), and can be replaced by alternatives. > Agreed. My point is about having it in the language as in the "language specification", which includes the standard library, a broader sense than yours. It appears that we agree that printing support (or formatting, as I wrote afterwards) is not strictly needed from the language as long as it offers the means, if you need it, to build or integrate alternatives according to your needs.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-23 21:52 +0200 |
| Message-ID | <siiluf$unh$1@dont-email.me> |
| In reply to | #81473 |
On 23/09/2021 18:42, Manfred wrote: > On 9/22/2021 11:51 PM, David Brown wrote: >> On 22/09/2021 23:45, Manfred wrote: >>> On 9/20/2021 6:08 PM, David Brown wrote: >>>> On 20/09/2021 17:11, Bart wrote: >>> <snip> >>>>> >>>>> My view is that basic Print is a fundamental feature that needs to be >>>>> natively supported by the core language. Then it can be kept >>>>> streamlined >>>>> without wasting too much compiler time on it. >>>> >>>> That's your view. It is not unique to you, but it is not the view of >>>> many other people. >>>> >>> >>> Actually this view was (and still is) shared by the creators of C and of >>> C++. >> >> It is not part of the core language. It is part of the standard >> library. That's a very different thing. In particular, the great >> majority of printf implementations are written in C, the great majority >> of iostream implementations are written in C++. >> (Implementation-specific behaviour might be needed.) Printing is not a >> special statement in either language - it is handled by library >> functions that are optional (small embedded systems often don't use >> them, for example), and can be replaced by alternatives. >> > > Agreed. > My point is about having it in the language as in the "language > specification", which includes the standard library, a broader sense > than yours. Yes, I can see that. That is why I made the distinction of the /core/ language. That includes statements, expressions, operators, types, etc. It can also language support libraries that come with compilers - for more limited processors, things like floating point might be in a software library. (These are for function calls generated by the compiler, rather than written in the source code.) And some headers would be included as they are required for the language - for example, the language "sizeof" operator evaluates to an expression of type "size_t" defined in <stddef.h>. (One could reasonably argue that it would be better to talk about "freestanding C and C++ environments, rather than "core language" - at least these terms are well defined in the standards.) > > It appears that we agree that printing support (or formatting, as I > wrote afterwards) is not strictly needed from the language as long as it > offers the means, if you need it, to build or integrate alternatives > according to your needs. Yes, indeed. When you have such flexible and general purpose languages as C and C++, then any given solution to printing will be far too big and complicated for some use-cases, and far too small and limited for others. The language has to provide the tools you need to make the solutions you need. And then the standard library can provide one or more printing and formatting systems that suit a wide range of programs, so that you only need to re-invent the wheel when you really need a new one.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-23 00:17 +0100 |
| Message-ID | <sigdhp$i17$1@dont-email.me> |
| In reply to | #81432 |
On 22/09/2021 22:45, Manfred wrote:
> On 9/20/2021 6:08 PM, David Brown wrote:
>> On 20/09/2021 17:11, Bart wrote:
> <snip>
>>>
>>> My view is that basic Print is a fundamental feature that needs to be
>>> natively supported by the core language. Then it can be kept streamlined
>>> without wasting too much compiler time on it.
>>
>> That's your view. It is not unique to you, but it is not the view of
>> many other people.
>>
>
> Actually this view was (and still is) shared by the creators of C and of
> C++.
> In fact, that is the only reason (every language should have it as an
> unavoidable axiom) that I can see for C to have a function like printf:
> as a systems language, you don't need formatting support, you just need
> the ability to send chars to some device.
> But, since it is such a widely spread convenience, they decided to put
> something in the standard library.
> C++ tried to improve with iostreams, it was a genuine attempt, but the
> result proved unpleasant.
>
> (In other words, string formatting is properly a UI feature, so if you
> seriously need it, get some serious UI library, which has intentionally
> been left out of C and C++; or, if you have specific and limited needs,
> write it yourself)
>
> The key point is the word "basic" in Bart's sentence - it is the same as
> "easy to use", what does it mean?
> Definitions like this are obviously subjective, and they're a sure path
> to disagreement.
The first languages I used all had a version of PRINT, needed as the
primary display device was a teletype or VDU, but you also needed to
write to text files (Algol, Fortran, Pascal; even assembly could do it!)
So I find it difficult to get away from the idea that PRINT is anything
but a fundamental feature of a language. Even though applications may
work primarily with a GUI, or without a UI at all. Such an app may still
need to write out a config file ...
... or read one in. Which brings me to something that hasn't been
discussed: basic READ.
This was something that was so easy in the 1970s, and now so hard;
except in my own languages where I keep it simple:
int a, b, c
print "Prompt> "
readln a, b, c
println a, b, c
I tried it in C++ to see how well it coped:
#include <iostream>
int main()
{ int a,b,c;
std::cout << "Prompt> ";
std::cin >> a >> b >> c;
std::cout << a << " " << b << " " << c << "\n";
}
(Just look at that last line; 15 tokens and 35 sig. characters; compare
my 6 tokens and 12 characters...)
Anyway, this was quite poor:
* It doesn't like commas as separators as well as spaces
* If less than 3 numbers are present, it keeps waiting for me to enter
them on a subsequent line; very unfriendly
* If more than 3 are entered, those extra ones are not ignored; on the
next Prompt, those ones form the first part of the input of the new
line, very confusing. This input is supposed to be LINE ORIENTED.
* If I enter 12.34 56 78, it reads 12 for the first number, and zeros
for the next two, and apparently zeros also for all subsequent lines
None of those problems appear in mine:
* It reads at most 3 numbers from the line
* If fewer are present, it'll read them as zeros
* If more, they are ignored. Whatever is entered on one line NEVER
impinges on the next
* Numbers can be separated with commas or spaces
* Entering 12.34 56 78 is well behaved; it reads 12 56 78
There are some weaknesses in my static language version, but most are
fixed in my dynamic version (same code, but no 'int a,b,c'):
* A print item is read as int, float, string or bignum according to what
is entered
* Missing items are read as ""
* A type can be forced if needed
READ is intended as a casual feature to quickly and informally read such
input from a console or file. But it's amazing how accomplished it is
compared with major languages.
I'm sure C++ is also capable of the same things, but how much effort is
it? Do you have to do everything yourself? Maybe there's a Boost library
to do what used to be one line of code with Algol60.
My first programs were student exercises. Then, getting the 3 numbers
the task demanded was the easy bit!
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-23 02:03 +0000 |
| Message-ID | <VfR2J.42368$2B4.1487@fx04.iad> |
| In reply to | #81435 |
On 2021-09-22, Bart <bc@freeuk.com> wrote:
> On 22/09/2021 22:45, Manfred wrote:
>> On 9/20/2021 6:08 PM, David Brown wrote:
>>> On 20/09/2021 17:11, Bart wrote:
>> <snip>
>>>>
>>>> My view is that basic Print is a fundamental feature that needs to be
>>>> natively supported by the core language. Then it can be kept streamlined
>>>> without wasting too much compiler time on it.
>>>
>>> That's your view. It is not unique to you, but it is not the view of
>>> many other people.
>>>
>>
>> Actually this view was (and still is) shared by the creators of C and of
>> C++.
>> In fact, that is the only reason (every language should have it as an
>> unavoidable axiom) that I can see for C to have a function like printf:
>> as a systems language, you don't need formatting support, you just need
>> the ability to send chars to some device.
>> But, since it is such a widely spread convenience, they decided to put
>> something in the standard library.
>> C++ tried to improve with iostreams, it was a genuine attempt, but the
>> result proved unpleasant.
>>
>> (In other words, string formatting is properly a UI feature, so if you
>> seriously need it, get some serious UI library, which has intentionally
>> been left out of C and C++; or, if you have specific and limited needs,
>> write it yourself)
>>
>> The key point is the word "basic" in Bart's sentence - it is the same as
>> "easy to use", what does it mean?
>> Definitions like this are obviously subjective, and they're a sure path
>> to disagreement.
>
> The first languages I used all had a version of PRINT, needed as the
> primary display device was a teletype or VDU, but you also needed to
> write to text files (Algol, Fortran, Pascal; even assembly could do it!)
>
> So I find it difficult to get away from the idea that PRINT is anything
> but a fundamental feature of a language. Even though applications may
> work primarily with a GUI, or without a UI at all. Such an app may still
> need to write out a config file ...
>
> ... or read one in. Which brings me to something that hasn't been
> discussed: basic READ.
>
> This was something that was so easy in the 1970s, and now so hard;
> except in my own languages where I keep it simple:
>
> int a, b, c
> print "Prompt> "
> readln a, b, c
> println a, b, c
>
> I tried it in C++ to see how well it coped:
>
> #include <iostream>
>
> int main()
> { int a,b,c;
> std::cout << "Prompt> ";
> std::cin >> a >> b >> c;
> std::cout << a << " " << b << " " << c << "\n";
> }
>
Same thing.
But there is bug if user enters more or less then three. How you handle
that case?
In Swift:
let values = readLine()?.components(separatedBy: CharacterSet.whitespacesAndNewlines) ?? []
let valueOne = values.count > 0 ? Int(values[0]) : nil
let valueTwo = values.count > 1 ? Int(values[1]) : nil
so this handles correct.
> (Just look at that last line; 15 tokens and 35 sig. characters; compare
> my 6 tokens and 12 characters...)
>
> Anyway, this was quite poor:
>
> * It doesn't like commas as separators as well as spaces
>
> * If less than 3 numbers are present, it keeps waiting for me to enter
> them on a subsequent line; very unfriendly
>
> * If more than 3 are entered, those extra ones are not ignored; on the
> next Prompt, those ones form the first part of the input of the new
> line, very confusing. This input is supposed to be LINE ORIENTED.
>
> * If I enter 12.34 56 78, it reads 12 for the first number, and zeros
> for the next two, and apparently zeros also for all subsequent lines
>
>
> None of those problems appear in mine:
>
> * It reads at most 3 numbers from the line
>
> * If fewer are present, it'll read them as zeros
nowhere is clear from code.
read as you write, write as you speak, that's the rule...
>
> * If more, they are ignored. Whatever is entered on one line NEVER
/what if that is not desired behavior? it is not clear from code.
Don't do things behind peoples backs.
--
7-77-777
\|/
---
/|\
> impinges on the next
>
> * Numbers can be separated with commas or spaces
>
> * Entering 12.34 56 78 is well behaved; it reads 12 56 78
>
> There are some weaknesses in my static language version, but most are
> fixed in my dynamic version (same code, but no 'int a,b,c'):
>
> * A print item is read as int, float, string or bignum according to what
> is entered
>
> * Missing items are read as ""
>
> * A type can be forced if needed
>
> READ is intended as a casual feature to quickly and informally read such
> input from a console or file. But it's amazing how accomplished it is
> compared with major languages.
>
> I'm sure C++ is also capable of the same things, but how much effort is
> it? Do you have to do everything yourself? Maybe there's a Boost library
> to do what used to be one line of code with Algol60.
>
> My first programs were student exercises. Then, getting the 3 numbers
> the task demanded was the easy bit!
>
--
/Volumes/air AFP Music Volume/NATASA/temp/peste noire/(2007) Folkfuck Folie/04 - D'un Vilain.mp3
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-23 11:18 +0100 |
| Message-ID | <sihk93$aro$1@dont-email.me> |
| In reply to | #81436 |
On 23/09/2021 03:03, Branimir Maksimovic wrote:
> On 2021-09-22, Bart <bc@freeuk.com> wrote:
>> This was something that was so easy in the 1970s, and now so hard;
>> except in my own languages where I keep it simple:
>>
>> int a, b, c
>> print "Prompt> "
>> readln a, b, c
>> println a, b, c
>>
>> I tried it in C++ to see how well it coped:
>>
>> #include <iostream>
>>
>> int main()
>> { int a,b,c;
>> std::cout << "Prompt> ";
>> std::cin >> a >> b >> c;
>> std::cout << a << " " << b << " " << c << "\n";
>> }
>>
> Same thing.
> But there is bug if user enters more or less then three. How you handle
> that case?
How do you handle it in C++? There, if the user enters less than 3,
nothing happens: the program apparenty hangs (waiting for more input).
If more than 3, it doesn't detect that either, until mysterious things
start happening on the next line.
If you put my example into a loop, then for inputs of:
10 20 30 40 50
100 200 300 400 500
where the user expects to see outputs of:
10 20 30
100 200 300
they will in fact see, after entering only 2 lines:
10 20 30
40 50 100
plus 200 300 400 as the output of a 3rd line that they haven't even
entered! Then '500' will figure as the first number of the next line.
It's missing an important thing: the ability to synchronise to each
fresh line of input.
In my version, there are a number of checks that can be made; missing
items are zero. Error flags are set and can be accessed by special reads:
read x:'E'
but which need to be done after item (I'd need to look into my code, as
I never bother for the casual use this is put to). In the dynamic
version, missing items are set to "", so you can check the type.
But you don't have to worry about input from multiple lines being
jumbled up and losing track of which was the first number on a line, or
using "," instead of " " screwing things up.
> In Swift:
> let values = readLine()?.components(separatedBy: CharacterSet.whitespacesAndNewlines) ?? []
>
> let valueOne = values.count > 0 ? Int(values[0]) : nil
> let valueTwo = values.count > 1 ? Int(values[1]) : nil
>
> so this handles correct.
Yeah, this is Python-style too. You just grab the line of input as a
string, and then have to effectively do your tokenising and conversions.
But note that with this method, for the next line, it will discard the
last line and read a fresh line, unlike the C++. It will resync.
However, does you example allow spaces OR commas as separators?
>> * If more, they are ignored. Whatever is entered on one line NEVER
> /what if that is not desired behavior? it is not clear from code.
> Don't do things behind peoples backs.
Poeple are familiar with CLIs and know what to expect. Every fresh line
of input is separate. They don't get a CLI which effectively
concatenates all the user's input into one long line.
On a Windows prompt, I can do:
dir a b c
or I can do:
dir a, b, c
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-23 10:26 +0000 |
| Message-ID | <sihkno$dvm$1@gioia.aioe.org> |
| In reply to | #81454 |
On Thu, 23 Sep 2021 11:18:02 +0100
Bart <bc@freeuk.com> wrote:
>On 23/09/2021 03:03, Branimir Maksimovic wrote:
>> On 2021-09-22, Bart <bc@freeuk.com> wrote:
>
>>> This was something that was so easy in the 1970s, and now so hard;
>>> except in my own languages where I keep it simple:
>>>
>>> int a, b, c
>>> print "Prompt> "
>>> readln a, b, c
>>> println a, b, c
>>>
>>> I tried it in C++ to see how well it coped:
>>>
>>> #include <iostream>
>>>
>>> int main()
>>> { int a,b,c;
>>> std::cout << "Prompt> ";
>>> std::cin >> a >> b >> c;
>>> std::cout << a << " " << b << " " << c << "\n";
>>> }
>>>
>> Same thing.
>> But there is bug if user enters more or less then three. How you handle
>> that case?
>
>How do you handle it in C++? There, if the user enters less than 3,
You read in the entire line then split it up into tokens using whatever method
takes your fancy.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-23 12:21 +0100 |
| Message-ID | <siho0k$3u2$1@dont-email.me> |
| In reply to | #81455 |
On 23/09/2021 11:26, HorseyWorsey@the_stables.com wrote:
> On Thu, 23 Sep 2021 11:18:02 +0100
> Bart <bc@freeuk.com> wrote:
>> On 23/09/2021 03:03, Branimir Maksimovic wrote:
>>> On 2021-09-22, Bart <bc@freeuk.com> wrote:
>>
>>>> This was something that was so easy in the 1970s, and now so hard;
>>>> except in my own languages where I keep it simple:
>>>>
>>>> int a, b, c
>>>> print "Prompt> "
>>>> readln a, b, c
>>>> println a, b, c
>>>>
>>>> I tried it in C++ to see how well it coped:
>>>>
>>>> #include <iostream>
>>>>
>>>> int main()
>>>> { int a,b,c;
>>>> std::cout << "Prompt> ";
>>>> std::cin >> a >> b >> c;
>>>> std::cout << a << " " << b << " " << c << "\n";
>>>> }
>>>>
>>> Same thing.
>>> But there is bug if user enters more or less then three. How you handle
>>> that case?
>>
>> How do you handle it in C++? There, if the user enters less than 3,
>
> You read in the entire line then split it up into tokens using whatever method
> takes your fancy.
>
Example?
My original point was for a language to provide ready means to do
/line-oriented/ input.
You're saying each programmer needs to reinvent this stuff?
I've tested my version some more (still trying to read 3 integers):
Input Output of my code Output of C++ code:
"10" 20 30 10 20 30 Continuous zeros
123'456 7 8 123456 7 8 123 then myriad zeros
123_456 7 8 123456 7 8 Same
.1234 5 6 0 5 6 Same
-1234 5 6 -1234 5 6 -1234 5 6 (A miracle!)
123e4 5 6 123 5 6 Goes crazy like above
10,20,30 10 20 30 Goes crazy
10+20+30 10 0 0 10 20 30
10 10 0 0 Waits for more input
19000000000000000000 3 4
wrong val 3 4 i32.max then goes crazy
Mine could be improved; but the C++ definitely needs some attention.
7/10 and 3/10 respectively I think!
[toc] | [prev] | [next] | [standalone]
Page 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
Back to top | Article view | comp.lang.c++
csiph-web