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 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-23 14:07 +0000 |
| Message-ID | <DS%2J.2841$fZ.127@fx06.iad> |
| In reply to | #81442 |
Juha Nieminen <nospam@thanks.invalid> writes: >Bart <bc@freeuk.com> wrote: >>> It seems to me that you come from a world of programming language design >>> that pays little to no attention to the efficiency of the resulting >>> program. >> >> Not at all. I used to write compilers and applications for 8-bit >> computers; I know how to be efficient! > >If that were the case, then you would abhor the idea of forcing every >custom type to have a "tostring" function which is the only way to >add support to the standard printing function for your type. > >> If you need to use sprintf() C, then that's when you might also consider >> using sprint() elsewhere. > >sprintf() cannot be extended to support your own custom types. Please. Competent C programmers eschew sprintf. It's dangerous and should be deprecated. snprintf is bounded and far safer than sprintf.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-23 14:50 +0000 |
| Message-ID | <Au03J.57295$jm6.7936@fx07.iad> |
| In reply to | #81463 |
On 2021-09-23, Scott Lurndal <scott@slp53.sl.home> wrote: > Juha Nieminen <nospam@thanks.invalid> writes: >>Bart <bc@freeuk.com> wrote: >>>> It seems to me that you come from a world of programming language design >>>> that pays little to no attention to the efficiency of the resulting >>>> program. >>> >>> Not at all. I used to write compilers and applications for 8-bit >>> computers; I know how to be efficient! >> >>If that were the case, then you would abhor the idea of forcing every >>custom type to have a "tostring" function which is the only way to >>add support to the standard printing function for your type. >> >>> If you need to use sprintf() C, then that's when you might also consider >>> using sprint() elsewhere. >> >>sprintf() cannot be extended to support your own custom types. > > Please. Competent C programmers eschew sprintf. It's dangerous and > should be deprecated. > > snprintf is bounded and far safer than sprintf. +1 you can use sprintf still, if you can predict size of input. -- 7-77-777 \|/ --- /|\ -- Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-20 05:20 +0000 |
| Message-ID | <si95nj$1n6v$1@gioia.aioe.org> |
| In reply to | #81334 |
Scott Lurndal <scott@slp53.sl.home> wrote: >>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 really know how exactly you expect that to be possible in all cases. The returned const char* has to point somewhere. To something that will outlive the to_string() function itself, but will, if necessary, be destroyed after use (because in many cases you will need to create a dynamically allocated string in order to contain the textual representation of the value of the object you are trying to print). You could have it like obj.to_string().c_str(), but that's not only awkward to write, the entire idea of having to dynamically allocate a string, populate it with the text you want to print (somehow) and then have it deleted is needlessly inefficient, when overloading operator<<() avoids doing all that. After all, you are probably thinking of very small objects with a very small textual representation, with a known maximum length. That's not always the case. Suppose your object contains a list of items, for example, and you want the output to be the textual representation of the entire list. Are you going to build up a std::string with this content and return it by value? Suppose the list is so large that the std::string takes megabytes of RAM. Is this supposed to be efficient and smart? Using an operator<<() overload you don't need to do any of that. You can just output every individual element to the std::ostream, one at a time, no matter how many of them there are, requiring no dynamic memory allocations, requiring pretty much no extra memory.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-24 21:45 +1200 |
| Message-ID | <ir5l2mFj3ljU4@mid.individual.net> |
| In reply to | #81339 |
On 20/09/2021 17:20, Juha Nieminen wrote: > Scott Lurndal <scott@slp53.sl.home> wrote: >>> 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 really know how exactly you expect that to be possible in all cases. > The returned const char* has to point somewhere. To something that will > outlive the to_string() function itself, but will, if necessary, be destroyed > after use (because in many cases you will need to create a dynamically > allocated string in order to contain the textual representation of the value > of the object you are trying to print). The whole to_string() concept also falls apart if you are printing in a template. int.to_string() anyone? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-25 16:15 +0300 |
| Message-ID | <sin7d5$ck8$1@dont-email.me> |
| In reply to | #81508 |
24.09.2021 12:45 Ian Collins kirjutas:
> On 20/09/2021 17:20, Juha Nieminen wrote:
>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> 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 really know how exactly you expect that to be possible in all
>> cases.
>> The returned const char* has to point somewhere. To something that will
>> outlive the to_string() function itself, but will, if necessary, be
>> destroyed
>> after use (because in many cases you will need to create a dynamically
>> allocated string in order to contain the textual representation of the
>> value
>> of the object you are trying to print).
>
> The whole to_string() concept also falls apart if you are printing in a
> template. int.to_string() anyone?
Adding a stream adaptor for a class having only a to_string() is trivial:
std::ostream& operator<<(std::ostream& os, const A& a) {
os << a.to_string();
return os;
}
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-27 05:36 +0000 |
| Message-ID | <sirl9b$5e8$2@gioia.aioe.org> |
| In reply to | #81556 |
Paavo Helde <myfirstname@osa.pri.ee> wrote:
> Adding a stream adaptor for a class having only a to_string() is trivial:
>
> std::ostream& operator<<(std::ostream& os, const A& a) {
> os << a.to_string();
> return os;
> }
While you are at it, why not just output the contents of that A object
directly, rather than making it construct a string?
At this point that to_string() method is completely superfluous.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-27 11:19 +0300 |
| Message-ID | <sirur8$vdo$1@dont-email.me> |
| In reply to | #81609 |
27.09.2021 08:36 Juha Nieminen kirjutas:
> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> Adding a stream adaptor for a class having only a to_string() is trivial:
>>
>> std::ostream& operator<<(std::ostream& os, const A& a) {
>> os << a.to_string();
>> return os;
>> }
>
> While you are at it, why not just output the contents of that A object
> directly, rather than making it construct a string?
Because of speed. I just showed elsethread that serializing a large
object into an in-memory string can be up to 10x faster than writing it
into a std::ostream piece-by-piece.
Also, because of better modularity and easier usage. A string is
basically just a raw memory buffer which is easy to transport and use.
Streams are more complicated.
Say, I want to write my large data structure into a file in AWS cloud.
AmazonStreamingWebServiceRequest::SetBody() takes a pointer to an input
stream and reads data from it later when I call S3Object::PutObject().
Say, for my large data structure I have proper streaming support which
writes the data into an std::ostream. So now what? How do I connect this
output stream to an input stream used by the AWS library so that they
would "flow together"? Sure it can be done, but seems not so easy.
Threads or coroutines come to mind.
The easiest way is to dump the data into a temporary file, then let the
AWS library to read it. We do not need a file on disk, so this ought to
be an in-memory file. And guess what is the fastest way to create an
in-memory file? Answer: serializing the data into a raw memory buffer
such as std::string. IOW the dreaded to_string() method.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-27 21:27 +1300 |
| Message-ID | <irdditFr86hU1@mid.individual.net> |
| In reply to | #81617 |
On 27/09/2021 21:19, Paavo Helde wrote:
> 27.09.2021 08:36 Juha Nieminen kirjutas:
>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>> Adding a stream adaptor for a class having only a to_string() is trivial:
>>>
>>> std::ostream& operator<<(std::ostream& os, const A& a) {
>>> os << a.to_string();
>>> return os;
>>> }
>>
>> While you are at it, why not just output the contents of that A object
>> directly, rather than making it construct a string?
>
>
> Because of speed. I just showed elsethread that serializing a large
> object into an in-memory string can be up to 10x faster than writing it
> into a std::ostream piece-by-piece.
>
> Also, because of better modularity and easier usage. A string is
> basically just a raw memory buffer which is easy to transport and use.
> Streams are more complicated.
>
> Say, I want to write my large data structure into a file in AWS cloud.
> AmazonStreamingWebServiceRequest::SetBody() takes a pointer to an input
> stream and reads data from it later when I call S3Object::PutObject().
>
> Say, for my large data structure I have proper streaming support which
> writes the data into an std::ostream. So now what? How do I connect this
> output stream to an input stream used by the AWS library so that they
> would "flow together"? Sure it can be done, but seems not so easy.
> Threads or coroutines come to mind.
>
> The easiest way is to dump the data into a temporary file, then let the
> AWS library to read it. We do not need a file on disk, so this ought to
> be an in-memory file. And guess what is the fastest way to create an
> in-memory file? Answer: serializing the data into a raw memory buffer
> such as std::string. IOW the dreaded to_string() method.
You can string it into an in memory straeam buffer.
I can't see how adding to a string can be any faster and you have to
convert each field to a string representation which is what streams do
for you.
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-27 15:49 +0300 |
| Message-ID | <sisel2$lvf$1@dont-email.me> |
| In reply to | #81618 |
27.09.2021 11:27 Ian Collins kirjutas:
> On 27/09/2021 21:19, Paavo Helde wrote:
>> 27.09.2021 08:36 Juha Nieminen kirjutas:
>>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>>> Adding a stream adaptor for a class having only a to_string() is
>>>> trivial:
>>>>
>>>> std::ostream& operator<<(std::ostream& os, const A& a) {
>>>> os << a.to_string();
>>>> return os;
>>>> }
>>>
>>> While you are at it, why not just output the contents of that A object
>>> directly, rather than making it construct a string?
>>
>>
>> Because of speed. I just showed elsethread that serializing a large
>> object into an in-memory string can be up to 10x faster than writing it
>> into a std::ostream piece-by-piece.
>>
>> Also, because of better modularity and easier usage. A string is
>> basically just a raw memory buffer which is easy to transport and use.
>> Streams are more complicated.
>>
>> Say, I want to write my large data structure into a file in AWS cloud.
>> AmazonStreamingWebServiceRequest::SetBody() takes a pointer to an input
>> stream and reads data from it later when I call S3Object::PutObject().
>>
>> Say, for my large data structure I have proper streaming support which
>> writes the data into an std::ostream. So now what? How do I connect this
>> output stream to an input stream used by the AWS library so that they
>> would "flow together"? Sure it can be done, but seems not so easy.
>> Threads or coroutines come to mind.
>>
>> The easiest way is to dump the data into a temporary file, then let the
>> AWS library to read it. We do not need a file on disk, so this ought to
>> be an in-memory file. And guess what is the fastest way to create an
>> in-memory file? Answer: serializing the data into a raw memory buffer
>> such as std::string. IOW the dreaded to_string() method.
>
> You can string it into an in memory straeam buffer.
This is the slow part.
> I can't see how adding to a string can be any faster
See my demo programs and timings elsethread.
and you have to
> convert each field to a string representation which is what streams do
> for you.
Yes, and that's the slow part. When adding to a string I can choose what
conversion function to use. There is a reason why std::to_chars() was
added to C++.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-28 04:53 +0000 |
| Message-ID | <siu746$1sdm$1@gioia.aioe.org> |
| In reply to | #81617 |
Paavo Helde <myfirstname@osa.pri.ee> wrote:
> 27.09.2021 08:36 Juha Nieminen kirjutas:
>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>> Adding a stream adaptor for a class having only a to_string() is trivial:
>>>
>>> std::ostream& operator<<(std::ostream& os, const A& a) {
>>> os << a.to_string();
>>> return os;
>>> }
>>
>> While you are at it, why not just output the contents of that A object
>> directly, rather than making it construct a string?
>
> Because of speed. I just showed elsethread that serializing a large
> object into an in-memory string can be up to 10x faster than writing it
> into a std::ostream piece-by-piece.
Suppose that the 'a' object above consists of 2 large strings, and you
want to write them to 'os' concatenated.
Are you seriously telling me that it's more efficient to first create a
new dynamically allocated string, write the two strings from 'a' there,
write that string to 'os' and then destroy that temporary string, than
it would be to just write the two strings directly to 'os' one after
another?
If that were the case, then it logically follows that if you do that again
with the resulting concatenated temporary string, by creating a second
temporary string with it, it would be even faster! And if you do it a
third time, it would be even faster still!
It seems extraordinarily silly to have the std::ostream object right
there to be used, and *still* construct a useless temporary string just
to write it there.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-28 10:16 +0100 |
| Message-ID | <siumgm$q2c$1@dont-email.me> |
| In reply to | #81634 |
On 28/09/2021 05:53, Juha Nieminen wrote:
> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> 27.09.2021 08:36 Juha Nieminen kirjutas:
>>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>>> Adding a stream adaptor for a class having only a to_string() is trivial:
>>>>
>>>> std::ostream& operator<<(std::ostream& os, const A& a) {
>>>> os << a.to_string();
>>>> return os;
>>>> }
>>>
>>> While you are at it, why not just output the contents of that A object
>>> directly, rather than making it construct a string?
>>
>> Because of speed. I just showed elsethread that serializing a large
>> object into an in-memory string can be up to 10x faster than writing it
>> into a std::ostream piece-by-piece.
>
> Suppose that the 'a' object above consists of 2 large strings, and you
> want to write them to 'os' concatenated.
>
> Are you seriously telling me that it's more efficient to first create a
> new dynamically allocated string, write the two strings from 'a' there,
> write that string to 'os' and then destroy that temporary string, than
> it would be to just write the two strings directly to 'os' one after
> another?
Bizarrely, yes it could be faster!
Because, for most objects that are not already strings, assembling into
a local temporary string, then dumping the whole string at once, might
be faster than calling some external character-at-a-time routine.
So even if your specific example of large strings is slower, overall
with a mix of objects, there might be a net benefit.
If the strings are large enough that having duplicates will impact on
memory resources, then that might be a consideration. But it might never
happen.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-29 12:10 +0000 |
| Message-ID | <sj1l42$1im4$1@gioia.aioe.org> |
| In reply to | #81648 |
Bart <bc@freeuk.com> wrote: >> Are you seriously telling me that it's more efficient to first create a >> new dynamically allocated string, write the two strings from 'a' there, >> write that string to 'os' and then destroy that temporary string, than >> it would be to just write the two strings directly to 'os' one after >> another? > > Bizarrely, yes it could be faster! > > Because, for most objects that are not already strings, assembling into > a local temporary string, then dumping the whole string at once, might > be faster than calling some external character-at-a-time routine. I did not ask whether outputting one concatenated string is faster than outputting two strings one character at a time. I asked if concatenating the two strings and then outputting the result is faster than just outputting the two strings.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-29 14:34 +0100 |
| Message-ID | <sj1q1j$9cb$1@dont-email.me> |
| In reply to | #81674 |
On 29/09/2021 13:10, Juha Nieminen wrote: > Bart <bc@freeuk.com> wrote: >>> Are you seriously telling me that it's more efficient to first create a >>> new dynamically allocated string, write the two strings from 'a' there, >>> write that string to 'os' and then destroy that temporary string, than >>> it would be to just write the two strings directly to 'os' one after >>> another? >> >> Bizarrely, yes it could be faster! >> >> Because, for most objects that are not already strings, assembling into >> a local temporary string, then dumping the whole string at once, might >> be faster than calling some external character-at-a-time routine. > > I did not ask whether outputting one concatenated string is faster than > outputting two strings one character at a time. > > I asked if concatenating the two strings and then outputting the result > is faster than just outputting the two strings. I was talking about the net effect when outputting lots of different objects, since the gains can offset the losses. But, OK, the answer to your specific question: I guess it depends. On the overheads of calling the o/p routine, and the efficiency of string concatenation.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-29 15:54 +0100 |
| Message-ID | <sj1umm$euu$1@dont-email.me> |
| In reply to | #81676 |
On 29/09/2021 14:34, Bart wrote:
> On 29/09/2021 13:10, Juha Nieminen wrote:
>> Bart <bc@freeuk.com> wrote:
>>>> Are you seriously telling me that it's more efficient to first create a
>>>> new dynamically allocated string, write the two strings from 'a' there,
>>>> write that string to 'os' and then destroy that temporary string, than
>>>> it would be to just write the two strings directly to 'os' one after
>>>> another?
>>>
>>> Bizarrely, yes it could be faster!
>>>
>>> Because, for most objects that are not already strings, assembling into
>>> a local temporary string, then dumping the whole string at once, might
>>> be faster than calling some external character-at-a-time routine.
>>
>> I did not ask whether outputting one concatenated string is faster than
>> outputting two strings one character at a time.
>>
>> I asked if concatenating the two strings and then outputting the result
>> is faster than just outputting the two strings.
>
> I was talking about the net effect when outputting lots of different
> objects, since the gains can offset the losses.
>
> But, OK, the answer to your specific question: I guess it depends. On
> the overheads of calling the o/p routine, and the efficiency of string
> concatenation.
Here's a random observation using script code. A and B are both
100-character strings:
to 1 million do
println A,,B
od
The above prints 1M lines of A and B (the ",," means no gap), so outputs
2M strings of 100 chars each.
The following combines A+B into one string each time, and writes 1M
strings of 200 chars each:
to 1 million do
println A + B
od
The first took around 4.5 seconds, the second about 4.3 seconds. (Run on
Windows and directing output to a file.)
If I instead printed 10,000 strings of 10,000 chars each, the results
were much closer (approx 3.5 second for both).
I didn't observe a slow-down due to having to 'pointlessly' create a
temporary string object and then tear it down again.
So in answer to this:
>> I asked if concatenating the two strings and then outputting the result
>> is faster than just outputting the two strings.
Yes, it can be. At least, you shouldn't just dismiss the possibility.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-28 13:23 +0300 |
| Message-ID | <siuqfa$n1o$1@dont-email.me> |
| In reply to | #81634 |
28.09.2021 07:53 Juha Nieminen kirjutas:
> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> 27.09.2021 08:36 Juha Nieminen kirjutas:
>>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>>> Adding a stream adaptor for a class having only a to_string() is trivial:
>>>>
>>>> std::ostream& operator<<(std::ostream& os, const A& a) {
>>>> os << a.to_string();
>>>> return os;
>>>> }
>>>
>>> While you are at it, why not just output the contents of that A object
>>> directly, rather than making it construct a string?
>>
>> Because of speed. I just showed elsethread that serializing a large
>> object into an in-memory string can be up to 10x faster than writing it
>> into a std::ostream piece-by-piece.
>
> Suppose that the 'a' object above consists of 2 large strings, and you
> want to write them to 'os' concatenated.
This is another task. If you already have data formatted into strings,
then of course these can be written directly to a file. But for that you
don't need a C++ std::ostream interface, you can write directly into the
file descriptor, or C++ streambuf(). If there are only a handful of
strings, then you can of course write them to the stream as well, the
overhead is insignificant.
What I'm talking is about outstreaming millions of small items
one-by-one, like advocated by ostream<< enthusiasts: just define a
proper operator<< overload and write everything in the ostream,
recursively, each number separately.
It's this formatting interface of C++ iostreams which is slow. With
MSVC++ I just stepped though an operator<<(std::ofstream&, int), this
involved at least 2 virtual function calls, 4 locking/unlocking of
current locale, and consulting TLS about the number of uncaught
exceptions, not to speak about tens of non-virtual function calls (which
hopefully get optimized away) and twiddling with the stream state. This
is all 100% unnecessary overhead for formatting an int in C locale. It
won't matter for a single debug printout line, but it will matter when
exporting a 100,000 line table into a CSV file.
> Are you seriously telling me that it's more efficient to first create a
> new dynamically allocated string, write the two strings from 'a' there,
> write that string to 'os' and then destroy that temporary string, than
> it would be to just write the two strings directly to 'os' one after
> another?
No, of course not.
[Rest of strawman arguments snipped]
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-29 10:34 +1300 |
| Message-ID | <irhg2bFr86hU2@mid.individual.net> |
| In reply to | #81651 |
On 28/09/2021 23:23, Paavo Helde wrote:
> 28.09.2021 07:53 Juha Nieminen kirjutas:
>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>> 27.09.2021 08:36 Juha Nieminen kirjutas:
>>>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>>>> Adding a stream adaptor for a class having only a to_string() is trivial:
>>>>>
>>>>> std::ostream& operator<<(std::ostream& os, const A& a) {
>>>>> os << a.to_string();
>>>>> return os;
>>>>> }
>>>>
>>>> While you are at it, why not just output the contents of that A object
>>>> directly, rather than making it construct a string?
>>>
>>> Because of speed. I just showed elsethread that serializing a large
>>> object into an in-memory string can be up to 10x faster than writing it
>>> into a std::ostream piece-by-piece.
>>
>> Suppose that the 'a' object above consists of 2 large strings, and you
>> want to write them to 'os' concatenated.
>
> This is another task. If you already have data formatted into strings,
> then of course these can be written directly to a file. But for that you
> don't need a C++ std::ostream interface, you can write directly into the
> file descriptor, or C++ streambuf(). If there are only a handful of
> strings, then you can of course write them to the stream as well, the
> overhead is insignificant.
>
> What I'm talking is about outstreaming millions of small items
> one-by-one, like advocated by ostream<< enthusiasts: just define a
> proper operator<< overload and write everything in the ostream,
> recursively, each number separately.
>
> It's this formatting interface of C++ iostreams which is slow. With
> MSVC++ I just stepped though an operator<<(std::ofstream&, int), this
> involved at least 2 virtual function calls, 4 locking/unlocking of
> current locale, and consulting TLS about the number of uncaught
> exceptions, not to speak about tens of non-virtual function calls (which
> hopefully get optimized away) and twiddling with the stream state. This
> is all 100% unnecessary overhead for formatting an int in C locale. It
> won't matter for a single debug printout line, but it will matter when
> exporting a 100,000 line table into a CSV file.
Ah, right so it's the overhead of locale based formatting that's the
real problem here. Presumably this would be the same for C printing
functions as well. I can see why std::to_chars would have an advantage
here.
I haven't seen such an high overhead on Unix/Linux, I wonder of the
Windows way of doing things is more burdensome? An example wit timings
would be useful!
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-29 12:18 +0300 |
| Message-ID | <sj1b0i$lm1$1@dont-email.me> |
| In reply to | #81656 |
29.09.2021 00:34 Ian Collins kirjutas:
> On 28/09/2021 23:23, Paavo Helde wrote:
>> It's this formatting interface of C++ iostreams which is slow. With
>> MSVC++ I just stepped though an operator<<(std::ofstream&, int), this
>> involved at least 2 virtual function calls, 4 locking/unlocking of
>> current locale, and consulting TLS about the number of uncaught
>> exceptions, not to speak about tens of non-virtual function calls (which
>> hopefully get optimized away) and twiddling with the stream state. This
>> is all 100% unnecessary overhead for formatting an int in C locale. It
>> won't matter for a single debug printout line, but it will matter when
>> exporting a 100,000 line table into a CSV file.
>
> Ah, right so it's the overhead of locale based formatting that's the
> real problem here. Presumably this would be the same for C printing
> functions as well. I can see why std::to_chars would have an advantage
> here.
Right. Actually it is not so important where the output is collected,
it's the formatting step what is the bottleneck. It is even possible to
use the standard stream for collecting the output, for those who repel
the idea of a string buffer. The trick is to ignore the stream part and
only use the streambuf part, see the test program below.
> I haven't seen such an high overhead on Unix/Linux, I wonder of the
> Windows way of doing things is more burdensome? An example wit timings
> would be useful!
Here you are. These timings are for 50 million ints. You can try the
demo program out by yourself with your favorite compiler and hardware.
On my Windows the "traditional" streaming is ca 10 times slower than
alternatives, on my Linux the difference is smaller, just ca 2 times.
MSVC++ 2019 on Windows, x64 Release build:
Traditional streaming: 16479 ms
Streaming with std::to_chars() directly into streambuf: 1612 ms
Collecting the content in a string buffer of 418 MB: 1126 ms
Writing the string buffer of 418 MB into a disk file: 796 ms
g++ 8.3 on Linux:
$ g++ -Wall -O3 -std=c++17 test6.cpp
$ ./a.out
Traditional streaming: 2080 ms
Streaming with std::to_chars() directly into streambuf: 903 ms
Collecting the content in a string buffer of 418 MB: 655 ms
Writing the string buffer of 418 MB into a disk file: 146 ms
Source code:
#include <iostream>
#include <string>
#include <vector>
#include <numeric>
#include <charconv>
#include <chrono>
#include <cstdint>
#include <fstream>
class A {
public:
A();
// traditional operator<<
friend std::ostream& operator<<(std::ostream& os, const A& a);
// tostring() operator
std::string to_string() const;
// Select whether operator<< uses stream or streambuf interface.
bool useStreamBufOnly = false;
private:
std::vector<int> data;
};
A::A() {
// Initialize data to 50 million ints.
data.resize(50000000);
std::iota(data.begin(), data.end(), 0);
}
std::ostream& operator<<(std::ostream& os, const A& a) {
if (a.useStreamBufOnly) {
// Ignore stream, use streambuf only.
auto streamBuf = os.rdbuf();
const size_t k = 64;
char buff[k];
for (auto& x: a.data) {
auto q = std::to_chars(buff, buff+k, x).ptr;
*q++ = ' ';
streamBuf->sputn(buff, q-buff);
}
} else {
// Traditional stream output
for (auto& x: a.data) {
os << x << ' ';
}
}
return os;
}
std::string A::to_string() const {
const size_t k = 64;
char buffer[k];
std::string result;
for (auto x: data) {
auto q = std::to_chars(buffer, buffer+k, x).ptr;
*q++ = ' ';
result.append(buffer, q-buffer);
}
return result;
}
using sclock = std::chrono::steady_clock;
std::int64_t ms(sclock::duration lapse) {
return
std::chrono::duration_cast<std::chrono::milliseconds>(lapse).count();
}
int main() {
A a;
std::ofstream sink1("sink1.txt"), sink2("sink2.txt"),
sink3("sink3.txt");
// traditional streaming
a.useStreamBufOnly = false;
sclock::time_point start1 = sclock::now();
sink1 << a;
sink1.close();
sclock::time_point finish1 = sclock::now();
std::cout << "Traditional streaming: " << ms(finish1-start1) << "
ms\n";
// streaming with to_chars() and streambuf
a.useStreamBufOnly = true;
sclock::time_point start2 = sclock::now();
sink2 << a;
sink2.close();
sclock::time_point finish2 = sclock::now();
std::cout << "Streaming with std::to_chars() directly into
streambuf: " << ms(finish2-start2) << " ms\n";
// to_string()
sclock::time_point start3 = sclock::now();
std::string s3 = a.to_string();
sclock::time_point finish3 = sclock::now();
std::cout << "Collecting the content in a string buffer of " <<
s3.length()/(1024*1024) << " MB: " << ms(finish3-start3) << " ms\n";
sclock::time_point start4 = sclock::now();
sink3.rdbuf()->sputn(s3.data(), s3.length());
sink3.close();
sclock::time_point finish4 = sclock::now();
std::cout << "Writing the string buffer of " <<
s3.length()/(1024*1024) << " MB into a disk file: " <<
ms(finish4-start4) << " ms\n";
}
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-29 22:46 +1300 |
| Message-ID | <iriqv9FfrldU1@mid.individual.net> |
| In reply to | #81669 |
On 29/09/2021 22:18, Paavo Helde wrote: > 29.09.2021 00:34 Ian Collins kirjutas: >> On 28/09/2021 23:23, Paavo Helde wrote: >>> It's this formatting interface of C++ iostreams which is slow. With >>> MSVC++ I just stepped though an operator<<(std::ofstream&, int), this >>> involved at least 2 virtual function calls, 4 locking/unlocking of >>> current locale, and consulting TLS about the number of uncaught >>> exceptions, not to speak about tens of non-virtual function calls (which >>> hopefully get optimized away) and twiddling with the stream state. This >>> is all 100% unnecessary overhead for formatting an int in C locale. It >>> won't matter for a single debug printout line, but it will matter when >>> exporting a 100,000 line table into a CSV file. >> >> Ah, right so it's the overhead of locale based formatting that's the >> real problem here. Presumably this would be the same for C printing >> functions as well. I can see why std::to_chars would have an advantage >> here. > > Right. Actually it is not so important where the output is collected, > it's the formatting step what is the bottleneck. It is even possible to > use the standard stream for collecting the output, for those who repel > the idea of a string buffer. The trick is to ignore the stream part and > only use the streambuf part, see the test program below. > >> I haven't seen such an high overhead on Unix/Linux, I wonder of the >> Windows way of doing things is more burdensome? An example wit timings >> would be useful! > > Here you are. These timings are for 50 million ints. You can try the > demo program out by yourself with your favorite compiler and hardware. > On my Windows the "traditional" streaming is ca 10 times slower than > alternatives, on my Linux the difference is smaller, just ca 2 times. > > MSVC++ 2019 on Windows, x64 Release build: > > Traditional streaming: 16479 ms > Streaming with std::to_chars() directly into streambuf: 1612 ms > Collecting the content in a string buffer of 418 MB: 1126 ms > Writing the string buffer of 418 MB into a disk file: 796 ms > > > g++ 8.3 on Linux: > $ g++ -Wall -O3 -std=c++17 test6.cpp > $ ./a.out > Traditional streaming: 2080 ms > Streaming with std::to_chars() directly into streambuf: 903 ms > Collecting the content in a string buffer of 418 MB: 655 ms > Writing the string buffer of 418 MB into a disk file: 146 ms Interesting, thanks for posting. It's a similar ratio on my machine. I can see that the Windows way of doing things is definitely more burdensome. It also gives me another argument for upgrading our embedded target compiler to one which supports C++17! <snip> -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-29 13:07 +0300 |
| Message-ID | <sj1ds5$aki$1@dont-email.me> |
| In reply to | #81670 |
29.09.2021 12:46 Ian Collins kirjutas: > > It also gives me another argument for upgrading our embedded target > compiler to one which supports C++17! Beware that some g++ versions do not support std::to_chars() with floating-point, even when otherwise supporting C++17.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-10-02 22:57 +0300 |
| Message-ID | <sjadjv$vqn$1@dont-email.me> |
| In reply to | #81670 |
29.09.2021 12:46 Ian Collins kirjutas:
> On 29/09/2021 22:18, Paavo Helde wrote:
>> Here you are. These timings are for 50 million ints. You can try the
>> demo program out by yourself with your favorite compiler and hardware.
>> On my Windows the "traditional" streaming is ca 10 times slower than
>> alternatives, on my Linux the difference is smaller, just ca 2 times.
>>
>> MSVC++ 2019 on Windows, x64 Release build:
>>
>> Traditional streaming: 16479 ms
>> Streaming with std::to_chars() directly into streambuf: 1612 ms
>> Collecting the content in a string buffer of 418 MB: 1126 ms
>> Writing the string buffer of 418 MB into a disk file: 796 ms
>>
>>
>> g++ 8.3 on Linux:
>> $ g++ -Wall -O3 -std=c++17 test6.cpp
>> $ ./a.out
>> Traditional streaming: 2080 ms
>> Streaming with std::to_chars() directly into streambuf: 903 ms
>> Collecting the content in a string buffer of 418 MB: 655 ms
>> Writing the string buffer of 418 MB into a disk file: 146 ms
>
> Interesting, thanks for posting. It's a similar ratio on my machine. I
> can see that the Windows way of doing things is definitely more burdensome.
For curiosity, I also added a non-portable memory map variant to
timings. As expected, it beats all the other methods. On Windows it is
ca 21 times faster than ostream<<int streaming, on Linux it is just 3
times faster. It preallocates a large file in advance and trims it into
the correct size later, it might be one can yet shave off some cycles by
doing something smarter.
MSVC++ Win x64 Release:
Traditional streaming (ostream<<int): 16309 ms
Streaming with std::to_chars() directly into streambuf: 1353 ms
Collecting the content in a string buffer of 418 MB: 1123 ms
Writing the string buffer of 418 MB into a disk file: 668 ms
Serializing to memory-mapped file: 753 ms
Speedup of mmap, compared to ostream<<int: 21.6587 times
Linux g++ 8.3:
$ g++ -O3 -std=c++17 test7.cpp
$ ./a.out
Traditional streaming (ostream<<int): 2358 ms
Streaming with std::to_chars() directly into streambuf: 1142 ms
Collecting the content in a string buffer of 418 MB: 674 ms
Writing the string buffer of 418 MB into a disk file: 393 ms
Serializing to memory-mapped file: 772 ms
Speedup of mmap, compared to ostream<<int: 3.0544 times
#include <iostream>
#include <string>
#include <vector>
#include <numeric>
#include <charconv>
#include <chrono>
#include <cstdint>
#include <fstream>
#include <limits>
#include <stdexcept>
#ifdef _WIN32
#define NOMINMAX
#include <Windows.h>
#endif
#ifdef __linux__
#include <fcntl.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/mman.h>
#endif
#ifdef _WIN32
class MMapper {
public:
MMapper(const char* filename, size_t len) {
h_ = ::CreateFileA(filename, GENERIC_WRITE | GENERIC_READ,
FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, CREATE_ALWAYS,
FILE_ATTRIBUTE_NORMAL, NULL);
if (h_==INVALID_HANDLE_VALUE) {
throw std::runtime_error("CreateFileA() failed");
}
LARGE_INTEGER x;
x.QuadPart = len;
if (!::SetFilePointerEx(h_, x, nullptr, FILE_BEGIN)) {
throw std::runtime_error("SetFilePointerEx() failed");
}
if (!::SetEndOfFile(h_)) {
throw std::runtime_error("SetEndOfFile() failed");
}
m_ = ::CreateFileMappingA(h_, NULL, PAGE_READWRITE, 0, 0, NULL);
if (!m_) {
auto err = ::GetLastError();
throw std::runtime_error("CreateFileMappingA() failed");
}
view_ = ::MapViewOfFile(m_, FILE_MAP_WRITE, 0, 0, len);
if (!view_) {
auto err = ::GetLastError();
throw std::runtime_error("MapViewOfFile() failed");
}
}
~MMapper() {
Close(0);
}
void Close(size_t len) {
if (view_) {
::UnmapViewOfFile(view_);
view_ = nullptr;
}
if (m_) {
::CloseHandle(m_);
m_ = nullptr;
}
if (h_) {
LARGE_INTEGER x;
x.QuadPart = len;
if (!::SetFilePointerEx(h_, x, nullptr, FILE_BEGIN)) {
throw std::runtime_error("SetFilePointerEx() failed");
}
if (!::SetEndOfFile(h_)) {
throw std::runtime_error("SetEndOfFile() failed");
}
::CloseHandle(h_);
h_ = nullptr;
}
}
char* Buffer() {
return static_cast<char*>(view_);
}
private:
HANDLE h_, m_;
void* view_;
};
#endif
#ifdef __linux__
class MMapper {
public:
MMapper(const char* filename, size_t len): len_(len) {
fd_ = open(filename, O_CREAT|O_RDWR|O_TRUNC, 0644);
if (fd_==-1) {
throw std::runtime_error("creat() failed");
}
if (ftruncate(fd_, len)!=0) {
throw std::runtime_error("ftruncate() failed");
}
view_ = mmap(nullptr, len, PROT_WRITE, MAP_SHARED, fd_, 0);
if (view_==MAP_FAILED) {
throw std::runtime_error("mmap() failed");
}
}
~MMapper() {
Close(0);
}
void Close(size_t len) {
if (view_) {
munmap(view_, len_);
view_ = nullptr;
}
if (fd_!=-1) {
if (ftruncate(fd_, len)!=0) {
throw std::runtime_error("ftruncate() failed");
}
close(fd_);
fd_ = -1;
}
}
char* Buffer() {
return static_cast<char*>(view_);
}
private:
size_t len_;
int fd_;
void* view_;
};
#endif
class A {
public:
A();
// traditional operator<<
friend std::ostream& operator<<(std::ostream& os, const A& a);
// tostring() operator
std::string to_string() const;
// Select whether operator<< uses stream or streambuf interface.
bool useStreamBufOnly = false;
// Return the maximum needed buffer space for serializing.
size_t MaxSerializedSize() const {
char buff[64];
size_t maxLen = std::to_chars(buff, buff+sizeof(buff),
std::numeric_limits<int>::min()).ptr - buff;
return data.size()*(maxLen+1); // +1 for a space between numbers.
}
size_t Serialize(char* buffer) const;
private:
std::vector<int> data;
};
A::A() {
// Initialize data to 50 million ints.
data.resize(50000000);
std::iota(data.begin(), data.end(), 0);
}
std::ostream& operator<<(std::ostream& os, const A& a) {
if (a.useStreamBufOnly) {
// Ignore stream, use streambuf only.
auto streamBuf = os.rdbuf();
const size_t k = 64;
char buff[k];
for (auto x: a.data) {
auto q = std::to_chars(buff, buff+k, x).ptr;
*q++ = ' ';
streamBuf->sputn(buff, q-buff);
}
} else {
// Traditional stream output
for (auto x: a.data) {
os << x << ' ';
}
}
return os;
}
std::string A::to_string() const {
const size_t k = 64;
char buffer[k];
std::string result;
for (auto x: data) {
auto q = std::to_chars(buffer, buffer+k, x).ptr;
*q++ = ' ';
result.append(buffer, q-buffer);
}
return result;
}
size_t A::Serialize(char* buffer) const {
char* p = buffer;
for (auto x: data) {
p = std::to_chars(p, p+64, x).ptr;
*p++ = ' ';
}
return p - buffer;
}
using sclock = std::chrono::steady_clock;
std::int64_t ms(sclock::duration lapse) {
return
std::chrono::duration_cast<std::chrono::milliseconds>(lapse).count();
}
int main() {
try {
A a;
// traditional streaming
a.useStreamBufOnly = false;
sclock::time_point start1 = sclock::now();
std::ofstream sink1("sink1.txt", std::ios::binary);
sink1 << a;
sink1.close();
sclock::time_point finish1 = sclock::now();
std::cout << "Traditional streaming (ostream<<int): " <<
ms(finish1-start1) << " ms\n";
// streaming with to_chars() and streambuf
a.useStreamBufOnly = true;
sclock::time_point start2 = sclock::now();
std::ofstream sink2("sink2.txt", std::ios::binary);
sink2 << a;
sink2.close();
sclock::time_point finish2 = sclock::now();
std::cout << "Streaming with std::to_chars() directly into
streambuf: " << ms(finish2-start2) << " ms\n";
// tostring()
sclock::time_point start3 = sclock::now();
std::string s3 = a.to_string();
sclock::time_point finish3 = sclock::now();
std::cout << "Collecting the content in a string buffer of " <<
s3.length()/(1024*1024) << " MB: " << ms(finish3-start3) << " ms\n";
sclock::time_point start3b = sclock::now();
std::ofstream sink3("sink3.txt", std::ios::binary);
sink3.rdbuf()->sputn(s3.data(), s3.length());
sink3.close();
sclock::time_point finish3b = sclock::now();
std::cout << "Writing the string buffer of " <<
s3.length()/(1024*1024) << " MB into a disk file: " <<
ms(finish3b-start3b) << " ms\n";
// mmap
sclock::time_point start4 = sclock::now();
size_t n = a.MaxSerializedSize();
MMapper sink4("sink4.txt", n);
size_t m = a.Serialize(sink4.Buffer());
sink4.Close(m);
sclock::time_point finish4 = sclock::now();
std::cout << "Serializing to memory-mapped file: " <<
ms(finish4-start4) << " ms\n";
std::cout << "Speedup of mmap, compared to ostream<<int: " <<
double(ms(finish1-start1))/ms(finish4-start4) << " times\n";
} catch (const std::exception& e) {
std::cerr << "EXCEPTION: " << e.what() << "\n";
return EXIT_FAILURE;
}
}
[toc] | [prev] | [next] | [standalone]
Page 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
Back to top | Article view | comp.lang.c++
csiph-web