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 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-19 15:58 +0000 |
| Message-ID | <si7mm9$1qj9$1@gioia.aioe.org> |
| In reply to | #81327 |
Scott Lurndal <scott@slp53.sl.home> wrote: >>I blame certain Linux distros for this. > > I wouldn't use the verb "blame" here. Most programmers don't > particularly care about the version of the compiler, so long as > it works. Yeah, the problem with gcc 4 is that it doesn't support fully C++11 (if I remember correctly), much less newer versions.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-19 21:53 +0000 |
| Message-ID | <yjO1J.90180$rl3.30194@fx45.iad> |
| In reply to | #81328 |
Juha Nieminen <nospam@thanks.invalid> writes: >Scott Lurndal <scott@slp53.sl.home> wrote: >>>I blame certain Linux distros for this. >> >> I wouldn't use the verb "blame" here. Most programmers don't >> particularly care about the version of the compiler, so long as >> it works. > >Yeah, the problem with gcc 4 is that it doesn't support fully C++11 >(if I remember correctly), much less newer versions. That is correct. As the worldwide data centers migrate to newer RHEL releases, we're planning on GCC 7.3 as the baseline, which should open up _some_ limited C++11 feature use (e.g. static_assert would be useful to elimate some unnecessary runtime assertion checks).
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-18 09:34 +1200 |
| Message-ID | <iqkfv1Fb6apU3@mid.individual.net> |
| In reply to | #81293 |
On 18/09/2021 02:03, Scott Lurndal wrote:
> Juha Nieminen <nospam@thanks.invalid> writes:
>> alessandro volturno <alessandro.volturno@libero.it> wrote:
>>> printDescription() // prints a description of the number and its
>>> // numerical value
>>
>> This is not really something that belongs to a class that behaves like an
>> arithmetic numerical value.
>>
>> At most what you could have is a separate
>>
>> std::ostream& operator<<(std::ostream&, YourRationalClass);
>>
>> function for outputting the value to a std::ostream.
>
> I could rant for hours on the unsuitability of the silly
> C++ output stream crap in real applications.
>
> But I've got too much on my plate right now. Much of which
> is making performance improvements to a large CPU-bound
> C++ application; primarily by getting rid of all outputstringstream
> crap (replacing with snprintf) and eliminating most trivial
> run-time (vs. startup time) uses of std::string.
>
> void
> a(void)
> {
> std::string fred = "this is a test";
> printf("%s", fred.c_str());
> }
>
> 0000000000400970 <a()>:
> 400970: 53 push %rbx
> 400971: be 50 0b 40 00 mov $0x400b50,%esi
> 400976: 48 83 ec 20 sub $0x20,%rsp
> 40097a: 48 8d 7c 24 10 lea 0x10(%rsp),%rdi
> 40097f: 48 8d 54 24 0f lea 0xf(%rsp),%rdx
> 400984: e8 97 fe ff ff callq 400820 <std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)@plt>
> 400989: 48 8b 74 24 10 mov 0x10(%rsp),%rsi
> 40098e: bf 5f 0b 40 00 mov $0x400b5f,%edi
> 400993: 31 c0 xor %eax,%eax
> 400995: e8 36 fe ff ff callq 4007d0 <printf@plt>
> 40099a: 48 8b 44 24 10 mov 0x10(%rsp),%rax
> 40099f: 48 8d 78 e8 lea -0x18(%rax),%rdi
> 4009a3: 48 81 ff 80 10 60 00 cmp $0x601080,%rdi
> 4009aa: 75 06 jne 4009b2 <a()+0x42>
> 4009ac: 48 83 c4 20 add $0x20,%rsp
> 4009b0: 5b pop %rbx
> 4009b1: c3 retq
> 4009b2: b9 00 00 00 00 mov $0x0,%ecx
> 4009b7: 48 8d 57 10 lea 0x10(%rdi),%rdx
> 4009bb: 48 85 c9 test %rcx,%rcx
> 4009be: 74 35 je 4009f5 <a()+0x85>
> 4009c0: 83 c8 ff or $0xffffffff,%eax
> 4009c3: f0 0f c1 02 lock xadd %eax,(%rdx)
> 4009c7: 85 c0 test %eax,%eax
> 4009c9: 7f e1 jg 4009ac <a()+0x3c>
> 4009cb: 48 8d 74 24 0f lea 0xf(%rsp),%rsi
> 4009d0: e8 3b fe ff ff callq 400810 <std::string::_Rep::_M_destroy(std::allocator<char> const&)@plt>
> 4009d5: eb d5 jmp 4009ac <a()+0x3c>
> 4009d7: 48 89 c3 mov %rax,%rbx
> 4009da: 48 8b 44 24 10 mov 0x10(%rsp),%rax
> 4009df: 48 8d 74 24 0f lea 0xf(%rsp),%rsi
> 4009e4: 48 8d 78 e8 lea -0x18(%rax),%rdi
> 4009e8: e8 03 fe ff ff callq 4007f0 <std::string::_Rep::_M_dispose(std::allocator<char> const&)@plt>
> 4009ed: 48 89 df mov %rbx,%rdi
> 4009f0: e8 5b fe ff ff callq 400850 <_Unwind_Resume@plt>
> 4009f5: 8b 50 f8 mov -0x8(%rax),%edx
> 4009f8: 8d 4a ff lea -0x1(%rdx),%ecx
> 4009fb: 89 48 f8 mov %ecx,-0x8(%rax)
> 4009fe: 89 d0 mov %edx,%eax
> 400a00: eb c5 jmp 4009c7 <a()+0x57>
> 400a02: 66 66 66 66 66 2e 0f data32 data32 data32 data32 nopw %cs:0x0(%rax,%rax,1)
> 400a09: 1f 84 00 00 00 00 00
>
> (and that's _with_ -O3).
Maybe a better compiler would help? With clang++ and -O2:
_Z1av: # @_Z1av
.cfi_startproc
# %bb.0:
pushq %rbx
.cfi_def_cfa_offset 16
subq $32, %rsp
.cfi_def_cfa_offset 48
.cfi_offset %rbx, -16
leaq 16(%rsp), %rbx
movq %rbx, (%rsp)
movabsq $2338328219631577204, %rax # imm = 0x2073692073696874
movq %rax, 16(%rsp)
movabsq $8391162080155213939, %rax # imm = 0x7473657420612073
movq %rax, 22(%rsp)
movq $14, 8(%rsp)
movb $0, 30(%rsp)
movl $.L.str.1, %edi
movq %rbx, %rsi
xorl %eax, %eax
callq printf
movq (%rsp), %rdi
cmpq %rbx, %rdi
je .LBB0_2
# %bb.1:
callq _ZdlPv
.LBB0_2:
addq $32, %rsp
.cfi_def_cfa_offset 16
popq %rbx
.cfi_def_cfa_offset 8
retq
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-18 12:00 +0200 |
| Message-ID | <si4db4$9oc$1@dont-email.me> |
| In reply to | #81304 |
On 17/09/2021 23:34, Ian Collins wrote:
> On 18/09/2021 02:03, Scott Lurndal wrote:
>> Juha Nieminen <nospam@thanks.invalid> writes:
>>> alessandro volturno <alessandro.volturno@libero.it> wrote:
>>>> printDescription() // prints a description of the number and its
>>>> // numerical value
>>>
>>> This is not really something that belongs to a class that behaves
>>> like an
>>> arithmetic numerical value.
>>>
>>> At most what you could have is a separate
>>>
>>> std::ostream& operator<<(std::ostream&, YourRationalClass);
>>>
>>> function for outputting the value to a std::ostream.
>>
>> I could rant for hours on the unsuitability of the silly
>> C++ output stream crap in real applications.
>>
>> But I've got too much on my plate right now. Much of which
>> is making performance improvements to a large CPU-bound
>> C++ application; primarily by getting rid of all outputstringstream
>> crap (replacing with snprintf) and eliminating most trivial
>> run-time (vs. startup time) uses of std::string.
>>
>> void
>> a(void)
>> {
>> std::string fred = "this is a test";
>> printf("%s", fred.c_str());
>> }
>>
>> (and that's _with_ -O3).
>
> Maybe a better compiler would help? With clang++ and -O2:
>
Or pretty much any version of gcc with -O2, at least according to my
tests on <https://godbolt.org>
Maybe Scott has unusual options, or an unusual library, or other
surrounding code that affects the results.
There are plenty of reasons to dislike C++ output streams (for me, it is
the moronic design decision of stateful formatting flags that are the
big problem). The quality of code generated for a weird mixture of
C-style and C++-style, for an operation that is always big and slow, is
not such a concern.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-18 14:54 +0000 |
| Message-ID | <J4n1J.42459$3p3.40193@fx16.iad> |
| In reply to | #81308 |
David Brown <david.brown@hesbynett.no> writes: >On 17/09/2021 23:34, Ian Collins wrote: >> >> Maybe a better compiler would help? With clang++ and -O2: >> >Or pretty much any version of gcc with -O2, at least according to my >tests on <https://godbolt.org> > >Maybe Scott has unusual options, or an unusual library, or other >surrounding code that affects the results. $ gcc --version gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7) Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. It's what I had on the system I was posting from, and the code was an illustrative example, not from our proprietary production code. > >There are plenty of reasons to dislike C++ output streams (for me, it is >the moronic design decision of stateful formatting flags that are the >big problem). Indeed, and they're completely unreadable. > The quality of code generated for a weird mixture of >C-style and C++-style, for an operation that is always big and slow, is >not such a concern. snprintf makes a single pass over the formatting string. It's a single function call. output string streams (the "C++" way) has multiple function calls and generates a shitload of code. And is much less readable and not as maintainable. The arguments about mismatched format types is obviated by all modern compilers warning for the *printf family arguments. Custom classes can use 'to_string' functions rather than overloading the << operator. Performance _does_ matter in some applications - ours can eat a 24-core system for lunch, so every cycle matters; especially when the customer complains about performance (but then our application simulates a full SoC - sufficient to boot multicore linux and run packet processing application stacks (e.g DPDK) on the simulator prior to hardware availability).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-18 17:36 +0100 |
| Message-ID | <si54jt$5ql$1@dont-email.me> |
| In reply to | #81310 |
On 18/09/2021 15:54, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 17/09/2021 23:34, Ian Collins wrote:
>
>>>
>>> Maybe a better compiler would help? With clang++ and -O2:
>>>
>> Or pretty much any version of gcc with -O2, at least according to my
>> tests on <https://godbolt.org>
>>
>> Maybe Scott has unusual options, or an unusual library, or other
>> surrounding code that affects the results.
>
> $ gcc --version
> gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> It's what I had on the system I was posting from, and the code
> was an illustrative example, not from our proprietary production
> code.
>
>>
>> There are plenty of reasons to dislike C++ output streams (for me, it is
>> the moronic design decision of stateful formatting flags that are the
>> big problem).
>
> Indeed, and they're completely unreadable.
>
>> The quality of code generated for a weird mixture of
>> C-style and C++-style, for an operation that is always big and slow, is
>> not such a concern.
>
> snprintf makes a single pass over the formatting string. It's a single
> function call.
>
> output string streams (the "C++" way) has multiple function calls and
> generates a shitload of code. And is much less readable and
> not as maintainable. The arguments about mismatched format
> types is obviated by all modern compilers warning for the *printf
> family arguments.
Both approaches are terrible in my opinion:
C++: std::cout << "A=" << a << " B=" << b << " C=" << c << std::endl;
C: printf("A=%d B=%f C=%s\n", a, b, c);
Compared with the equivalent in any of my languages:
M: println =a, =b, =c
The C++ just looks dreadful (and I keep forgetting the << or writing
commas instead).
The C has the big problem of needing to tell the compiler the types of
the expressions you're printing, something it already knows perfectly
well, since it can warn you when they're wrong!
You might not even know yourself, with a complex expression, or one
involving opaque types. And they need maintenance as code changes.
My approach is to have print directly supported by the language. It can
map your code to a series of function calls or, at one time when I
transpiled to C, into a single synthesised printf call.
Or, possibly you can use a feature such as this in my C compiler:
C (bcc): printf("%=? %=? %=?\n", a, b, c);
where it fills in the format codes. Note the the C example above is ONLY
valid when a has an int type, b is double or float, and c is char*,
otherwise those need adjusting. If I reverse the order in my C version:
printf("%=? %=? %=?\n", c, b, a);
It still works fine. If I try the same in the standard C version,
without fixing the formats, it crashes. gcc might warn, /if/ you specify
-Wformat. And then you still need to fix it.
> Performance _does_ matter in some applications - ours can eat a
> 24-core system for lunch, so every cycle matters; especially when
> the customer complains about performance (but then our application
> simulates a full SoC - sufficient to boot multicore linux and run packet
> processing application stacks (e.g DPDK) on the simulator prior
> to hardware availability).
You don't want to make the emulation too good or people won't buy the
hardware...
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2021-09-18 23:29 +0200 |
| Message-ID | <si5loc$vcp$1@dont-email.me> |
| In reply to | #81311 |
Am 18.09.21 um 18:36 schrieb Bart:
> On 18/09/2021 15:54, Scott Lurndal wrote:
>> snprintf makes a single pass over the formatting string. It's a single
>> function call.
>>
>> output string streams (the "C++" way) has multiple function calls and
>> generates a shitload of code. And is much less readable and
>> not as maintainable. The arguments about mismatched format
>> types is obviated by all modern compilers warning for the *printf
>> family arguments.
>
> Both approaches are terrible in my opinion:
>
> C++: std::cout << "A=" << a << " B=" << b << " C=" << c << std::endl;
>
> C: printf("A=%d B=%f C=%s\n", a, b, c);
>
> Compared with the equivalent in any of my languages:
>
> M: println =a, =b, =c
>
> The C++ just looks dreadful (and I keep forgetting the << or writing
> commas instead).
There is widespread support for this in other languages; e.g. Python3:
Python 3.8.8 (default, Apr 13 2021, 12:59:45)
[Clang 10.0.0 ] :: Anaconda, Inc. on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a=3;b=4;c='Hallo'
>>> print(f'a={a} b={b} c={c}')
a=3 b=4 c=Hallo
>>>
Tcl:
(base) Apfelkiste:Sources chris$ wish86
% set a 3; set b 4; set c Hallo
Hallo
% puts "a=$a b=$b c=$c"
a=3 b=4 c=Hallo
%
> My approach is to have print directly supported by the language. It can
> map your code to a series of function calls or, at one time when I
> transpiled to C, into a single synthesised printf call.
In the other languages as demonstrated above, it is not a special
"print" function but rather a way to build strings; you can feed it to
any function or assign it to a variable, not just print it. And so it is
much more useful; consider e.g. constructing file names
>>> f'input_{a:03}.png'
'input_003.png'
>>>
...and, surprise:
Christian
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-19 01:09 +0100 |
| Message-ID | <si5v40$bs2$1@dont-email.me> |
| In reply to | #81312 |
On 18/09/2021 22:29, Christian Gollwitzer wrote:
> Am 18.09.21 um 18:36 schrieb Bart:
>> On 18/09/2021 15:54, Scott Lurndal wrote:
>>> snprintf makes a single pass over the formatting string. It's a single
>>> function call.
>>>
>>> output string streams (the "C++" way) has multiple function calls and
>>> generates a shitload of code. And is much less readable and
>>> not as maintainable. The arguments about mismatched format
>>> types is obviated by all modern compilers warning for the *printf
>>> family arguments.
>>
>> Both approaches are terrible in my opinion:
>>
>> C++: std::cout << "A=" << a << " B=" << b << " C=" << c << std::endl;
>>
>> C: printf("A=%d B=%f C=%s\n", a, b, c);
>>
>> Compared with the equivalent in any of my languages:
>>
>> M: println =a, =b, =c
>>
>> The C++ just looks dreadful (and I keep forgetting the << or writing
>> commas instead).
>
> There is widespread support for this in other languages; e.g. Python3:
>
> Python 3.8.8 (default, Apr 13 2021, 12:59:45)
> [Clang 10.0.0 ] :: Anaconda, Inc. on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> a=3;b=4;c='Hallo'
> >>> print(f'a={a} b={b} c={c}')
> a=3 b=4 c=Hallo
> >>>
>
> Tcl:
> (base) Apfelkiste:Sources chris$ wish86
> % set a 3; set b 4; set c Hallo
> Hallo
> % puts "a=$a b=$b c=$c"
> a=3 b=4 c=Hallo
> %
Simple Print is one of the most diverse features in program languages
(just take a look through Rosetta Code).
Scripting languages tend to do better, although most seem to want to do
it via functions in libraries, sometimes requiring special features of
the language (in C, it's variadic functions and parameters).
One of the best IMV was BASIC:
PRINT A, B, C ' 1960s and 70s
and I can do the same:
print A, B, C
Although the rules for spacing and newlines still differ widely. My
example will add spacing between the elements. In C++, you need to write:
std::cout << A << " " << B << " " << C;
where you gradually lose the will to live. I assume there is a formatted
Print feature other than C's printf.
(The "=" feature of mine adds a label; invaluable for debugging code,
but elsewhere you usually have to either repeat the expression as a
string, or knock up some C macro to avoid the duplication.)
>
>> My approach is to have print directly supported by the language. It
>> can map your code to a series of function calls or, at one time when I
>> transpiled to C, into a single synthesised printf call.
>
> In the other languages as demonstrated above, it is not a special
> "print" function but rather a way to build strings; you can feed it to
> any function or assign it to a variable, not just print it. And so it is
> much more useful; consider e.g. constructing file names
>
> >>> f'input_{a:03}.png'
> 'input_003.png'
> >>>
>
> ...and, surprise:
If you have string processing anyway, then there are many more
possibilities to getting formatted results. But sticking with formatted
Print, this becomes in my languages:
fprint "input_#.png", a:"z3" # statement-style
s := sfprint("input_#.png", a:"z3") # expression-style
I like the format string to be clean, and free of clutter, so that I can
more easily see what it's supposed to look like!
[toc] | [prev] | [next] | [standalone]
| From | red floyd <no.spam.here@its.invalid> |
|---|---|
| Date | 2021-09-18 23:45 -0700 |
| Message-ID | <si6m9h$qac$1@redfloyd.dont-email.me> |
| In reply to | #81316 |
On 9/18/2021 5:09 PM, Bart wrote: > Although the rules for spacing and newlines still differ widely. My > example will add spacing between the elements. In C++, you need to write: > > std::cout << A << " " << B << " " << C; > > where you gradually lose the will to live. I assume there is a formatted > Print feature other than C's printf. > boost::format? Or C++20 std::format?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-18 22:48 +0000 |
| Message-ID | <q1u1J.79028$g81.27187@fx33.iad> |
| In reply to | #81311 |
Bart <bc@freeuk.com> writes:
>On 18/09/2021 15:54, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 17/09/2021 23:34, Ian Collins wrote:
>> snprintf makes a single pass over the formatting string. It's a single
>> function call.
>C: printf("A=%d B=%f C=%s\n", a, b, c);
A trivially useless format string. Try adding field widths and
re-ordering the arguments within the format string for i18n/l10n
purposes.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-19 00:46 +0100 |
| Message-ID | <si5tp8$jli$1@dont-email.me> |
| In reply to | #81313 |
On 18/09/2021 23:48, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 18/09/2021 15:54, Scott Lurndal wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 17/09/2021 23:34, Ian Collins wrote:
>
>>> snprintf makes a single pass over the formatting string. It's a single
>>> function call.
>
>> C: printf("A=%d B=%f C=%s\n", a, b, c);
>
> A trivially useless format string. Try adding field widths and
> re-ordering the arguments within the format string for i18n/l10n
> purposes.
>
You're just picking holes, aren't you?
I don't see the problem with field widths. While internationalisation is
a separate aspect that is not a problem I've ever had in 99.999% of my
uses of printf.
But grappling with the correct format codes has ALWAYS been a problem,
and needs a solution, not nit-picking ideas because you're trying to put
someone down.
(I used a different approach to locale-specific printing decades ago, so
that I would write:
println /"Serial number:", sn
in my code, but at the customer site, it might output:
Serie nummer: 1234
if they spoke Dutch. "/" is a translation operator.)
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2021-09-19 08:06 +0200 |
| Message-ID | <si6k0h$l5k$1@dont-email.me> |
| In reply to | #81315 |
Am 19.09.21 um 01:46 schrieb Bart:
> On 18/09/2021 23:48, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 18/09/2021 15:54, Scott Lurndal wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> On 17/09/2021 23:34, Ian Collins wrote:
>>
>>>> snprintf makes a single pass over the formatting string. It's a single
>>>> function call.
>>
>>> C: printf("A=%d B=%f C=%s\n", a, b, c);
>>
>> A trivially useless format string. Try adding field widths and
>> re-ordering the arguments within the format string for i18n/l10n
>> purposes.
> that I would write:
>
> println /"Serial number:", sn
>
> in my code, but at the customer site, it might output:
>
> Serie nummer: 1234
>
> if they spoke Dutch. "/" is a translation operator.)
>
You didn't get the problem Scott was talking about. If you have more
than 1 variable in a sentence, in the translation the word order might
be changed. E.g.
"The $animal bites $name"
could be tranlsated as
"$name gets bitten by the $animal"
in some language.
Therefore, if you do
printf("The %s bites %s", "dog", "Harry")
and the translator does
"%s gets bitten by the %s"
you will end up with
"dog gets bitten by the Harry"
If, however, there is proper string interpolation like in Python format
strings, then the translator would translatate the string as above, changing
"The {animal} bites {name}"
into
"{name} gets bitten by the {animal}"
and it would come out correctly. Obviously, there are still problems
with inflections; in most languages the dog, Harry etc. are adapted
depending on the function in the sentence (grammatical cases).
Christian
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-19 10:26 +0100 |
| Message-ID | <si6vpd$dgs$1@dont-email.me> |
| In reply to | #81317 |
On 19/09/2021 07:06, Christian Gollwitzer wrote:
> Am 19.09.21 um 01:46 schrieb Bart:
>> On 18/09/2021 23:48, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 18/09/2021 15:54, Scott Lurndal wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> On 17/09/2021 23:34, Ian Collins wrote:
>>>
>>>>> snprintf makes a single pass over the formatting string. It's a
>>>>> single
>>>>> function call.
>>>
>>>> C: printf("A=%d B=%f C=%s\n", a, b, c);
>>>
>>> A trivially useless format string. Try adding field widths and
>>> re-ordering the arguments within the format string for i18n/l10n
>>> purposes.
>
>> that I would write:
>>
>> println /"Serial number:", sn
>>
>> in my code, but at the customer site, it might output:
>>
>> Serie nummer: 1234
>>
>> if they spoke Dutch. "/" is a translation operator.)
>>
>
> You didn't get the problem Scott was talking about. If you have more
> than 1 variable in a sentence, in the translation the word order might
> be changed. E.g.
>
>
> "The $animal bites $name"
>
> could be tranlsated as
>
> "$name gets bitten by the $animal"
>
> in some language.
>
> Therefore, if you do
>
> printf("The %s bites %s", "dog", "Harry")
>
> and the translator does
>
> "%s gets bitten by the %s"
>
> you will end up with
>
> "dog gets bitten by the Harry"
>
> If, however, there is proper string interpolation like in Python format
> strings, then the translator would translatate the string as above,
> changing
>
> "The {animal} bites {name}"
> into
> "{name} gets bitten by the {animal}"
>
> and it would come out correctly. Obviously, there are still problems
> with inflections; in most languages the dog, Harry etc. are adapted
> depending on the function in the sentence (grammatical cases).
But this is not what printf does? That has n$ positional codes, which is
not affected by my suggestion to use, for example, "?" instead of "d",
"f", "s" etc to denote the type of the result.
(And if a format string ends in a list outside the program, it's better
that "?" was in there, than "d" "lld" etc, which now become extra
program code to maintain.)
My point, again, was that this stuff is not the problem with Print in C
and C++ that I was addressing.
(Does C++ have keyword arguments yet? A vastly more useful feature in
everyday coding. If not, then implement those and then we'll talk about
positional print items, which can trivially be dealt with in user-code.)
>
> "The {animal} bites {name}"
> into
> "{name} gets bitten by the {animal}"
>
That seems a reasonable way of doing that, except that the second line
will be translated into the target language; you need to ensure that
'name' and 'animal', identifiers in the source code, are not translated too!
(I would still prefer that those names, which are really expressions,
were outside the string, with a positional scheme like printf's applied
if necessary.
Being expressions, they can presumably include embedded format strings too?)
Anyway, in many applications I've seen, people don't really bother
getting things right even in English: in Windows I often see "1 Files"
being shown (now improved to "1 File(s)"!), when the program /knows/ the
quantity and can easy display either "1 File" or "5 Files".
This is an example of my code from last century (here using string
processing not formatted print):
smcmd((nfiles=0|/"No Files"|(nfiles=1|"1 " + /"File"|str(nfiles) +
/"Files")))
It shows 'No files' or '1 File' or 'N Files'. In Dutch, it would show
'Geen bestanden' or '1 Bestand' or 'N Bestanden'. (I supported German
and French too.)
I can't remember the details, but if there were differences in word
order, then the whole phrase was translated when there were no variable
parts.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-19 10:23 +0000 |
| Message-ID | <si7327$103b$1@gioia.aioe.org> |
| In reply to | #81311 |
Bart <bc@freeuk.com> wrote:
> Both approaches are terrible in my opinion:
>
> C++: std::cout << "A=" << a << " B=" << b << " C=" << c << std::endl;
>
> C: printf("A=%d B=%f C=%s\n", a, b, c);
>
> Compared with the equivalent in any of my languages:
>
> M: println =a, =b, =c
Uh... println in your languages will automatically print "name=" before
printing the value of a variable? What if you want to use spaces around
the '='? What if you want to use another character instead, like ':',
and have a space only after that character but not before it?
Anyway, it's relatively easy in C++ to implement a function that behaves
like std::ostream, but uses a function call syntax instead, like:
myprint("a=", a, ", b=", b, ", c=", c, "\n");
> The C++ just looks dreadful (and I keep forgetting the << or writing
> commas instead).
It's C++'s fault that you keep forgetting the <<?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-19 12:04 +0100 |
| Message-ID | <si75fo$q7k$1@dont-email.me> |
| In reply to | #81324 |
On 19/09/2021 11:23, Juha Nieminen wrote:
> Bart <bc@freeuk.com> wrote:
>> Both approaches are terrible in my opinion:
>>
>> C++: std::cout << "A=" << a << " B=" << b << " C=" << c << std::endl;
>>
>> C: printf("A=%d B=%f C=%s\n", a, b, c);
>>
>> Compared with the equivalent in any of my languages:
>>
>> M: println =a, =b, =c
>
> Uh... println in your languages will automatically print "name=" before
> printing the value of a variable? What if you want to use spaces around
> the '='? What if you want to use another character instead, like ':',
> and have a space only after that character but not before it?
It prints the whole expression not just the name, and is primarily for
debugging prints where large numbers of such temporary statements will
be added and removed. With C, it would make my RSI worse.
C allows you to define a macro to reduce that duplication, example:
#define EQ(x) #x "=",x
where the expression is an exact copy of what's in the source (although
I prefer them in upper case for emphasis). But if I plug that into my C
example:
printf("%s%d %s%f %s%s\n", EQ(a), EQ(b), EQ(c));
you find you're doing even more typing!
Of course for permanent print statements and more precise control, you
add those annotations more conventionally.
> Anyway, it's relatively easy in C++ to implement a function that behaves
> like std::ostream, but uses a function call syntax instead, like:
>
> myprint("a=", a, ", b=", b, ", c=", c, "\n");
>
>> The C++ just looks dreadful (and I keep forgetting the << or writing
>> commas instead).
>
> It's C++'s fault that you keep forgetting the <<?
>
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.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-19 16:01 +0000 |
| Message-ID | <si7msk$1vdt$1@gioia.aioe.org> |
| In reply to | #81325 |
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";
I suppose there could be a contrived way of achieving the same thing
with a function call syntax, ie. that you could write
std::cout("Value = ", obj, "\n");
but I'm not sure how simple that could be made to be. Especially in C++98.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-19 17:39 +0100 |
| Message-ID | <si7p4n$sts$1@dont-email.me> |
| In reply to | #81329 |
On 19/09/2021 17:01, Juha Nieminen wrote:
> 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";
>
> I suppose there could be a contrived way of achieving the same thing
> with a function call syntax, ie. that you could write
>
> std::cout("Value = ", obj, "\n");
>
> but I'm not sure how simple that could be made to be. Especially in C++98.
>
That doesn't make sense to me, or maybe there are some limitations in
C++ so that it can only work that way.
I don't do overloads in my languages except for the 'tostr' operator
(normally unary, but see below) in my dynamic language.
'tostr' is applied automatically to each item in a statement like this:
println a, b, c
And it turns whatever a, b, c are into strings.
There is a default handler for the types known to the language, but a
user defined handler can be applied to a user type.
Example (the overloading syntax is crude, but it works):
record date=(var day,month,year)
function tostr_date(a,fmt)=
return sfprint("#/#/# CE", a.day, a.month, a.year)
end
d:=date(19,9,2021)
println d # default tostr shows '(19,9,2021)'
$setoverload(($tostr),date,tostr_date)
println d # custom tostr shows '19/9/2021 CE'
No binary overloads of some mysterious "<<" operator needed, although
'tostr' is really a binary operator; the second operand provides
optional format info, ignored in my example. If I write:
println d:"..."
then that "..." string appears as the fmt parameter, and it can be used
in any manner.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-20 05:25 +0000 |
| Message-ID | <si9611$1plr$1@gioia.aioe.org> |
| In reply to | #81332 |
Bart <bc@freeuk.com> wrote:
>> In other words, you can achieve this:
>>
>> MyClass obj;
>> std::cout << "Value = " << obj << "\n";
>>
>> I suppose there could be a contrived way of achieving the same thing
>> with a function call syntax, ie. that you could write
>>
>> std::cout("Value = ", obj, "\n");
>>
>> but I'm not sure how simple that could be made to be. Especially in C++98.
>
> That doesn't make sense to me, or maybe there are some limitations in
> C++ so that it can only work that way.
What doesn't make sense to you?
How exactly do you expect being able to have an existing standard library
function support your own custom type as a parameter?
> I don't do overloads in my languages except for the 'tostr' operator
> (normally unary, but see below) in my dynamic language.
>
> 'tostr' is applied automatically to each item in a statement like this:
>
> println a, b, c
>
> And it turns whatever a, b, c are into strings.
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.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-20 10:37 +0100 |
| Message-ID | <si9ko5$ngj$1@dont-email.me> |
| In reply to | #81340 |
On 20/09/2021 06:25, Juha Nieminen wrote:
> Bart <bc@freeuk.com> wrote:
>>> In other words, you can achieve this:
>>>
>>> MyClass obj;
>>> std::cout << "Value = " << obj << "\n";
>>>
>>> I suppose there could be a contrived way of achieving the same thing
>>> with a function call syntax, ie. that you could write
>>>
>>> std::cout("Value = ", obj, "\n");
>>>
>>> but I'm not sure how simple that could be made to be. Especially in C++98.
>>
>> That doesn't make sense to me, or maybe there are some limitations in
>> C++ so that it can only work that way.
>
> 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.
> How exactly do you expect being able to have an existing standard library
> function support your own custom type as a parameter?
>
>> I don't do overloads in my languages except for the 'tostr' operator
>> (normally unary, but see below) in my dynamic language.
>>
>> 'tostr' is applied automatically to each item in a statement like this:
>>
>> println a, b, c
>>
>> And it turns whatever a, b, c are into strings.
>
> 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.
Plus some formatting options will require that you know the full string,
or at least its width, before you can start outputting the first characters.
The point of being able to do:
print x
for any object x is for convenience. If that's likely to be a problem,
then user-code can choose a different approach.
If there is no formatting involved or it is simple (can be done as it
goes), then the output can be optimised: instead of of building a single
large string, it can directly send it to the destination if it knows
what it is (eg. to some file handle).
I haven't yet done such an optimisation in the print handler of my
dynamic language.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-22 04:58 +0000 |
| Message-ID | <sied5t$1ijg$1@gioia.aioe.org> |
| In reply to | #81345 |
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? >> 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.
[toc] | [prev] | [next] | [standalone]
Page 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
Back to top | Article view | comp.lang.c++
csiph-web