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 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-22 11:26 +0100 |
| Message-ID | <sif0dp$cfh$1@dont-email.me> |
| In reply to | #81401 |
On 22/09/2021 05:58, Juha Nieminen wrote:
> Bart <bc@freeuk.com> wrote:
>>> What doesn't make sense to you?
>>
>> Having to overload "<<", as I assume you meant, as you seemed to imply
>> that was better/easier than doing whatever it was to obj to allow its
>> use in function syntax.
>
> So what's the alternative that you suggest?
Overloading whatever 'tostring' operations that are implicitly used when
printing.
>
>>> So if one of them is, say, a list of a thousand objects, and you want to
>>> print that list like that, it will dynamically allocate and construct a
>>> huge string, which gets printed, and then destroyed?
>>>
>>> Instead of, you know, the object just printing every element individually,
>>> requiring no extra memory and no extra allocations. Something that
>>> overloading operator<< easily achieves.
>>
>>
>> This is a drawback of having a 'tostring' method applied to an entire,
>> complex object.
>>
>> However, if the object is that complex, it will already be using
>> equivalent amounts of memory anyway.
>
> The string will be constructed *in addition* to whatever memory the object
> may be taking, and it will be constructed solely for the printing process,
> and then immediately destroyed.
>
> This even though there's no reason to construct such a string into RAM,
> as each element could just be printed to the output individually by the
> object, without having to construct any strings.
OK, let's try it. Here's a program that writes 1 million lines of the
same 3 variables:
#include <iostream>
#include <fstream>
using namespace std;
int main () {
ofstream myfile;
long long int a = 0x7FFFFFFFFFFFFFFF;
double b = 3.14159265359;
const char* c = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
myfile.open ("output");
for (int i=0; i<1000000; ++i) {
myfile << a << " " << b << " " << c << "\n";
}
myfile.close();
return 0;
}
On my machine, that took 4 seconds. But when I tried my script language,
where each element has to be converted to a string object before being
printed, it took only 3 seconds:
a := int64.max
b := pi
c := "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
f:=createfile("output")
to 1 million do
println @f, a,b,c
od
closefile(f)
But now look at this version, which makes use of that sprint() routine
that you derided in another post; this one takes only 2.1 seconds:
a := int64.max
b := pi
c := "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
s ::= ""
to 1 million do
s +:= sprint(a,b,c,"\n")
od
writestrfile("output",s)
(It seems that a sprintln() version would be useful to avoid that
explicit "\n" argument, and make it even faster.)
Perhaps you shouldn't write off these pesky scripting languages so
quickly...
[Timings shown for my language is for when the interpreter is transpiled
to C and compiled with gcc-O3. That's only available with an older
version. The new version doesn't have a C option and will be 30% slower
until a C target is reinstated. C++ timings use g++-O2]
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-22 23:13 +1200 |
| Message-ID | <ir0hfkFj3liU1@mid.individual.net> |
| In reply to | #81409 |
On 22/09/2021 22:26, Bart wrote:
>
> OK, let's try it. Here's a program that writes 1 million lines of the
> same 3 variables:
>
> #include <iostream>
> #include <fstream>
> using namespace std;
>
> int main () {
> ofstream myfile;
> long long int a = 0x7FFFFFFFFFFFFFFF;
> double b = 3.14159265359;
> const char* c = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
>
> myfile.open ("output");
> for (int i=0; i<1000000; ++i) {
> myfile << a << " " << b << " " << c << "\n";
> }
> myfile.close();
> return 0;
> }
>
> On my machine, that took 4 seconds.
This will take roughly the time it takes to perform the file writing
(0.4S on my machine). The time spend formatting the output is
inconsequential in comparison.
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-22 13:45 +0100 |
| Message-ID | <sif8gj$649$1@dont-email.me> |
| In reply to | #81413 |
On 22/09/2021 12:13, Ian Collins wrote:
> On 22/09/2021 22:26, Bart wrote:
>>
>> OK, let's try it. Here's a program that writes 1 million lines of the
>> same 3 variables:
>>
>> #include <iostream>
>> #include <fstream>
>> using namespace std;
>>
>> int main () {
>> ofstream myfile;
>> long long int a = 0x7FFFFFFFFFFFFFFF;
>> double b = 3.14159265359;
>> const char* c = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
>>
>> myfile.open ("output");
>> for (int i=0; i<1000000; ++i) {
>> myfile << a << " " << b << " " << c << "\n";
>> }
>> myfile.close();
>> return 0;
>> }
>>
>> On my machine, that took 4 seconds.
>
> This will take roughly the time it takes to perform the file writing
> (0.4S on my machine). The time spend formatting the output is
> inconsequential in comparison.
But you don't know that? On my machine, timing went from 4.3 seconds to
5.3 seconds if I changed the output file from "output" to "nul"
(Windows' version of a null device, not a very effective one!).
I don't know how to isolate the file i/o from the conversion in C++. If
I switch to C *printf functions, then going from fprintf to sprintf,
changes the timing from 4.3 seconds to 0.8 seconds; so more than 80% is
writing via the file system.
I wanted to determine the overheads of using "<<" on each print item,
especially as there are 3 extra arguments of " ", " " and "\n".
These latter overheads are irrelevant when using the format string of
sprintf.
The question posed was whether turning into individual print items into
a string object, before sending that string to the output, was a
significant overhead.
I showed my /dynamic/ code wasn't significantly slower than C++
(actually it was faster) despite doing those conversions, plus a whole
bunch of other overheads that C++ will not have.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-24 21:37 +1200 |
| Message-ID | <ir5kj5Fj3ljU3@mid.individual.net> |
| In reply to | #81417 |
On 23/09/2021 00:45, Bart wrote:
> On 22/09/2021 12:13, Ian Collins wrote:
>> On 22/09/2021 22:26, Bart wrote:
>>>
>>> OK, let's try it. Here's a program that writes 1 million lines of the
>>> same 3 variables:
>>>
>>> #include <iostream>
>>> #include <fstream>
>>> using namespace std;
>>>
>>> int main () {
>>> ofstream myfile;
>>> long long int a = 0x7FFFFFFFFFFFFFFF;
>>> double b = 3.14159265359;
>>> const char* c = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
>>>
>>> myfile.open ("output");
>>> for (int i=0; i<1000000; ++i) {
>>> myfile << a << " " << b << " " << c << "\n";
>>> }
>>> myfile.close();
>>> return 0;
>>> }
>>>
>>> On my machine, that took 4 seconds.
>>
>> This will take roughly the time it takes to perform the file writing
>> (0.4S on my machine). The time spend formatting the output is
>> inconsequential in comparison.
>
>
> But you don't know that? On my machine, timing went from 4.3 seconds to
> 5.3 seconds if I changed the output file from "output" to "nul"
> (Windows' version of a null device, not a very effective one!).
>
> I don't know how to isolate the file i/o from the conversion in C++. If
> I switch to C *printf functions, then going from fprintf to sprintf,
> changes the timing from 4.3 seconds to 0.8 seconds; so more than 80% is
> writing via the file system.
>
> I wanted to determine the overheads of using "<<" on each print item,
> especially as there are 3 extra arguments of " ", " " and "\n".
>
> These latter overheads are irrelevant when using the format string of
> sprintf.
>
> The question posed was whether turning into individual print items into
> a string object, before sending that string to the output, was a
> significant overhead.
The answer is in comparison with doing the actual output, no.
> I showed my /dynamic/ code wasn't significantly slower than C++
> (actually it was faster) despite doing those conversions, plus a whole
> bunch of other overheads that C++ will not have.
What you showed is the implementation you are using is really really
(10x slower than my unimpressive laptop) slow!
-
Ian.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-22 15:29 +0300 |
| Message-ID | <sif7ie$uc1$1@dont-email.me> |
| In reply to | #81409 |
22.09.2021 13:26 Bart kirjutas:
> On 22/09/2021 05:58, Juha Nieminen wrote:
>> Bart <bc@freeuk.com> wrote:
>>>> What doesn't make sense to you?
>>>
>>> Having to overload "<<", as I assume you meant, as you seemed to imply
>>> that was better/easier than doing whatever it was to obj to allow its
>>> use in function syntax.
>>
>> So what's the alternative that you suggest?
>
> Overloading whatever 'tostring' operations that are implicitly used when
> printing.
>
>>
>>>> So if one of them is, say, a list of a thousand objects, and you
>>>> want to
>>>> print that list like that, it will dynamically allocate and construct a
>>>> huge string, which gets printed, and then destroyed?
>>>>
>>>> Instead of, you know, the object just printing every element
>>>> individually,
>>>> requiring no extra memory and no extra allocations. Something that
>>>> overloading operator<< easily achieves.
>>>
>>>
>>> This is a drawback of having a 'tostring' method applied to an entire,
>>> complex object.
>>>
>>> However, if the object is that complex, it will already be using
>>> equivalent amounts of memory anyway.
>>
>> The string will be constructed *in addition* to whatever memory the
>> object
>> may be taking, and it will be constructed solely for the printing
>> process,
>> and then immediately destroyed.
>>
>> This even though there's no reason to construct such a string into RAM,
>> as each element could just be printed to the output individually by the
>> object, without having to construct any strings.
>
> OK, let's try it. Here's a program that writes 1 million lines of the
> same 3 variables:
>
> #include <iostream>
> #include <fstream>
> using namespace std;
>
> int main () {
> ofstream myfile;
> long long int a = 0x7FFFFFFFFFFFFFFF;
> double b = 3.14159265359;
> const char* c = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
>
> myfile.open ("output");
> for (int i=0; i<1000000; ++i) {
> myfile << a << " " << b << " " << c << "\n";
> }
> myfile.close();
> return 0;
> }
>
> On my machine, that took 4 seconds. But when I tried my script language,
> where each element has to be converted to a string object before being
> printed, it took only 3 seconds:
A better comparison would be to measure the time of converting and
appending a million numbers to a std::string, then outputting the huge
string in one go.
The C++ iostreams can be very slow and the timings depend on the
implementation. In my experiments I saw that ostream << can be either
10x slower than huge string building (MSVC++ 2019), or then 2x faster
(g++ 8.3). I streamed to an in-memory ostringstream, so there was no
disk slowdown involved.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-23 07:26 +0000 |
| Message-ID | <siha6m$1ar3$1@gioia.aioe.org> |
| In reply to | #81409 |
Bart <bc@freeuk.com> wrote: >>> Having to overload "<<", as I assume you meant, as you seemed to imply >>> that was better/easier than doing whatever it was to obj to allow its >>> use in function syntax. >> >> So what's the alternative that you suggest? > > Overloading whatever 'tostring' operations that are implicitly used when > printing. So your only alternative is to only support a "tostring" function? How about thanks, but no thanks? I'll take the operator<< overloading if your suggestions is the only available alternative. > OK, let's try it. Here's a program that writes 1 million lines of the > same 3 variables: You are comparing the seed of std::ostream to some other way of writing to a file. You are not comparing string creation vs. direct writing of values.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-19 21:54 +0000 |
| Message-ID | <gkO1J.90181$rl3.18099@fx45.iad> |
| In reply to | #81329 |
Juha Nieminen <nospam@thanks.invalid> writes: >Bart <bc@freeuk.com> wrote: >> Yes, because it is so peculiar. I wouldn't know how to create such a >> function, but it would have been a better way of presenting a print >> feature, and more conventional. > >The basic idea with overloading a binary operator, rather than using a >function call syntax, is that the output can be expanded with your own >custom types (which is not really possible if it used a function call >syntax). > >In other words, you can achieve this: > > MyClass obj; > std::cout << "Value = " << obj << "\n"; fprintf(stdout, "Value = %s\n" obj.to_string());
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-20 00:31 +0100 |
| Message-ID | <si8h8v$pt0$1@dont-email.me> |
| In reply to | #81334 |
On 19/09/2021 22:54, Scott Lurndal wrote: > Juha Nieminen <nospam@thanks.invalid> writes: >> Bart <bc@freeuk.com> wrote: >>> Yes, because it is so peculiar. I wouldn't know how to create such a >>> function, but it would have been a better way of presenting a print >>> feature, and more conventional. >> >> The basic idea with overloading a binary operator, rather than using a >> function call syntax, is that the output can be expanded with your own >> custom types (which is not really possible if it used a function call >> syntax). >> >> In other words, you can achieve this: >> >> MyClass obj; >> std::cout << "Value = " << obj << "\n"; > > fprintf(stdout, "Value = %s\n" obj.to_string()); > I don't know how well C++ can match even a simple scripting language in capabilities. But there, you could do something like this: x := (obj1, obj2, obj3) # list of 3 objects All objects could be of different types, with their own to-string methods. But even if all of the same type, you'd need this: print x to apply those custom to-string methods to the elements of x without being told. Include x itself if that had its own to-string routine.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-20 08:33 +0200 |
| Message-ID | <si9a0a$vgn$1@dont-email.me> |
| In reply to | #81336 |
On 20/09/2021 01:31, Bart wrote: > On 19/09/2021 22:54, Scott Lurndal wrote: >> Juha Nieminen <nospam@thanks.invalid> writes: >>> Bart <bc@freeuk.com> wrote: >>>> Yes, because it is so peculiar. I wouldn't know how to create such a >>>> function, but it would have been a better way of presenting a print >>>> feature, and more conventional. >>> >>> The basic idea with overloading a binary operator, rather than using a >>> function call syntax, is that the output can be expanded with your own >>> custom types (which is not really possible if it used a function call >>> syntax). >>> >>> In other words, you can achieve this: >>> >>> MyClass obj; >>> std::cout << "Value = " << obj << "\n"; >> >> fprintf(stdout, "Value = %s\n" obj.to_string()); >> > > I don't know how well C++ can match even a simple scripting language in > capabilities. But there, you could do something like this: > > x := (obj1, obj2, obj3) # list of 3 objects > > All objects could be of different types, with their own to-string > methods. But even if all of the same type, you'd need this: > > print x > > to apply those custom to-string methods to the elements of x without > being told. Include x itself if that had its own to-string routine. > There should be no problem making a variadic template function "print" that turns "print(a, b, c);" into "cout << a << b << c;", if someone really dislikes the << syntax. It could also turn it into "cout << a.to_string() << ' ' << b.to_string() << ' ' << c.to_string();", or whatever is the day's preference.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-20 16:11 +0100 |
| Message-ID | <sia8ap$qft$1@dont-email.me> |
| In reply to | #81344 |
On 20/09/2021 07:33, David Brown wrote:
> On 20/09/2021 01:31, Bart wrote:
>> On 19/09/2021 22:54, Scott Lurndal wrote:
>>> Juha Nieminen <nospam@thanks.invalid> writes:
>>>> Bart <bc@freeuk.com> wrote:
>>>>> Yes, because it is so peculiar. I wouldn't know how to create such a
>>>>> function, but it would have been a better way of presenting a print
>>>>> feature, and more conventional.
>>>>
>>>> The basic idea with overloading a binary operator, rather than using a
>>>> function call syntax, is that the output can be expanded with your own
>>>> custom types (which is not really possible if it used a function call
>>>> syntax).
>>>>
>>>> In other words, you can achieve this:
>>>>
>>>> MyClass obj;
>>>> std::cout << "Value = " << obj << "\n";
>>>
>>> fprintf(stdout, "Value = %s\n" obj.to_string());
>>>
>>
>> I don't know how well C++ can match even a simple scripting language in
>> capabilities. But there, you could do something like this:
>>
>> x := (obj1, obj2, obj3) # list of 3 objects
>>
>> All objects could be of different types, with their own to-string
>> methods. But even if all of the same type, you'd need this:
>>
>> print x
>>
>> to apply those custom to-string methods to the elements of x without
>> being told. Include x itself if that had its own to-string routine.
>>
>
> There should be no problem making a variadic template function "print"
> that turns "print(a, b, c);" into "cout << a << b << c;", if someone
> really dislikes the << syntax. It could also turn it into "cout <<
> a.to_string() << ' ' << b.to_string() << ' ' << c.to_string();", or
> whatever is the day's preference.
>
>
>
My guess is cout and << (don't ask me to explain the difference, except
one needs to go at the start!) are already implemented on top of a stack
of language-defining features.
Now you're saying that we need more templates on top of that to make the
syntax palatable.
It's not surprising that people complain about C++ being slower to compile!
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.
(I would also separate the main job of Print - serialising values into
text - from doing any output.
My print statements also come as the function-like sprint()/sfprint()
that just return a string anyway.
While normal Print statements can take a optional destination that tell
it what to do with the text representation it creates:
print x # to console
print @f, x # to a file handle
print @s, x # to a string buffer
print @w, x # (old versions) to a GUI window
print @b, x # to an image buffer
Unlike streams, these are easy to get your head around.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-20 18:08 +0200 |
| Message-ID | <siablt$tjq$1@dont-email.me> |
| In reply to | #81346 |
On 20/09/2021 17:11, Bart wrote: > On 20/09/2021 07:33, David Brown wrote: >> On 20/09/2021 01:31, Bart wrote: >>> On 19/09/2021 22:54, Scott Lurndal wrote: >>>> Juha Nieminen <nospam@thanks.invalid> writes: >>>>> Bart <bc@freeuk.com> wrote: >>>>>> Yes, because it is so peculiar. I wouldn't know how to create such a >>>>>> function, but it would have been a better way of presenting a print >>>>>> feature, and more conventional. >>>>> >>>>> The basic idea with overloading a binary operator, rather than using a >>>>> function call syntax, is that the output can be expanded with your own >>>>> custom types (which is not really possible if it used a function call >>>>> syntax). >>>>> >>>>> In other words, you can achieve this: >>>>> >>>>> MyClass obj; >>>>> std::cout << "Value = " << obj << "\n"; >>>> >>>> fprintf(stdout, "Value = %s\n" obj.to_string()); >>>> >>> >>> I don't know how well C++ can match even a simple scripting language in >>> capabilities. But there, you could do something like this: >>> >>> x := (obj1, obj2, obj3) # list of 3 objects >>> >>> All objects could be of different types, with their own to-string >>> methods. But even if all of the same type, you'd need this: >>> >>> print x >>> >>> to apply those custom to-string methods to the elements of x without >>> being told. Include x itself if that had its own to-string routine. >>> >> >> There should be no problem making a variadic template function "print" >> that turns "print(a, b, c);" into "cout << a << b << c;", if someone >> really dislikes the << syntax. It could also turn it into "cout << >> a.to_string() << ' ' << b.to_string() << ' ' << c.to_string();", or >> whatever is the day's preference. >> >> >> > > My guess is cout and << (don't ask me to explain the difference, except > one needs to go at the start!) are already implemented on top of a stack > of language-defining features. If you want to learn C++, learn C++. Please stop giving opinions on everything you hate about it, or all the limitations and problems you think it has, when you know so very little about the language. > > Now you're saying that we need more templates on top of that to make the > syntax palatable. No. I am saying that /if/ you really want to have the syntax "print(a, b, c)", or /if/ you really want to have printing based on "to_string()" methods, then you can do so. The std::cout and iostream system has its limitations - we are all aware of that. The C++ standards committee is aware of that, and there is a new system in the works that is more modern. I'm sure plenty of people will find things they like about the new system, and plenty will find things they don't like - that is the nature of /every/ programming language except perhaps ones written by a single person, and used by that same single person. > > It's not surprising that people complain about C++ being slower to compile! > > 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. <snip pointless repetition of how well your our personal language suits your own personal preferences>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-20 18:39 +0100 |
| Message-ID | <siagvq$a0c$1@dont-email.me> |
| In reply to | #81347 |
On 20/09/2021 17:08, David Brown wrote: > On 20/09/2021 17:11, Bart wrote: >> My guess is cout and << (don't ask me to explain the difference, except >> one needs to go at the start!) are already implemented on top of a stack >> of language-defining features. > > If you want to learn C++, learn C++. Please stop giving opinions on > everything you hate about it, or all the limitations and problems you > think it has, when you know so very little about the language. You don't need to know C++ inside out to have an opinion about it or about language design, or for it to help you in knowing which avenues not to pursue, since you can see how it's ended up: in a vastly complex and cumbersome language near-impossible for an individual to implement. Most of what C++ can do, can be done much more simply in any scripting language, and much more quickly; it just won't run as fast. Any new features, C++ also seems to delight in making as comprehensive and complicated as possible (perhaps in keeping with the spirit of the language!). My job tends to be the opposite. >> 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. > > <snip pointless repetition of how well your our personal language suits > your own personal preferences> Simple Print would suit a lot of people (ie. genuinely simple not just piling on more layers in order to emulate 'simple') Separating text conversions from i/o is also useful; 'cout' seems to conflate those operations. My examples should have made it clear; I'm sorry if I had to use my own language, since suitable alternatives are thin on the ground. Just pretend they are hypothetical pseudo-code; after all 'print x' could be from anywhere (mostly from the 1970s unfortunately).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-20 19:49 +0200 |
| Message-ID | <siahjp$k2p$1@dont-email.me> |
| In reply to | #81348 |
On 20/09/2021 19:39, Bart wrote: > On 20/09/2021 17:08, David Brown wrote: >> On 20/09/2021 17:11, Bart wrote: > >>> My guess is cout and << (don't ask me to explain the difference, except >>> one needs to go at the start!) are already implemented on top of a stack >>> of language-defining features. >> >> If you want to learn C++, learn C++. Please stop giving opinions on >> everything you hate about it, or all the limitations and problems you >> think it has, when you know so very little about the language. > > You don't need to know C++ inside out to have an opinion about it or > about language design, or for it to help you in knowing which avenues > not to pursue, since you can see how it's ended up: in a vastly complex > and cumbersome language near-impossible for an individual to implement. > It's true that you don't need much knowledge about a subject to have an opinion. You only need to know what you are talking about to have an /informed/ opinion - one worth listening to and discussing.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-20 19:04 +0100 |
| Message-ID | <siaifp$8u1$1@dont-email.me> |
| In reply to | #81349 |
On 20/09/2021 18:49, David Brown wrote: > On 20/09/2021 19:39, Bart wrote: >> On 20/09/2021 17:08, David Brown wrote: >>> On 20/09/2021 17:11, Bart wrote: >> >>>> My guess is cout and << (don't ask me to explain the difference, except >>>> one needs to go at the start!) are already implemented on top of a stack >>>> of language-defining features. >>> >>> If you want to learn C++, learn C++. Please stop giving opinions on >>> everything you hate about it, or all the limitations and problems you >>> think it has, when you know so very little about the language. >> >> You don't need to know C++ inside out to have an opinion about it or >> about language design, or for it to help you in knowing which avenues >> not to pursue, since you can see how it's ended up: in a vastly complex >> and cumbersome language near-impossible for an individual to implement. >> > > It's true that you don't need much knowledge about a subject to have an > opinion. You only need to know what you are talking about to have an > /informed/ opinion - one worth listening to and discussing. You're right: someone who's only implemented PRINT in various languages a few dozen times can't be expected to have an informed opinion about how well cout or printf tackles the job. (I think I first had PRINT going in a toy BASIC interpreter I knocked up one bored afternoon, running on a PDP11. Although the expressions it could deal with were very limited, it could still do: 20 PRINT X so was still better than cout or printf 40+ years later!)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-20 21:35 +0200 |
| Message-ID | <sianpk$lq5$1@dont-email.me> |
| In reply to | #81350 |
On 20/09/2021 20:04, Bart wrote: > On 20/09/2021 18:49, David Brown wrote: >> On 20/09/2021 19:39, Bart wrote: >>> On 20/09/2021 17:08, David Brown wrote: >>>> On 20/09/2021 17:11, Bart wrote: >>> >>>>> My guess is cout and << (don't ask me to explain the difference, >>>>> except >>>>> one needs to go at the start!) are already implemented on top of a >>>>> stack >>>>> of language-defining features. >>>> >>>> If you want to learn C++, learn C++. Please stop giving opinions on >>>> everything you hate about it, or all the limitations and problems you >>>> think it has, when you know so very little about the language. >>> >>> You don't need to know C++ inside out to have an opinion about it or >>> about language design, or for it to help you in knowing which avenues >>> not to pursue, since you can see how it's ended up: in a vastly complex >>> and cumbersome language near-impossible for an individual to implement. >>> >> >> It's true that you don't need much knowledge about a subject to have an >> opinion. You only need to know what you are talking about to have an >> /informed/ opinion - one worth listening to and discussing. > > You're right: someone who's only implemented PRINT in various languages > a few dozen times can't be expected to have an informed opinion about > how well cout or printf tackles the job. Implementing it doesn't give you anything here except an inflated view of your own opinion. /Using/ print systems in various languages is relevant. But if you don't even know what "cout" is or how "<<" works in C++, it is pointless to compare it to anything else. And since your experience of C++ appears mostly to be "What can I find to complain about today?", rather than trying to actually /use/ it, I don't see you as being in a position to judge. Any print system has its advantages and disadvantages. You should be able to understand that. Instead, you'd rather assume that because it is C++, it is necessarily all bad without any need for further thought or knowledge. I've nothing against opinions about things that people have tried and disliked, or found inferior in some ways - it's the knee-jerk blind prejudice that bugs me. (And in case you think I am biased in the other direction, you can read some of my opinions on C++ iostreams in other posts here.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-20 21:38 +0100 |
| Message-ID | <siarfn$ud5$1@dont-email.me> |
| In reply to | #81352 |
On 20/09/2021 20:35, David Brown wrote: > On 20/09/2021 20:04, Bart wrote: >> You're right: someone who's only implemented PRINT in various languages >> a few dozen times can't be expected to have an informed opinion about >> how well cout or printf tackles the job. > > Implementing it doesn't give you anything here except an inflated view > of your own opinion. /Using/ print systems in various languages is > relevant. Well, I've used print, of course, in 2-3 dozen languages I might have played with. But to talk with some knowledge about how Print might be better implemented in any language, you really need to have tried implementing Print within a language, and specifically implementing it as a built-in feature But if you don't even know what "cout" is or how "<<" works > in C++, it is pointless to compare it to anything else. It doesn't matter. I know what it is I'm trying to achieve: turn an expression into text and display it somewhere or send it somewhere. So I'm judging how conveniently the language allows me to do that simple task. I don't care what else cout might do for me in that context. Here, anyone can judge for themselves (although I doubt they'll be that open minded in a C++ group): 20 print i, sqr(i) std::cout << i << " " << sqrt(i) << std::endl; The first line is from decades-old BASIC. The second line, which also needs iostream and math.h includes, is from latest C++. > Any print system has its advantages and disadvantages. You should be > able to understand that. Instead, you'd rather assume that because it > is C++, it is necessarily all bad without any need for further thought > or knowledge. As I said above, people can make up their own minds. Personally I find the first type considerably easier to write, and to read. The only difficulty is having to go and find out how to suppress the automatic space between items, and the newline at the end.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-21 10:28 +1200 |
| Message-ID | <iqsg98Fcu03U1@mid.individual.net> |
| In reply to | #81354 |
On 21/09/2021 08:38, Bart wrote: > As I said above, people can make up their own minds. Personally I find > the first type considerably easier to write, and to read. The only > difficulty is having to go and find out how to suppress the automatic > space between items, and the newline at the end. You have hit the nail squarely on the head there. Simple prints are great so long as the designers defaults match your needs. Things get ugly fast once you need something different! A search for "python print no newline" is a good illustration :) -- Ian,
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2021-09-21 09:08 +0200 |
| Message-ID | <iqtemuFifk4U1@mid.individual.net> |
| In reply to | #81354 |
On 2021-09-20 at 22:38, Bart wrote: > So I'm judging how conveniently the language allows me to do that simple > task. I don't care what else cout might do for me in that context. > > Here, anyone can judge for themselves (although I doubt they'll be that > open minded in a C++ group): > > 20 print i, sqr(i) > > std::cout << i << " " << sqrt(i) << std::endl; > > The first line is from decades-old BASIC. The second line, which also > needs iostream and math.h includes, is from latest C++. > >> Any print system has its advantages and disadvantages. You should be >> able to understand that. Instead, you'd rather assume that because it >> is C++, it is necessarily all bad without any need for further thought >> or knowledge. > > As I said above, people can make up their own minds. Personally I find > the first type considerably easier to write, and to read. The only > difficulty is having to go and find out how to suppress the automatic > space between items, and the newline at the end. > Yes, the BASIC print works well for built in types, but how do you extend it to works with user defined types? Wait, in BASIC that is not a problem (you just don't allow user defined types :-). I have seen the same feature in Pascal, where READ and WRITE worked similarly well, for the built in types. I looked long and hard for the way to output one of my records - only to find that you could not. Still remember how disappointed I was - a nice language feature that only worked for some simple types, but not for the types I actually used in the program. See "useless".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-21 09:39 +0200 |
| Message-ID | <sic28b$m8a$1@dont-email.me> |
| In reply to | #81354 |
On 20/09/2021 22:38, Bart wrote: > On 20/09/2021 20:35, David Brown wrote: >> On 20/09/2021 20:04, Bart wrote: > >>> You're right: someone who's only implemented PRINT in various languages >>> a few dozen times can't be expected to have an informed opinion about >>> how well cout or printf tackles the job. >> >> Implementing it doesn't give you anything here except an inflated view >> of your own opinion. /Using/ print systems in various languages is >> relevant. > > Well, I've used print, of course, in 2-3 dozen languages I might have > played with. > > But to talk with some knowledge about how Print might be better > implemented in any language, you really need to have tried implementing > Print within a language, and specifically implementing it as a built-in > feature No one cares about how easy or hard it is to implement. Seriously. Rounded to the nearest 0.01% of programmers, /no one/ cares. The important thing is how people can /use/ the feature in the language, not how it is implemented! And how you want to /use/ your print features depends on the language and what you want to do with it. A BASIC-style print statement is fine for BASIC-style languages - typically designed to be quick and simple for easy tasks, but unsuitable for bigger work or more complex work, or programs that don't fit into the simple sequence of start program, read files and/or keyboard, print to screen and/or files, stop program. But for a language that supports multiple types, formatting, translations, redirected outputs, systems without a console, etc., then a simple print statement won't do. It is both too much, and too little. In fact, /no/ single solution will do everything. When you think you have "/the/ answer" to a coding or programming language problem, you are almost guaranteed to be wrong - and you, Bart, think you have all the answers. So a good, serious programming language does not provide a "print" statement. It does not even provide a "print" function as part of the language itself. It provides ways to make printing functionality. Then it can have one or more printing implementation as part of the standard library, for the convenience of users - while letting them make their own systems to suit more specialised needs, with their own balance of pros and cons. Thus C++ has printf that works reasonably for translations and formatting, but not for different types, and it has std::cout that works well for different types, but not for translations and formatting. And there is a new (C++20) formatting library that should work well for translations, formatting /and/ different types, but is sure to have other disadvantages (I haven't used it myself as yet). And in my own code I often use my own system because I have different needs from those of most C++ programmers. > > But if you don't even know what "cout" is or how "<<" works >> in C++, it is pointless to compare it to anything else. > > It doesn't matter. I know what it is I'm trying to achieve: turn an > expression into text and display it somewhere or send it somewhere. > > So I'm judging how conveniently the language allows me to do that simple > task. I don't care what else cout might do for me in that context. > > Here, anyone can judge for themselves (although I doubt they'll be that > open minded in a C++ group): > > 20 print i, sqr(i) > > std::cout << i << " " << sqrt(i) << std::endl; > > The first line is from decades-old BASIC. The second line, which also > needs iostream and math.h includes, is from latest C++. > The first version is easiest for a quick and dirty script. The second is better for more serious programming. (I am not mocking quick and dirty coding - that is suitable for a great deal of work, but it is certainly not suitable for everything.) Oh, and if your "sqr" is a language built-in function for square roots, then that demonstrates another reason why serious languages avoid built-in functions. The name is wrong, and changing the library is vastly easier than changing the language. >> Any print system has its advantages and disadvantages. You should be >> able to understand that. Instead, you'd rather assume that because it >> is C++, it is necessarily all bad without any need for further thought >> or knowledge. > > As I said above, people can make up their own minds. Personally I find > the first type considerably easier to write, and to read. The only > difficulty is having to go and find out how to suppress the automatic > space between items, and the newline at the end. > And there you have it. With your personal language and tools, if you want to change the way the spacing or formatting works, you change the language and the compiler/interpreter. With real languages, the programmer changes the code they write to change the formatting. Contrary to some experts' views, I have nothing against BASIC. I learned to program in BASIC, in several dialects - the "B" stands for "Beginners'". But then I grew up, and understood that while languages like BASIC can undoubtedly be good for a few hundred line programs, they are rarely a good choice for more serious work.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-21 11:12 +0100 |
| Message-ID | <sicb5v$gnl$1@dont-email.me> |
| In reply to | #81365 |
On 21/09/2021 08:39, David Brown wrote:
> On 20/09/2021 22:38, Bart wrote:
>> But to talk with some knowledge about how Print might be better
>> implemented in any language, you really need to have tried implementing
>> Print within a language, and specifically implementing it as a built-in
>> feature
>
> No one cares about how easy or hard it is to implement.
You're changing the goalposts. You said my opinion wasn't an informed
one, when I was talking about the deficiences of both cout and printf
approaches.
> A BASIC-style print statement is fine
> for BASIC-style languages - typically designed to be quick and simple
> for easy tasks, but unsuitable for bigger work or more complex work, or
> programs that don't fit into the simple sequence of start program, read
> files and/or keyboard, print to screen and/or files, stop program.
What can 'cout' or 'printf' do that an easier-to-use and better designed
Print can't do? This is an example bit of C++ posted a couple of days ago:
CMT:
std::cout << sizeof(__int64) << "\n";
std::cout << sizeof(__m128) << "\n";
std::cout << foo_64.is_lock_free() << "\n";
std::cout << foo_128.is_lock_free() << "\n";
I might be missing something, but is there any reason why something like:
println sizeof(__int64);
println sizeof(__m128);
println foo_64.is_lock_free();
println foo_128.is_lock_free();
wouldn't cut it? Too sensible? Too uncluttered? Might leave too many
people thinking, where's the catch? Because all that extra crap in C++
must do something important, right?
> But for a language that supports multiple types, formatting,
> translations, redirected outputs, systems without a console, etc., then
> a simple print statement won't do. It is both too much, and too little.
You're making this up aren't you?
Simple Print doesn't mean an inability to do anything. It means being
able to do most of it, but in a simpler manner with a lot less typing!
> In fact, /no/ single solution will do everything.
But it might do 90% of it.
> When you think you
> have "/the/ answer" to a coding or programming language problem, you are
> almost guaranteed to be wrong - and you, Bart, think you have all the
> answers.
Some things are just no-brainers.
> So a good, serious programming language does not provide a "print"
> statement.
Yeah. And the better ones also do away with mutability. And global
variables (see new 'pen' language). And loops. And of course goto.
>> Here, anyone can judge for themselves (although I doubt they'll be that
>> open minded in a C++ group):
>>
>> 20 print i, sqr(i)
>>
>> std::cout << i << " " << sqrt(i) << std::endl;
>>
>> The first line is from decades-old BASIC. The second line, which also
>> needs iostream and math.h includes, is from latest C++.
>>
>
> The first version is easist for a quick and dirty script.
Most of my uses of Print are quick and dirty:
* Because I add and remove such statements extensively for debugging, so
the total number of Prints written are much greater than than the number
of static Print statements in a finished program
* I also use it a lot for large numbers of throwaway programs, test
programs, code posted on forums, etc, in a variety of languages.
C's printf is poor in that regard, but I think C++'s cout might just pip
it. However Zig's print facilities I think are even worse; once you've
figured out how to do it once, you have to keep that example locked away
for future reference!
> The second
> is better for more serious programming.
So give me an example of serious programming where:
println X
is no good at all, and you're better off with:
std::cout << X << "\n";
> Oh, and if your "sqr" is a language built-in function for square roots,
> then that demonstrates another reason why serious languages avoid
> built-in functions. The name is wrong, and changing the library is
> vastly easier than changing the language.
SQR comes from BASIC (most languages use 'sqrt'). Many also have such
abilities built-in, because it's convenient.
In mine, sqrt is an operator. You don't need to include or import
anything; it's just there. And usually mapped to an x64 'sqrtsd'
instruction, but that's up to the backend.
Now look at the abs() function, and you realise why it is BETTER to have
such things properly built-in, and not just a bunch of templates. In C,
you have these variations:
abs(x) // these need stdlib.h
labs(x)
llabs(x)
fabs(x) // these need math.h
fabsf(x)
Maybe there's some more, I don't know. I just have 'abs', and it works
on any suitable type, because it's a unary operator like 'negate'.
> And there you have it.
>
> With your personal language and tools, if you want to change the way the
> spacing or formatting works, you change the language and the
> compiler/interpreter. With real languages, the programmer changes the
> code they write to change the formatting.
You say you like Python.
Python also injects implicit spaces and implicit new lines. But that's
OK, even though it is a PITA to figure out how to suppress them.
But C++, where it is a PITA to have to add explicit spaces and newlines,
is also fine.
The only place it isn't fine, apparently, is my language, where I have
implicit spaces and explicit newlines!
There /is/ a simple way to suppress spaces, but if you don't know what
it is, then instead of writing:
print "ABC","DEF" # ABC DEF
you have the option to just split the print into two:
print "ABC"; print "DEF" # ABCDEF
Because of how it works. In Python, you HAVE to go and look this up, as
splitting a print will just insert a newline instead of a space.
(Space suppression between my print items uses: ",," instead of ",".
When that gets too ugly, then you use formatted print.)
> Contrary to some experts' views, I have nothing against BASIC. I
> learned to program in BASIC, in several dialects - the "B" stands for
> "Beginners'". But then I grew up, and understood that while languages
> like BASIC can undoubtedly be good for a few hundred line programs, they
> are rarely a good choice for more serious work.
I want to port an algorithm which is expressed in both language A and
language B, into a new language.
Suppose A and B were C++ and BASIC; which do you think would be simplest
to work from?
The chances are that it will be BASIC, since most of its features exist
also in many other languages.
With C++, especially if written by Bonita Montero, it would likely mean
first implementing a dozen C++ libraries that it will depend on, and
disentangling a mess of arcane syntax.
You shouldn't really write off a language for language for being too simple.
It actuality, that simpler language, more likely to use mostly simple,
universal features, might be something like Lua or Python. Or even C,
provided the author hasn't gone mad with macros.
[toc] | [prev] | [next] | [standalone]
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
Back to top | Article view | comp.lang.c++
csiph-web