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 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-23 12:40 +0100 |
| Message-ID | <sihp3i$bfj$1@dont-email.me> |
| In reply to | #81458 |
On 23/09/2021 12:21, Bart wrote:
> 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
I mean same as the last example; just crazy stuff. Not the same as mine.
Example:
C:\c>a # C++ program with loop
Prompt> 123'456 7 8 # this is what is typed
123 0 0
Prompt> 123 0 0 # these appear automatically
Prompt> 123 0 0
Prompt> 123 0 0
Prompt> 123 0 0
Prompt> 123 0 0
Prompt> 123 0 0
Prompt> 123 0 0
Prompt> 123 0 0
Prompt> 123 0 0
....
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-09-23 08:05 -0400 |
| Message-ID | <F4_2J.41248$6U3.32310@fx43.iad> |
| In reply to | #81458 |
On 9/23/21 7:21 AM, Bart wrote:
> 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.
Then use line oriented processing. That would be gets (or maybe better
fgets to avoid overrun attacks) to get the line, and then parse with the
method you want, sscanf if you can deal with the default error handling.
C++ has similar functions for streams.
Don't complain that your hammer doesn't work well on screws.
>
> 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]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-23 15:02 +0100 |
| Message-ID | <sii1e6$6d0$1@dont-email.me> |
| In reply to | #81460 |
On 23/09/2021 13:05, Richard Damon wrote:
> On 9/23/21 7:21 AM, Bart wrote:
>>>> 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.
>
> Then use line oriented processing. That would be gets (or maybe better
> fgets to avoid overrun attacks) to get the line, and then parse with the
> method you want, sscanf if you can deal with the default error handling.
>
> C++ has similar functions for streams.
So it /doesn't/ support line-oriented input unless you implement it
yourself. /That/ is my complaint.
This is a similar example in Basic:
for i=1 to 3
print "Prompt> "; rem ";" suppresses the newline
input a,b,c rem I think this grabs a fresh line
print a,b,c
next i
It works better than the C++! And better than C's scanf which everyone
tries to avoid using.
None of this is really surprising; I've also had the impression that the
job of C++ was to make things more complicated than necessary and not
simpler. (Perhaps it wouldn't do to have just anybody being able to use
the language.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-24 08:48 +1200 |
| Message-ID | <ir47g0Fj3ljU1@mid.individual.net> |
| In reply to | #81461 |
On 24/09/2021 02:02, Bart wrote:
> On 23/09/2021 13:05, Richard Damon wrote:
>> On 9/23/21 7:21 AM, Bart wrote:
>
>>>>> 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.
>>
>> Then use line oriented processing. That would be gets (or maybe better
>> fgets to avoid overrun attacks) to get the line, and then parse with the
>> method you want, sscanf if you can deal with the default error handling.
>>
>> C++ has similar functions for streams.
>
> So it /doesn't/ support line-oriented input unless you implement it
> yourself. /That/ is my complaint.
>
> This is a similar example in Basic:
>
> for i=1 to 3
> print "Prompt> "; rem ";" suppresses the newline
> input a,b,c rem I think this grabs a fresh line
> print a,b,c
> next i
>
> It works better than the C++! And better than C's scanf which everyone
> tries to avoid using.
How is that fundamentally different from
for( int i = 0; i < 3; ++i )
{
std::cout << "Prompt> ";
std::cin >> a >> b >> c;
std::cout << a << ' ' << b << ' ' << c << '\n';
}
?
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-23 23:05 +0100 |
| Message-ID | <siitne$l4r$1@dont-email.me> |
| In reply to | #81489 |
On 23/09/2021 21:48, Ian Collins wrote:
> On 24/09/2021 02:02, Bart wrote:
>> On 23/09/2021 13:05, Richard Damon wrote:
>>> On 9/23/21 7:21 AM, Bart wrote:
>>
>>>>>> 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.
>>>
>>> Then use line oriented processing. That would be gets (or maybe better
>>> fgets to avoid overrun attacks) to get the line, and then parse with the
>>> method you want, sscanf if you can deal with the default error handling.
>>>
>>> C++ has similar functions for streams.
>>
>> So it /doesn't/ support line-oriented input unless you implement it
>> yourself. /That/ is my complaint.
>>
>> This is a similar example in Basic:
>>
>> for i=1 to 3
>> print "Prompt> "; rem ";" suppresses the newline
>> input a,b,c rem I think this grabs a fresh line
>> print a,b,c
>> next i
>>
>> It works better than the C++! And better than C's scanf which everyone
>> tries to avoid using.
>
> How is that fundamentally different from
>
> for( int i = 0; i < 3; ++i )
> {
> std::cout << "Prompt> ";
> std::cin >> a >> b >> c;
> std::cout << a << ' ' << b << ' ' << c << '\n';
> }
> ?
>
Haven't you followed the thread? A lot of things have been pointed out.
But here's a summary of issues with the C++ loop:
* It's not line-oriented; the new lines get out of sync with the data
being read
* If fewer than 3 items are present on a line, then it apparently hangs,
with no explanation, waiting for them on the next line
* If more than 3 items are present on a line, then those aren't
discarded, but are confusingly used as input for a, b, c for the next
line. So if 400 and 500 are extra items, and the user enters 10 20 30 on
the next line, if will read '400 500 10', with 20 and 30 rolled over to
the subsequent line
* If more than 3 extra items are present, then on the next iteration, it
doesn't wait for user input at all. If will not do so until everything
on that initial line is consumed
* Numeric separators within numbers such as "_" and "'" are not
recognised, and cause an error
* Numbers which are quoted are not recognised, and cause an error
* Separators between numbers other than white space are not recognised,
such as commas, and cause an error
* Floating point numbers (using "." and/or "e") are not recognised;
those characters cause an error
* When an out-of-range number is entered, it reads i32.max (etc) for
that number, but also generates an error
* I mentioned error a few times, when that happens, it goes crazy. I
think the internal pointer is not stepped past it, and it just reads
zeros, so it never consumes the rest of the line. So in a loop, it just
prints zeros over and over again without the user entering anything.
Apart from that it's fine!
The behaviour of mine (bearing in mind I only use the feature casually,
and it's never been implemented comprehensively), is as follows:
* It is strictly line oriented. Each READLN discards the rest of the
last read, and asks for a fresh line of input. It can never get out of sync
* If fewer than 3 items are entered, the missing ones are zero. (In
dynamic version, they are read as "".) It will not hang.
* If more than 3 items are entered, those are ignored. (A program would
have to speculatively read a fourth item, as a string, to test for
trailing characters)
* Numeric separators within numbers like "_" and "'" are recognised and
skipped.
* Numbers can be separated by white space or commas, or a mix (remember
this can be used for ad hoc user input, not tidy machine-generated files)
* Floating point numbers are properly consumed, then converted to ints
(when reading int values)
* Out-of-range numbers are truncated to 64 bits (for int types). (In
dynamic version, it results in a bignum value.)
* For certain errors, internal flags are set, which can be interrogated
with a special Read (eg. read err:"e"), but I rarely do so. It doesn't
now screw any line synchronisation
* Print items can be enclosed in quotes. (Mainly for the benefit of
strings, names etc which then allow embedded spaces, commas and quotes,
but all print items share the same tokenisation step.)
Hope that answers your question! I can't speak specifically for that
Basic code, as I only tested one version, and only to confirm that it
appeared to be line-oriented too.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-23 23:47 +0000 |
| Message-ID | <vm83J.6038$7U3.4588@fx24.iad> |
| In reply to | #81491 |
On 2021-09-23, Bart <bc@freeuk.com> wrote:
> On 23/09/2021 21:48, Ian Collins wrote:
>> On 24/09/2021 02:02, Bart wrote:
>>> On 23/09/2021 13:05, Richard Damon wrote:
>>>> On 9/23/21 7:21 AM, Bart wrote:
>>>
>>>>>>> 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.
>>>>
>>>> Then use line oriented processing. That would be gets (or maybe better
>>>> fgets to avoid overrun attacks) to get the line, and then parse with the
>>>> method you want, sscanf if you can deal with the default error handling.
>>>>
>>>> C++ has similar functions for streams.
>>>
>>> So it /doesn't/ support line-oriented input unless you implement it
>>> yourself. /That/ is my complaint.
>>>
>>> This is a similar example in Basic:
>>>
>>> for i=1 to 3
>>> print "Prompt> "; rem ";" suppresses the newline
>>> input a,b,c rem I think this grabs a fresh line
>>> print a,b,c
>>> next i
>>>
>>> It works better than the C++! And better than C's scanf which everyone
>>> tries to avoid using.
>>
>> How is that fundamentally different from
>>
>> for( int i = 0; i < 3; ++i )
>> {
>> std::cout << "Prompt> ";
>> std::cin >> a >> b >> c;
>> std::cout << a << ' ' << b << ' ' << c << '\n';
>> }
>> ?
>>
>
> Haven't you followed the thread? A lot of things have been pointed out.
> But here's a summary of issues with the C++ loop:
>
>
> * It's not line-oriented; the new lines get out of sync with the data
> being read
>
> * If fewer than 3 items are present on a line, then it apparently hangs,
> with no explanation, waiting for them on the next line
streams are for serialization, getline is for user input.
--
7-77-777
\|/
---
/|\
>
> * If more than 3 items are present on a line, then those aren't
> discarded, but are confusingly used as input for a, b, c for the next
> line. So if 400 and 500 are extra items, and the user enters 10 20 30 on
> the next line, if will read '400 500 10', with 20 and 30 rolled over to
> the subsequent line
>
> * If more than 3 extra items are present, then on the next iteration, it
> doesn't wait for user input at all. If will not do so until everything
> on that initial line is consumed
>
> * Numeric separators within numbers such as "_" and "'" are not
> recognised, and cause an error
>
> * Numbers which are quoted are not recognised, and cause an error
>
> * Separators between numbers other than white space are not recognised,
> such as commas, and cause an error
>
> * Floating point numbers (using "." and/or "e") are not recognised;
> those characters cause an error
>
> * When an out-of-range number is entered, it reads i32.max (etc) for
> that number, but also generates an error
>
> * I mentioned error a few times, when that happens, it goes crazy. I
> think the internal pointer is not stepped past it, and it just reads
> zeros, so it never consumes the rest of the line. So in a loop, it just
> prints zeros over and over again without the user entering anything.
>
> Apart from that it's fine!
>
>
> The behaviour of mine (bearing in mind I only use the feature casually,
> and it's never been implemented comprehensively), is as follows:
>
> * It is strictly line oriented. Each READLN discards the rest of the
> last read, and asks for a fresh line of input. It can never get out of sync
>
> * If fewer than 3 items are entered, the missing ones are zero. (In
> dynamic version, they are read as "".) It will not hang.
>
> * If more than 3 items are entered, those are ignored. (A program would
> have to speculatively read a fourth item, as a string, to test for
> trailing characters)
>
> * Numeric separators within numbers like "_" and "'" are recognised and
> skipped.
>
> * Numbers can be separated by white space or commas, or a mix (remember
> this can be used for ad hoc user input, not tidy machine-generated files)
>
> * Floating point numbers are properly consumed, then converted to ints
> (when reading int values)
>
> * Out-of-range numbers are truncated to 64 bits (for int types). (In
> dynamic version, it results in a bignum value.)
>
> * For certain errors, internal flags are set, which can be interrogated
> with a special Read (eg. read err:"e"), but I rarely do so. It doesn't
> now screw any line synchronisation
>
> * Print items can be enclosed in quotes. (Mainly for the benefit of
> strings, names etc which then allow embedded spaces, commas and quotes,
> but all print items share the same tokenisation step.)
>
>
> Hope that answers your question! I can't speak specifically for that
> Basic code, as I only tested one version, and only to confirm that it
> appeared to be line-oriented too.
--
Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-09-23 16:56 -0700 |
| Message-ID | <87zgs2lubf.fsf@nosuchdomain.example.com> |
| In reply to | #81491 |
Bart <bc@freeuk.com> writes:
> On 23/09/2021 21:48, Ian Collins wrote:
>> On 24/09/2021 02:02, Bart wrote:
[...]
>>> This is a similar example in Basic:
>>>
>>> for i=1 to 3
>>> print "Prompt> "; rem ";" suppresses the newline
>>> input a,b,c rem I think this grabs a fresh line
>>> print a,b,c
>>> next i
>>>
>>> It works better than the C++! And better than C's scanf which everyone
>>> tries to avoid using.
>> How is that fundamentally different from
>> for( int i = 0; i < 3; ++i )
>> {
>> std::cout << "Prompt> ";
>> std::cin >> a >> b >> c;
>> std::cout << a << ' ' << b << ' ' << c << '\n';
>> }
>> ?
>
> Haven't you followed the thread? A lot of things have been pointed
> out. But here's a summary of issues with the C++ loop:
>
>
> * It's not line-oriented; the new lines get out of sync with the data
> being read
Right, it's not designed to be. For example:
int a, b, c;
std::cin >> a >> b >> c;
std::cout << "a=" << a << " b=" << b << " c=" << c << '\n';
The std::cin line reads integer values, skipping white space (which
includes newlines) before each. If you just want to skip white space
other than newlines, there's probably a way to do that.
If you want line-oriented input, read a line at a time using
std::getline() and then parse each line. It's not that hard.
std::string line;
std::getline(std::cin, line);
std::stringstream ss(line);
ss >> a >> b >> c;
> * If fewer than 3 items are present on a line, then it apparently
> hangs, with no explanation, waiting for them on the next line
Because it's not line-oriented.
> * If more than 3 items are present on a line, then those aren't
> discarded, but are confusingly used as input for a, b, c for the
> next line. So if 400 and 500 are extra items, and the user enters 10
> 20 30 on the next line, if will read '400 500 10', with 20 and 30
> rolled over to the subsequent line
Because it's not line-oriented.
> * If more than 3 extra items are present, then on the next iteration,
> it doesn't wait for user input at all. If will not do so until
> everything on that initial line is consumed
Because it's not line-oriented.
> * Numeric separators within numbers such as "_" and "'" are not
> recognised, and cause an error
Right. Just how permissive do you think it should be?
> * Numbers which are quoted are not recognised, and cause an error
Right. 123 is a number; "123", “123”, '123', and «123» are not.
> * Separators between numbers other than white space are not
> recognised, such as commas, and cause an error
Right.
> * Floating point numbers (using "." and/or "e") are not recognised;
> those characters cause an error
Right. You can read into a floating-point object if you want to support
floating-point syntax.
> * When an out-of-range number is entered, it reads i32.max (etc) for
> that number, but also generates an error
Yes, and?
> * I mentioned error a few times, when that happens, it goes crazy. I
> think the internal pointer is not stepped past it, and it just reads
> zeros, so it never consumes the rest of the line. So in a loop, it
> just prints zeros over and over again without the user entering
> anything.
It's difficult to respond to that without an example.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-24 01:58 +0100 |
| Message-ID | <sij7sb$bj8$1@dont-email.me> |
| In reply to | #81494 |
On 24/09/2021 00:56, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> * It's not line-oriented; the new lines get out of sync with the data
>> being read
>
> Right, it's not designed to be. For example:
>
> int a, b, c;
> std::cin >> a >> b >> c;
> std::cout << "a=" << a << " b=" << b << " c=" << c << '\n';
>
> The std::cin line reads integer values, skipping white space (which
> includes newlines) before each. If you just want to skip white space
> other than newlines, there's probably a way to do that.
>
> If you want line-oriented input, read a line at a time using
> std::getline() and then parse each line. It's not that hard.
>
> std::string line;
> std::getline(std::cin, line);
> std::stringstream ss(line);
> ss >> a >> b >> c;
Thanks at last somebody posted some actual code instead of just saying
how easy it was. But a couple of things:
* (It needs #include <sstream>)
* If I put this in my loop, and type 10 20 30 on the first line, it
prints 10 20 30; that's fine.
* But if I type only 40 on the next line, it prints 40 20 30. So if
there are fewer entries than expected, it will not do '>> b >> c'; those
values are unchanged from before.
* It's better behaved as it doesn't try to exhaust the same line over
again. But if the input is '10.2 11 12', the output is '10 0 999'. (The
999 is what I've now initialised a,b,c to at the start of each loop.)
>> * If fewer than 3 items are present on a line, then it apparently
>> hangs, with no explanation, waiting for them on the next line
>
> Because it's not line-oriented.
> Because it's not line-oriented.
> Because it's not line-oriented.
Isn't that what I said?
>
>> * Numeric separators within numbers such as "_" and "'" are not
>> recognised, and cause an error
>
> Right. Just how permissive do you think it should be?
For interactive user input - quite permissive. People are quite likely
to type in decimal points or do unexpected things. A full treatment is
hard, but if someone types "100." or 1e2 instead of "100", should that
be a hanging offence?
>> * Numbers which are quoted are not recognised, and cause an error
>
> Right. 123 is a number; "123", “123”, '123', and «123» are not.
If you are reading CSV files and such, fields are sometimes enclosed in
quotes, including numeric fields.
>> * When an out-of-range number is entered, it reads i32.max (etc) for
>> that number, but also generates an error
>
> Yes, and?
That error is the problem.
>
>> * I mentioned error a few times, when that happens, it goes crazy. I
>> think the internal pointer is not stepped past it, and it just reads
>> zeros, so it never consumes the rest of the line. So in a loop, it
>> just prints zeros over and over again without the user entering
>> anything.
>
> It's difficult to respond to that without an example.
I thought I posted it earlier. Here's the code:
#include <iostream>
int main()
{ int a,b,c;
int x=0;
do {
std::cout << "Prompt> ";
std::cin >> a >> b >> c;
std::cout << a << " " << b << " " << c << "\n";
} while (++x<10);
}
And here it is in action; the only input I type in is the '10.2 11 12'
line, the rest just keeps going, and only stops because I cap the output
at 10 lines:
C:\c>a
Prompt> 10.2 11 12
10 0 0
Prompt> 10 0 0
Prompt> 10 0 0
Prompt> 10 0 0
Prompt> 10 0 0
Prompt> 10 0 0
Prompt> 10 0 0
Prompt> 10 0 0
Prompt> 10 0 0
Prompt> 10 0 0
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-24 01:40 +0000 |
| Message-ID | <f0a3J.58173$jm6.51576@fx07.iad> |
| In reply to | #81495 |
int main()
{
string line = "GeeksForGeeks is a must try";
// Vector of string to save tokens
vector <string> tokens;
// stringstream class check1
stringstream check1(line);
string intermediate;
// Tokenizing w.r.t. space ' '
while(getline(check1, intermediate, ' '))
{
tokens.push_back(intermediate);
}
// Printing the token vector
for(int i = 0; i < tokens.size(); i++)
cout << tokens[i] << '\n';
}
--
7-77-777
\|/
/|\
On 2021-09-24, Bart <bc@freeuk.com> wrote:
> On 24/09/2021 00:56, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> * It's not line-oriented; the new lines get out of sync with the data
>>> being read
>>
>> Right, it's not designed to be. For example:
>>
>> int a, b, c;
>> std::cin >> a >> b >> c;
>> std::cout << "a=" << a << " b=" << b << " c=" << c << '\n';
>>
>> The std::cin line reads integer values, skipping white space (which
>> includes newlines) before each. If you just want to skip white space
>> other than newlines, there's probably a way to do that.
>>
>> If you want line-oriented input, read a line at a time using
>> std::getline() and then parse each line. It's not that hard.
>>
>> std::string line;
>> std::getline(std::cin, line);
>> std::stringstream ss(line);
>> ss >> a >> b >> c;
>
> Thanks at last somebody posted some actual code instead of just saying
> how easy it was. But a couple of things:
>
> * (It needs #include <sstream>)
>
> * If I put this in my loop, and type 10 20 30 on the first line, it
> prints 10 20 30; that's fine.
>
> * But if I type only 40 on the next line, it prints 40 20 30. So if
> there are fewer entries than expected, it will not do '>> b >> c'; those
> values are unchanged from before.
>
> * It's better behaved as it doesn't try to exhaust the same line over
> again. But if the input is '10.2 11 12', the output is '10 0 999'. (The
> 999 is what I've now initialised a,b,c to at the start of each loop.)
>
>
>>> * If fewer than 3 items are present on a line, then it apparently
>>> hangs, with no explanation, waiting for them on the next line
>>
>> Because it's not line-oriented.
>
>> Because it's not line-oriented.
>
>> Because it's not line-oriented.
>
> Isn't that what I said?
>
>>
>>> * Numeric separators within numbers such as "_" and "'" are not
>>> recognised, and cause an error
>>
>> Right. Just how permissive do you think it should be?
>
> For interactive user input - quite permissive. People are quite likely
> to type in decimal points or do unexpected things. A full treatment is
> hard, but if someone types "100." or 1e2 instead of "100", should that
> be a hanging offence?
>
>>> * Numbers which are quoted are not recognised, and cause an error
>>
>> Right. 123 is a number; "123", “123”, '123', and «123» are not.
>
> If you are reading CSV files and such, fields are sometimes enclosed in
> quotes, including numeric fields.
>
>>> * When an out-of-range number is entered, it reads i32.max (etc) for
>>> that number, but also generates an error
>>
>> Yes, and?
>
> That error is the problem.
>>
>>> * I mentioned error a few times, when that happens, it goes crazy. I
>>> think the internal pointer is not stepped past it, and it just reads
>>> zeros, so it never consumes the rest of the line. So in a loop, it
>>> just prints zeros over and over again without the user entering
>>> anything.
>>
>> It's difficult to respond to that without an example.
>
> I thought I posted it earlier. Here's the code:
>
> #include <iostream>
>
> int main()
> { int a,b,c;
> int x=0;
> do {
> std::cout << "Prompt> ";
> std::cin >> a >> b >> c;
> std::cout << a << " " << b << " " << c << "\n";
> } while (++x<10);
> }
>
> And here it is in action; the only input I type in is the '10.2 11 12'
> line, the rest just keeps going, and only stops because I cap the output
> at 10 lines:
>
>
> C:\c>a
> Prompt> 10.2 11 12
> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
--
Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-09-23 19:35 -0700 |
| Message-ID | <87v92qlmyx.fsf@nosuchdomain.example.com> |
| In reply to | #81495 |
Bart <bc@freeuk.com> writes:
> On 24/09/2021 00:56, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> * It's not line-oriented; the new lines get out of sync with the data
>>> being read
>> Right, it's not designed to be. For example:
>> int a, b, c;
>> std::cin >> a >> b >> c;
>> std::cout << "a=" << a << " b=" << b << " c=" << c << '\n';
>> The std::cin line reads integer values, skipping white space (which
>> includes newlines) before each. If you just want to skip white space
>> other than newlines, there's probably a way to do that.
>> If you want line-oriented input, read a line at a time using
>> std::getline() and then parse each line. It's not that hard.
>> std::string line;
>> std::getline(std::cin, line);
>> std::stringstream ss(line);
>> ss >> a >> b >> c;
>
> Thanks at last somebody posted some actual code instead of just saying
> how easy it was. But a couple of things:
>
> * (It needs #include <sstream>)
Yes?
> * If I put this in my loop, and type 10 20 30 on the first line, it
> prints 10 20 30; that's fine.
>
> * But if I type only 40 on the next line, it prints 40 20 30. So if
> there are fewer entries than expected, it will not do '>> b >> c';
> those values are unchanged from before.
My quick and dirty code sample didn't check for errors. The user didn't
provide inputs for those values. What exactly do you expect to happen?
You can query ss.good(), ss.bad(), ss.fail(), and ss.eof() to see
whether the input operation succeeded.
> * It's better behaved as it doesn't try to exhaust the same line over
> again. But if the input is '10.2 11 12', the output is '10 0
> 999'. (The 999 is what I've now initialised a,b,c to at the start of
> each loop.)
>
>
>>> * If fewer than 3 items are present on a line, then it apparently
>>> hangs, with no explanation, waiting for them on the next line
>> Because it's not line-oriented.
>
>> Because it's not line-oriented.
>
>> Because it's not line-oriented.
>
> Isn't that what I said?
My point is that you complained that it's not line-oriented (which is a
deliberate design decision) and then complained about the inevitable
consequences of the fact that it's not line-oriented.
>>> * Numeric separators within numbers such as "_" and "'" are not
>>> recognised, and cause an error
>> Right. Just how permissive do you think it should be?
>
> For interactive user input - quite permissive. People are quite likely
> to type in decimal points or do unexpected things. A full treatment is
> hard, but if someone types "100." or 1e2 instead of "100", should that
> be a hanging offence?
Hanging offence? Give me a freaking break.
Numeric input has to define *some* syntax. If you want a different
syntax, implement it. That includes deciding what an integer should be
set to if the input is "1.5". If you like, read it into a string and
try converting that string to whatever you want.
The default input for numeric input is reasonably simple and
straightforward.
>>> * Numbers which are quoted are not recognised, and cause an error
>> Right. 123 is a number; "123", “123”, '123', and «123» are not.
>
> If you are reading CSV files and such, fields are sometimes enclosed
> in quotes, including numeric fields.
>
>>> * When an out-of-range number is entered, it reads i32.max (etc) for
>>> that number, but also generates an error
>> Yes, and?
>
> That error is the problem.
What?
You're not suggesting that it should set the value to INT_MAX *and then
not give any indication that there was a problem*, are you?
>>> * I mentioned error a few times, when that happens, it goes crazy. I
>>> think the internal pointer is not stepped past it, and it just reads
>>> zeros, so it never consumes the rest of the line. So in a loop, it
>>> just prints zeros over and over again without the user entering
>>> anything.
>> It's difficult to respond to that without an example.
>
> I thought I posted it earlier. Here's the code:
>
> #include <iostream>
>
> int main()
> { int a,b,c;
> int x=0;
> do {
> std::cout << "Prompt> ";
> std::cin >> a >> b >> c;
> std::cout << a << " " << b << " " << c << "\n";
> } while (++x<10);
> }
>
> And here it is in action; the only input I type in is the '10.2 11 12'
> line, the rest just keeps going, and only stops because I cap the
> output at 10 lines:
>
> C:\c>a
> Prompt> 10.2 11 12
> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
> Prompt> 10 0 0
The first << operation succeeded, set a to 10, and consumed the
characters '1' and '0'.
The second one failed because it was trying to read an integer value and
saw a '.' character. Try reading an integer again, and it fails again.
If you instead tried to read a string or a character, it would consume
the '.' character and whatever follows it.
If you want to consume and discard incorrect input rather than letting
it remain in the input stream, you can do that by writing different code.
If you do something simple like `std::cin >> a >> b >> c`, it doesn't
give you a way to determine which input operation failed -- but you can
tell whether they were all successful or not. Sometimes that's good
enough. If it isn't, write different code.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2021-09-24 09:07 -0700 |
| Message-ID | <4cee1aa2-abb0-40bc-bd44-85441921817dn@googlegroups.com> |
| In reply to | #81497 |
On Thursday, September 23, 2021 at 10:35:44 PM UTC-4, Keith Thompson wrote: > > If you do something simple like `std::cin >> a >> b >> c`, it doesn't > give you a way to determine which input operation failed -- but you can > tell whether they were all successful or not. Sometimes that's good > enough. If it isn't, write different code. I see `std::cout << a` in real code, but I don't see `std::cin >> a >> b >> c` in anything other than toy examples. If we have something, we can send that to `std::cout` without worrying about it, but input invariably has to be validated. Daniel
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2021-09-24 09:21 -0700 |
| Message-ID | <03ae4a4c-5675-4102-be7a-592be0c5de06n@googlegroups.com> |
| In reply to | #81495 |
On Thursday, September 23, 2021 at 8:59:02 PM UTC-4, Bart wrote: > If you are reading CSV files and such, fields are sometimes enclosed in > quotes, including numeric fields. I don't think anybody would attempt to read a CSV file with `<istream> >> field1 >> field2 >> field3` notation. But of course line oriented input wouldn't be of much help here either, in general. As to a number enclosed in quotes, I think a typical CSV parser would by default interpret that as string, but perhaps provide an option to interpret a quoted value in a specified column as a number. Daniel
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-23 14:58 +0000 |
| Message-ID | <sii4n8$d8m$1@gioia.aioe.org> |
| In reply to | #81458 |
On Thu, 23 Sep 2021 12:21:48 +0100 Bart <bc@freeuk.com> wrote: >On 23/09/2021 11:26, HorseyWorsey@the_stables.com wrote: >> 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? Its not exactly rocket science. C++ isn't and isn't intended to be a hand holding scripting language, some things you have to know how to do yourself. > 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. C++ cin is as useless as C's scanf() for doing actual real world stdin input processing. Unless the users follows the expected format then it all blows up. As I said, you read in the entire string then parse it using std::string find() and substr() or C's strtok() or even raw pointers. Either way an experienced programmer should take longer than 20 mins to come up with something.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-23 17:02 +0100 |
| Message-ID | <sii8f5$q42$1@dont-email.me> |
| In reply to | #81467 |
On 23/09/2021 15:58, HorseyWorsey@the_stables.com wrote: > On Thu, 23 Sep 2021 12:21:48 +0100 > Bart <bc@freeuk.com> wrote: >> On 23/09/2021 11:26, HorseyWorsey@the_stables.com wrote: >>> 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? > > Its not exactly rocket science. C++ isn't and isn't intended to be a hand > holding scripting language, some things you have to know how to do yourself. I usually devise my own languages, including those for systems programming. Without exception they had means to do line-based i/o as one of the first things implemented. Is that the attitude here, that such fundamental features are to be looked down upon because they would make life too easy? Or is this another Unix characteristic bestowed upon the world (on top of case-sensitivity etc): character-based i/o rather than line-based? > >> 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. > > C++ cin is as useless as C's scanf() for doing actual real world stdin input > processing. Unless the users follows the expected format then it all blows up. > As I said, you read in the entire string then parse it using std::string find() > and substr() or C's strtok() or even raw pointers. Either way an experienced > programmer should take longer than 20 mins to come up with something. In other words, a million programmers have to keep reinventing the same thing. Or a million variations of the same thing.
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-23 16:21 +0000 |
| Message-ID | <sii9i0$spf$1@gioia.aioe.org> |
| In reply to | #81469 |
On Thu, 23 Sep 2021 17:02:36 +0100 Bart <bc@freeuk.com> wrote: >On 23/09/2021 15:58, HorseyWorsey@the_stables.com wrote: >> Its not exactly rocket science. C++ isn't and isn't intended to be a hand >> holding scripting language, some things you have to know how to do yourself. > >I usually devise my own languages, including those for systems programming. Clever you. >Is that the attitude here, that such fundamental features are to be >looked down upon because they would make life too easy? Your attitude seems to be "C++ doesn't do what I want therefore its crap". C++ is what it is. If you don't like it use another language, you have plenty to choose from including your own. >> As I said, you read in the entire string then parse it using std::string >find() >> and substr() or C's strtok() or even raw pointers. Either way an experienced >> programmer should take longer than 20 mins to come up with something. > >In other words, a million programmers have to keep reinventing the same >thing. Or a million variations of the same thing. Since a basic line splitter is easy for any half competant programmer and anything more complex - ie a parser - is usually tuned for a particular need what would be the point? C++ has already had the kitchen sink thrown into it because of people like you yet you want even basic stuff done for you? What next , concatenation too hard? Perhaps a built in function that automatically concats a vector of strings for you? Maybe you'd be better off using javascript.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-23 18:31 +0100 |
| Message-ID | <siidlv$2ac$1@dont-email.me> |
| In reply to | #81472 |
On 23/09/2021 17:21, HorseyWorsey@the_stables.com wrote: > On Thu, 23 Sep 2021 17:02:36 +0100 > Bart <bc@freeuk.com> wrote: >> On 23/09/2021 15:58, HorseyWorsey@the_stables.com wrote: >>> Its not exactly rocket science. C++ isn't and isn't intended to be a hand >>> holding scripting language, some things you have to know how to do yourself. >> >> I usually devise my own languages, including those for systems programming. > > Clever you. > >> Is that the attitude here, that such fundamental features are to be >> looked down upon because they would make life too easy? > > Your attitude seems to be "C++ doesn't do what I want therefore its crap". > C++ is what it is. If you don't like it use another language, you have plenty > to choose from including your own. > >>> As I said, you read in the entire string then parse it using std::string >> find() >>> and substr() or C's strtok() or even raw pointers. Either way an experienced >>> programmer should take longer than 20 mins to come up with something. >> >> In other words, a million programmers have to keep reinventing the same >> thing. Or a million variations of the same thing. > > Since a basic line splitter is easy for any half competant programmer and > anything more complex - ie a parser - is usually tuned for a particular need > what would be the point? C++ has already had the kitchen sink thrown into it > because of people like you yet you want even basic stuff done for you? This is the paradox: C++ has a lot of hugely complicated but neglects the basics. And it's just C++ but a lot of current languages, because they have their focus elsewhere. (I especially know about Python.) An effective basic Print (and Read) needs language support otherwise it becomes a pain to use. The support needed is not significant. My proof-of-concept to add automatic printf format codes to a C compiler (so you do "%?" for any basic type instead of "%d" etc), was 50 lines of code. That would simplify the maintenance of a billion codes of code. What > next , concatenation too hard? Perhaps a built in function that automatically > concats a vector of strings for you? Maybe you'd be better off using javascript. So. why bother with even std::cout (I still don't know what that actually is) or printf? Just have fgetc and fputc. After all how hard can it be to knock up an int-to-string converter? The language already has enough stuff in it!
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-24 09:12 +0000 |
| Message-ID | <sik4qg$m7d$1@gioia.aioe.org> |
| In reply to | #81481 |
On Thu, 23 Sep 2021 18:31:34 +0100 Bart <bc@freeuk.com> wrote: >On 23/09/2021 17:21, HorseyWorsey@the_stables.com wrote: >> Since a basic line splitter is easy for any half competant programmer and >> anything more complex - ie a parser - is usually tuned for a particular need >> what would be the point? C++ has already had the kitchen sink thrown into it >> because of people like you yet you want even basic stuff done for you? > >This is the paradox: C++ has a lot of hugely complicated but neglects >the basics. > >And it's just C++ but a lot of current languages, because they have >their focus elsewhere. (I especially know about Python.) > >An effective basic Print (and Read) needs language support otherwise it >becomes a pain to use. > >The support needed is not significant. My proof-of-concept to add >automatic printf format codes to a C compiler (so you do "%?" for any >basic type instead of "%d" etc), was 50 lines of code. 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. It could have been done for C++ which has RTTI anyway but stroustrup went with iostream instead. >> concats a vector of strings for you? Maybe you'd be better off using >javascript. > >So. why bother with even std::cout (I still don't know what that >actually is) or printf? Just have fgetc and fputc. As you well know the point of cout is to allow output of complex objects which have overloaded << without having to call a converter function first. If all you're doing is outputting formatted strings then IMO *printf() is a better choice because its more expressive and compact. >After all how hard can it be to knock up an int-to-string converter? The A universal number to string converter is actually quite complex as it has to deal with IEEE 754 floating point format not to mention negative numbers and formatting.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-24 12:10 +0100 |
| Message-ID | <sikbmk$s6d$1@dont-email.me> |
| In reply to | #81505 |
On 24/09/2021 10:12, HorseyWorsey@the_stables.com wrote:
> On Thu, 23 Sep 2021 18:31:34 +0100
> Bart <bc@freeuk.com> wrote:
>> On 23/09/2021 17:21, HorseyWorsey@the_stables.com wrote:
>>> Since a basic line splitter is easy for any half competant programmer and
>>> anything more complex - ie a parser - is usually tuned for a particular need
>>> what would be the point? C++ has already had the kitchen sink thrown into it
>>> because of people like you yet you want even basic stuff done for you?
>>
>> This is the paradox: C++ has a lot of hugely complicated but neglects
>> the basics.
>>
>> And it's just C++ but a lot of current languages, because they have
>> their focus elsewhere. (I especially know about Python.)
>>
>> An effective basic Print (and Read) needs language support otherwise it
>> becomes a pain to use.
>>
>> The support needed is not significant. My proof-of-concept to add
>> automatic printf format codes to a C compiler (so you do "%?" for any
>> basic type instead of "%d" etc), was 50 lines of code.
>
> 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.
> It could have been done for C++ which has RTTI
> anyway but stroustrup went with iostream instead.
>
>>> concats a vector of strings for you? Maybe you'd be better off using
>> javascript.
>>
>> So. why bother with even std::cout (I still don't know what that
>> actually is) or printf? Just have fgetc and fputc.
>
> As you well know the point of cout is to allow output of complex objects
> which have overloaded << without having to call a converter function first.
Actually no I don't. I'm still not entirely clear how << works, other
than it is 100% unintuitive.
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 ...
I'm just surprised you don't have to type:
... A std::<< " " std::<< B ...
> If all you're doing is outputting formatted strings then IMO *printf() is a
> better choice because its more expressive and compact.
Yeah. It takes a lot to suddenly make printf seem much better!
>> After all how hard can it be to knock up an int-to-string converter? The
>
> A universal number to string converter is actually quite complex as it has to
> deal with IEEE 754 floating point format not to mention negative numbers and
> formatting.
Negative numbers aren't that difficult actually...
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-24 11:23 +0000 |
| Message-ID | <czi3J.118681$Kv2.54329@fx47.iad> |
| In reply to | #81512 |
For example of type safe print take a look at Bjarne's BOOK.
--
7-77-777
\|/
---
/|\
On 2021-09-24, Bart <bc@freeuk.com> wrote:
> On 24/09/2021 10:12, HorseyWorsey@the_stables.com wrote:
>> On Thu, 23 Sep 2021 18:31:34 +0100
>> Bart <bc@freeuk.com> wrote:
>>> On 23/09/2021 17:21, HorseyWorsey@the_stables.com wrote:
>>>> Since a basic line splitter is easy for any half competant programmer and
>>>> anything more complex - ie a parser - is usually tuned for a particular need
>>>> what would be the point? C++ has already had the kitchen sink thrown into it
>>>> because of people like you yet you want even basic stuff done for you?
>>>
>>> This is the paradox: C++ has a lot of hugely complicated but neglects
>>> the basics.
>>>
>>> And it's just C++ but a lot of current languages, because they have
>>> their focus elsewhere. (I especially know about Python.)
>>>
>>> An effective basic Print (and Read) needs language support otherwise it
>>> becomes a pain to use.
>>>
>>> The support needed is not significant. My proof-of-concept to add
>>> automatic printf format codes to a C compiler (so you do "%?" for any
>>> basic type instead of "%d" etc), was 50 lines of code.
>>
>> 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.
>
>> It could have been done for C++ which has RTTI
>> anyway but stroustrup went with iostream instead.
>>
>>>> concats a vector of strings for you? Maybe you'd be better off using
>>> javascript.
>>>
>>> So. why bother with even std::cout (I still don't know what that
>>> actually is) or printf? Just have fgetc and fputc.
>>
>> As you well know the point of cout is to allow output of complex objects
>> which have overloaded << without having to call a converter function first.
>
> Actually no I don't. I'm still not entirely clear how << works, other
> than it is 100% unintuitive.
>
> 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 ...
>
> I'm just surprised you don't have to type:
>
> ... A std::<< " " std::<< B ...
>
>
>> If all you're doing is outputting formatted strings then IMO *printf() is a
>> better choice because its more expressive and compact.
>
> Yeah. It takes a lot to suddenly make printf seem much better!
>
>>> After all how hard can it be to knock up an int-to-string converter? The
>>
>> A universal number to string converter is actually quite complex as it has to
>> deal with IEEE 754 floating point format not to mention negative numbers and
>> formatting.
>
> Negative numbers aren't that difficult actually...
>
>
--
Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-24 15:19 +0000 |
| Message-ID | <sikqav$1feu$1@gioia.aioe.org> |
| In reply to | #81512 |
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?
>> As you well know the point of cout is to allow output of complex objects
>> which have overloaded << without having to call a converter function first.
>
>Actually no I don't. I'm still not entirely clear how << works, other
>than it is 100% unintuitive.
So you're complaining about basic C++ functionality you don't even understand.
Got it.
>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? 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. Plus a comma already has syntactic
meaning in C & C++.
>> A universal number to string converter is actually quite complex as it has to
>
>> deal with IEEE 754 floating point format not to mention negative numbers and
>> formatting.
>
>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.
[toc] | [prev] | [next] | [standalone]
Page 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
Back to top | Article view | comp.lang.c++
csiph-web