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 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-24 17:25 +0100 |
| Message-ID | <siku5v$5vi$1@dont-email.me> |
| In reply to | #81515 |
On 24/09/2021 16:19, HorseyWorsey@the_stables.com wrote:
> On Fri, 24 Sep 2021 12:10:01 +0100
> Bart <bc@freeuk.com> wrote:
>> On 24/09/2021 10:12, HorseyWorsey@the_stables.com wrote:
>>> And no doubt requires the resulting binary to store a boatload of RTTI in
>> order
>>> to do that which rather defeats the point of using C which is to create
>>> slimline efficient binaries.
>>
>> Huh? This tweak to C means that when somebody writes:
>>
>> printf("%? %?", i, f);
>>
>> it converts the string to "%d %f". There is zero impact on any binaries.
>
> And what happens if 'i' is a char? Do you want %c, %d or %u? What if its a
> pointer? Do you want %p, %x, %X, %lu etc?
In C, char types count as integers. My scheme only takes care of the
/types/ of the expression (so that you don't to choose from %d %lld
PRIi64 etc). If you want a different textual representation, that's when
you need to be explicit.
My experimental feature generates one of %d %u %lld %llu %f %s %p.
%s is used for char* types, and %p for other pointers.
With this program:
int main(void) {
int a=10;
unsigned int b=20;
long long int c=30;
unsigned long long int d=40;
double e=50.1;
char* f="sixty";
void* g=&a;
void(*h)(void)=main;
printf("%? %? %? %? %? %? %? %?\n", a, b, c, d, e, f, g, h);
}
the format string is changed to:
"%d %u %lld %llu %f %s %p %p\n"
The output is:
10 20 30 40 50.100000 sixty 000000000080FF48 0000000000401000
At this point, with this enhancement, C's printf (I know it's in C++
too) looks better than:
std::cout << a << " " << b << " " << c << " " << d << " " << e << " "
<< f << " " << g << " " << h << "\n";
But remember that in my kiddies' language, it's still just:
println a, b, c, d, e, f, g, h
And still totally unprofessional, of course. (Maybe a professional
wouldn't be able to claim so many hours' pay if the language was too easy!)
> So you're complaining about basic C++ functionality you don't even understand.
> Got it.
Would understanding it make me happier about typing out all that <<
nonsense above?
>> Virtually all output I want to do is of standard types. It would just be
>> nice to output A and B by writing:
>>
>> ... A, B ...
>>
>> rather than:
>>
>> ... A << " " << B ...
>
> Whats special about a space?
Have a look at the English written in these posts; what's the common
separator between words? Yep, it's a single space. Handy for stopping
alphanumeric entities from running into each other.
Because of course, when you generate human readable text from a
programming language, the most sensible default is to end up with:
12345678910
instead of:
1 2 3 4 5 6 7 8 9 10
> What if someone wants 2 spaces as a seperator
> or maybe a tab or comma? C++ is a professional language, its not BASIC for
> kiddies to output simple tabular results.
So 'professional' equals 'unnecessarily complicated and unintuitive'?
I think everyone's got that about C++!
> What if someone wants 2 spaces as a seperator
> or maybe a tab or comma?
You make the most common, most useful and convenient requirement the
default. Anything different, then that's when you have special code.
Such as using formatted printing.
In my book that's better than HAVING to write '<< " " <<' 99 times out
of hundred, instead of nothing.
> Plus a comma already has syntactic
> meaning in C & C++.
In programming languages it is very commonly used to separate the
elements of a list. So why not the list of expressions in a print
statement (or whatever std::cout << is classed as).
>> Negative numbers aren't that difficult actually...
>
> So long as you remember chars,ints etc are 2's complement whereas floating
> point uses a sign bit.
Yeah, thanks.
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-25 09:27 +0000 |
| Message-ID | <simq1v$13sm$1@gioia.aioe.org> |
| In reply to | #81522 |
On Fri, 24 Sep 2021 17:25:24 +0100
Bart <bc@freeuk.com> wrote:
>On 24/09/2021 16:19, HorseyWorsey@the_stables.com wrote:
> println a, b, c, d, e, f, g, h
>
>And still totally unprofessional, of course. (Maybe a professional
>wouldn't be able to claim so many hours' pay if the language was too easy!)
If someone needs a nice easy scripting language they'll use Python. And they
do.
>> So you're complaining about basic C++ functionality you don't even
>understand.
>> Got it.
>
>Would understanding it make me happier about typing out all that <<
>nonsense above?
It might help.
>> Whats special about a space?
>
>Have a look at the English written in these posts; what's the common
>separator between words? Yep, it's a single space. Handy for stopping
>alphanumeric entities from running into each other.
So? Even your sentence above contains "," "?" and " " so your reasoning
fails immediately.
>Because of course, when you generate human readable text from a
>programming language, the most sensible default is to end up with:
>
> 12345678910
>
>instead of:
>
> 1 2 3 4 5 6 7 8 9 10
You seem to be fixated on simple output spacing. Its really not a Big Deal
for most people. How hard is printf("%d %d %d %d\n".... to write?
>> What if someone wants 2 spaces as a seperator
>> or maybe a tab or comma? C++ is a professional language, its not BASIC for
>> kiddies to output simple tabular results.
>
>So 'professional' equals 'unnecessarily complicated and unintuitive'?
No, it equals syntax able to do complex tasks easily. BASIC makes it easy to
print stuff out but I wouldn't use it to write Fintech software in!
> > What if someone wants 2 spaces as a seperator
> > or maybe a tab or comma?
>
>You make the most common, most useful and convenient requirement the
Where did you get the idea its the most common? I'm afraid thats BS. We're
talking program output, not human writing.
>In programming languages it is very commonly used to separate the
>elements of a list. So why not the list of expressions in a print
>statement (or whatever std::cout << is classed as).
face <- palm. Honestly, why don't you go play in comp.lang.basic
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-25 11:07 +0100 |
| Message-ID | <simsd1$eb$1@dont-email.me> |
| In reply to | #81536 |
On 25/09/2021 10:27, HorseyWorsey@the_stables.com wrote: > On Fri, 24 Sep 2021 17:25:24 +0100 > Bart <bc@freeuk.com> wrote: >> On 24/09/2021 16:19, HorseyWorsey@the_stables.com wrote: >> println a, b, c, d, e, f, g, h >> >> And still totally unprofessional, of course. (Maybe a professional >> wouldn't be able to claim so many hours' pay if the language was too easy!) > > If someone needs a nice easy scripting language they'll use Python. And they > do. I write both kinds of languages, systems ones and scripting ones. Both have the same easy print facilities. Except the scripting one can print more complex objects too. >> So 'professional' equals 'unnecessarily complicated and unintuitive'? > > No, it equals syntax able to do complex tasks easily. BASIC makes it easy to > print stuff out but I wouldn't use it to write Fintech software in! ANY language can make it easier to print stuff out! Believe me, it's of the simplest parts of implementing a language. And it's what needs to be done early as it plays a part in testing everything else. But some languages are pig-headed enough to make it difficult and to keep it that way in the mistaken belief that making things too easy is in some way 'unprofessional', and something to be look down upon. So, make a rod for your own back, then. >> You make the most common, most useful and convenient requirement the > > Where did you get the idea its the most common? I'm afraid thats BS. We're > talking program output, not human writing. Program output as text? The intention is usually to keep it human readable. Each machine readable text will need separators. (Except in the specific case of generating fixed field database files, but those are unlikely to use hard-coded lists of print items, which is the print feature we're talking about.) At least 90% of the print statements I write (not 90% of the ones in a finished program) are temporary ones to do with debugging. >> In programming languages it is very commonly used to separate the >> elements of a list. So why not the list of expressions in a print >> statement (or whatever std::cout << is classed as). > > face <- palm. Honestly, why don't you go play in comp.lang.basic /I/ should do the face-palm, given your completely irrational insistence that: A << " " << B is miles better than: A, " ", B /and/ better than simply: A, B
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-25 10:14 +0000 |
| Message-ID | <simsqd$a75$1@gioia.aioe.org> |
| In reply to | #81539 |
On Sat, 25 Sep 2021 11:07:16 +0100 Bart <bc@freeuk.com> wrote: >On 25/09/2021 10:27, HorseyWorsey@the_stables.com wrote: >> Where did you get the idea its the most common? I'm afraid thats BS. We're >> talking program output, not human writing. > >Program output as text? The intention is usually to keep it human >readable. Each machine readable text will need separators. And just how many C++ programs these days do you think return their output to the console assuming human readable output is even their raison d'etre? C++ is usually used for huge backend systems that run in the background and any readable output will probably be formatted data written to a log that won't be simply words seperated by a space. >>> In programming languages it is very commonly used to separate the >>> elements of a list. So why not the list of expressions in a print >>> statement (or whatever std::cout << is classed as). >> >> face <- palm. Honestly, why don't you go play in comp.lang.basic > >/I/ should do the face-palm, given your completely irrational insistence >that: > > A << " " << B > >is miles better than: > > A, " ", B Where did I say that? Comma is already overloaded in C/C++, it doesn't need yet another meaning. >/and/ better than simply: > > A, B Because the use case of that for C++ is virtually non existent except in debugging.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-25 11:53 +0100 |
| Message-ID | <simv40$i84$1@dont-email.me> |
| In reply to | #81541 |
On 25/09/2021 11:14, HorseyWorsey@the_stables.com wrote: > On Sat, 25 Sep 2021 11:07:16 +0100 > Bart <bc@freeuk.com> wrote: >> On 25/09/2021 10:27, HorseyWorsey@the_stables.com wrote: >>> Where did you get the idea its the most common? I'm afraid thats BS. We're >>> talking program output, not human writing. >> >> Program output as text? The intention is usually to keep it human >> readable. Each machine readable text will need separators. > > And just how many C++ programs these days do you think return their output > to the console assuming human readable output is even their raison d'etre? > C++ is usually used for huge backend systems that run in the background and > any readable output will probably be formatted data written to a log that > won't be simply words seperated by a space. According to Wikipedia, C++ is a general purpose language. My own applications were mostly GUI ones, with no attached console, and the languages used still had Print. Print is used also to send output to files. And could be used to display text within a GUI window. >>>> In programming languages it is very commonly used to separate the >>>> elements of a list. So why not the list of expressions in a print >>>> statement (or whatever std::cout << is classed as). >>> >>> face <- palm. Honestly, why don't you go play in comp.lang.basic >> >> /I/ should do the face-palm, given your completely irrational insistence >> that: >> >> A << " " << B >> >> is miles better than: >> >> A, " ", B > > Where did I say that? Comma is already overloaded in C/C++, it doesn't need > yet another meaning. But, what on earth does that mean? Overloaded for what purpose? Last time I looked, comma was still used to separate the arguments of a function. Are you hung up on the fact that because "<<" is an operator (a very strange one), then any replacement for that whole god-forsaken std::cout scheme must be implemented as some kind of operator too? Forget about the operator idea, it's just a list! (I was going to post examples of << code, with versions that use commas to show much easier on the eye it would be. But then I accidentally caught glimpses of full-on C++ code, and realised trying to fix this small corner of the language is completely futile. The whole thing is just irretrievably broken.) >> /and/ better than simply: >> >> A, B > > Because the use case of that for C++ is virtually non existent except in > debugging. So quite an important use-case.
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-25 11:23 +0000 |
| Message-ID | <sin0rf$1vgp$1@gioia.aioe.org> |
| In reply to | #81546 |
On Sat, 25 Sep 2021 11:53:39 +0100
Bart <bc@freeuk.com> wrote:
>On 25/09/2021 11:14, HorseyWorsey@the_stables.com wrote:
>> On Sat, 25 Sep 2021 11:07:16 +0100
>> Bart <bc@freeuk.com> wrote:
>>> On 25/09/2021 10:27, HorseyWorsey@the_stables.com wrote:
>>>> Where did you get the idea its the most common? I'm afraid thats BS. We're
>>>> talking program output, not human writing.
>>>
>>> Program output as text? The intention is usually to keep it human
>>> readable. Each machine readable text will need separators.
>>
>> And just how many C++ programs these days do you think return their output
>> to the console assuming human readable output is even their raison d'etre?
>> C++ is usually used for huge backend systems that run in the background and
>> any readable output will probably be formatted data written to a log that
>> won't be simply words seperated by a space.
>
>According to Wikipedia, C++ is a general purpose language.
Most languages are technically general purpose but most of them also
specialise in certain areas. C/C++ is mainly used in large applications,
systems and low level programming and places where speed matters. They're
not generally used to write quick and dirty console apps though you can use
them for that.
>> Where did I say that? Comma is already overloaded in C/C++, it doesn't need
>> yet another meaning.
>
>But, what on earth does that mean? Overloaded for what purpose? Last
>time I looked, comma was still used to separate the arguments of a function.
Arguments of a function, variable definitions, class initialisers and also
to seperate function calls and assignments (though not built-in keywords for
some reason) instead of using curly brackets which not many people know eg:
while(i < 10) printf("i = %d\n",i),++i,puts("---");
>Are you hung up on the fact that because "<<" is an operator (a very
>strange one), then any replacement for that whole god-forsaken std::cout
>scheme must be implemented as some kind of operator too?
No. Personally I think overloading << was a stupid idea, strstroup should have
invented a turbo charged version of printf() instead like your %? instead with
a formatter that called a default class method to output itself.
>> Because the use case of that for C++ is virtually non existent except in
>> debugging.
>
>So quite an important use-case.
Only if you still using print statements to debug instead of using a debugger.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-25 12:34 +0000 |
| Message-ID | <NHE3J.37357$rsCb.7328@fx01.iad> |
| In reply to | #81536 |
On 2021-09-25, HorseyWorsey@the_stables.com <HorseyWorsey@the_stables.com> wrote: > On Fri, 24 Sep 2021 17:25:24 +0100 > > If someone needs a nice easy scripting language they'll use Python. And they > do. > > OK. Agreed. But what about ONES that think using SCRIPTING LANGUAGE, is Bellow HONOR? -- 7-77-777 Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-25 15:37 +0300 |
| Message-ID | <sin577$t0n$1@dont-email.me> |
| In reply to | #81536 |
25.09.2021 12:27 HorseyWorsey@the_stables.com kirjutas:
> On Fri, 24 Sep 2021 17:25:24 +0100
> Bart <bc@freeuk.com> wrote:
>> On 24/09/2021 16:19, HorseyWorsey@the_stables.com wrote:
>> println a, b, c, d, e, f, g, h
>>
>> And still totally unprofessional, of course. (Maybe a professional
>> wouldn't be able to claim so many hours' pay if the language was too easy!)
>
> If someone needs a nice easy scripting language they'll use Python. And they
> do.
In Python they apparently thought printing was too simple, so in Python
3 they now require parens:
Python2: print 1, 2, 3
Python3: print(1, 2, 3)
BTW, in C++ one can easily define python3 style print:
#include <iostream>
inline void print() {
std::cout << "\n";
}
template<typename T, typename... Args>
void print(T x, Args... args) {
std::cout << x << ' ';
print(args...);
}
int main() {
print(1, 2, 3);
}
Note to Bart: the ellipses above are actual C++11 syntax, not some
pseudocode. This is a running demo program. In your own C++ code just
put these print() definitions in sme common header file, and you can use
python3 style print syntax for all built-in and other types which
support stream<<.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-25 15:46 +0100 |
| Message-ID | <sincog$j57$1@dont-email.me> |
| In reply to | #81552 |
On 25/09/2021 13:37, Paavo Helde wrote:
> 25.09.2021 12:27 HorseyWorsey@the_stables.com kirjutas:
>> On Fri, 24 Sep 2021 17:25:24 +0100
>> Bart <bc@freeuk.com> wrote:
>>> On 24/09/2021 16:19, HorseyWorsey@the_stables.com wrote:
>>> println a, b, c, d, e, f, g, h
>>>
>>> And still totally unprofessional, of course. (Maybe a professional
>>> wouldn't be able to claim so many hours' pay if the language was too
>>> easy!)
>>
>> If someone needs a nice easy scripting language they'll use Python.
>> And they
>> do.
>
> In Python they apparently thought printing was too simple, so in Python
> 3 they now require parens:
>
> Python2: print 1, 2, 3
>
> Python3: print(1, 2, 3)
That was one giant PITA. A lot of downloadable Python at one time was
Python2. So you had to convert all the uses of 'print'.
The change was to turn 'print' from a statement into a function, because
it was 'better'.
> BTW, in C++ one can easily define python3 style print:
>
> #include <iostream>
>
> inline void print() {
> std::cout << "\n";
> }
>
> template<typename T, typename... Args>
> void print(T x, Args... args) {
> std::cout << x << ' ';
> print(args...);
> }
>
> int main() {
> print(1, 2, 3);
> }
>
> Note to Bart: the ellipses above are actual C++11 syntax, not some
> pseudocode. This is a running demo program. In your own C++ code just
> put these print() definitions in sme common header file, and you can use
> python3 style print syntax for all built-in and other types which
> support stream<<.
This is good. It doesn't handle all the possibilities of properly
built-in Print, although print/println variations are easy. But it will
do for quick debug prints where layout doesn't matter.
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-25 15:19 +0000 |
| Message-ID | <sinemf$1t25$1@gioia.aioe.org> |
| In reply to | #81564 |
On Sat, 25 Sep 2021 15:46:27 +0100 Bart <bc@freeuk.com> wrote: >On 25/09/2021 13:37, Paavo Helde wrote: >> 25.09.2021 12:27 HorseyWorsey@the_stables.com kirjutas: >>> On Fri, 24 Sep 2021 17:25:24 +0100 >>> Bart <bc@freeuk.com> wrote: >>>> On 24/09/2021 16:19, HorseyWorsey@the_stables.com wrote: >>>> println a, b, c, d, e, f, g, h >>>> >>>> And still totally unprofessional, of course. (Maybe a professional >>>> wouldn't be able to claim so many hours' pay if the language was too >>>> easy!) >>> >>> If someone needs a nice easy scripting language they'll use Python. >>> And they >>> do. >> >> In Python they apparently thought printing was too simple, so in Python >> 3 they now require parens: >> >> Python2: print 1, 2, 3 >> >> Python3: print(1, 2, 3) > >That was one giant PITA. A lot of downloadable Python at one time was >Python2. So you had to convert all the uses of 'print'. Removing python2 syntax from python3 wasn't one of Guido's smartest moves. No reason it couldn't have been left in and deprecated.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-25 17:16 +0000 |
| Message-ID | <1QI3J.144682$o45.88908@fx46.iad> |
| In reply to | #81564 |
On 2021-09-25, Bart <bc@freeuk.com> wrote: >> Python2: print 1, 2, 3 >> >> Python3: print(1, 2, 3) > > That was one giant PITA. A lot of downloadable Python at one time was > Python2. So you had to convert all the uses of 'print'. > > The change was to turn 'print' from a statement into a function, because > it was 'better'. This is why I don't like student code and libraries to use. They don't care about API and code stability... -- 7-77-777 Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2021-09-27 23:51 +0200 |
| Message-ID | <sitecg$d91$1@dont-email.me> |
| In reply to | #81552 |
Am 25.09.21 um 14:37 schrieb Paavo Helde: > In Python they apparently thought printing was too simple, so in Python > 3 they now require parens: > > Python2: print 1, 2, 3 > > Python3: print(1, 2, 3) > It wasn't "too simple", whatever that means, but in Python2, "print" was a keyword and specially treated in the interpreter, whereas the core developers thought that it should not be set apart from regular functions, because there is nothing that "print" can do that any other old function could not do. Variable number of arguments of varying type is possible for any Python function. Christian
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-27 23:41 +0100 |
| Message-ID | <sithal$1mf$1@dont-email.me> |
| In reply to | #81630 |
On 27/09/2021 22:51, Christian Gollwitzer wrote: > Am 25.09.21 um 14:37 schrieb Paavo Helde: >> In Python they apparently thought printing was too simple, so in >> Python 3 they now require parens: >> >> Python2: print 1, 2, 3 >> >> Python3: print(1, 2, 3) >> > > It wasn't "too simple", whatever that means, but in Python2, "print" was > a keyword and specially treated in the interpreter, whereas the core > developers thought that it should not be set apart from regular > functions, because there is nothing that "print" can do that any other > old function could not do. Other than provide a more ergonomic syntax. Some languages have features that allow 'if' and 'for' statements to be implemented as functions. But just because you can, should you?
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-23 10:26 +0000 |
| Message-ID | <PDY2J.117475$Kv2.20688@fx47.iad> |
| In reply to | #81454 |
On 2021-09-23, 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,
> 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.
Same way as in Swift. getline on ' ' or '\'
Greetings, Branimir.
--
7-77-777
\|/
---
/|\
>
> 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
>
>
>
--
/Volumes/air AFP Music Volume/NATASA/temp/Exciter/heavy metal maniac/05 Mistress Of Evil.mp3
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-23 14:04 +0000 |
| Message-ID | <4Q%2J.2840$fZ.1327@fx06.iad> |
| In reply to | #81432 |
Manfred <noname@add.invalid> writes: >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. As someone who has been crafting operating systems for over forty years from mainframes to 5G base stations, your assertion is complete nonsense.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-09-23 17:47 +0200 |
| Message-ID | <sii7id$1srh$1@gioia.aioe.org> |
| In reply to | #81462 |
On 9/23/2021 4:04 PM, Scott Lurndal wrote: > Manfred <noname@add.invalid> writes: >> 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. > > As someone who has been crafting operating systems for over forty > years from mainframes to 5G base stations, your assertion is complete nonsense. > Thanks for the "nonsense" label. Just for the record, David Brown has just confirmed that printing (aka formatting in this context) is an "optional" library feature, that is in fact often /not/ used in some types of systems. Will you please come to an agreement before insulting me?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-23 17:07 +0000 |
| Message-ID | <nv23J.143092$o45.67971@fx46.iad> |
| In reply to | #81468 |
Manfred <noname@add.invalid> writes: >On 9/23/2021 4:04 PM, Scott Lurndal wrote: >> Manfred <noname@add.invalid> writes: >>> 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. >> >> As someone who has been crafting operating systems for over forty >> years from mainframes to 5G base stations, your assertion is complete nonsense. >> > >Thanks for the "nonsense" label. >Just for the record, David Brown has just confirmed that printing (aka >formatting in this context) is an "optional" library feature, that is in >fact often /not/ used in some types of systems. > >Will you please come to an agreement before insulting me?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-23 17:08 +0000 |
| Message-ID | <mw23J.143093$o45.52284@fx46.iad> |
| In reply to | #81468 |
Manfred <noname@add.invalid> writes: >On 9/23/2021 4:04 PM, Scott Lurndal wrote: >> Manfred <noname@add.invalid> writes: >>> 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. >> >> As someone who has been crafting operating systems for over forty >> years from mainframes to 5G base stations, your assertion is complete nonsense. >> > >Thanks for the "nonsense" label. >Just for the record, David Brown has just confirmed that printing (aka >formatting in this context) is an "optional" library feature, that is in >fact often /not/ used in some types of systems. You wrote: as a systems language, you don't need formatting support Which is complete nonsense. I stand by my assertion.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-09-23 19:30 +0200 |
| Message-ID | <siidkk$va6$1@gioia.aioe.org> |
| In reply to | #81477 |
On 9/23/2021 7:08 PM, Scott Lurndal wrote: > Manfred <noname@add.invalid> writes: >> On 9/23/2021 4:04 PM, Scott Lurndal wrote: >>> Manfred <noname@add.invalid> writes: > >>>> 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. >>> >>> As someone who has been crafting operating systems for over forty >>> years from mainframes to 5G base stations, your assertion is complete nonsense. >>> >> >> Thanks for the "nonsense" label. >> Just for the record, David Brown has just confirmed that printing (aka >> formatting in this context) is an "optional" library feature, that is in >> fact often /not/ used in some types of systems. > > You wrote: > > as a systems language, you don't need formatting support > > Which is complete nonsense. I stand by my assertion. > Maybe we refer to different meanings of formatting in this context, or whatever. I find it really hard to try and reason with such an insulting attitude. Have it your way.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-24 10:06 +1200 |
| Message-ID | <ir4c33Fj3ljU2@mid.individual.net> |
| In reply to | #81480 |
On 24/09/2021 05:30, Manfred wrote: > On 9/23/2021 7:08 PM, Scott Lurndal wrote: >> Manfred <noname@add.invalid> writes: >>> On 9/23/2021 4:04 PM, Scott Lurndal wrote: >>>> Manfred <noname@add.invalid> writes: >> >>>>> 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. >>>> >>>> As someone who has been crafting operating systems for over forty >>>> years from mainframes to 5G base stations, your assertion is complete nonsense. >>>> >>> >>> Thanks for the "nonsense" label. >>> Just for the record, David Brown has just confirmed that printing (aka >>> formatting in this context) is an "optional" library feature, that is in >>> fact often /not/ used in some types of systems. >> >> You wrote: >> >> as a systems language, you don't need formatting support >> >> Which is complete nonsense. I stand by my assertion. >> > > Maybe we refer to different meanings of formatting in this context, or > whatever. > > I find it really hard to try and reason with such an insulting attitude. > Have it your way. Incorrect might be a kinder way of putting it. Many command line tools provide a variety of output formatting options, such as human and machine readable formats. Even basic kernel and driver logging requires some degree of formatting (timestamps, fixed widths etc.). Much "systems" programming is tool writing. -- Ian
[toc] | [prev] | [next] | [standalone]
Page 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
Back to top | Article view | comp.lang.c++
csiph-web