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 10 of 12 — ← Prev page 1 … 8 9 [10] 11 12 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-22 14:04 +0000 |
| Message-ID | <0KG2J.83569$g81.67846@fx33.iad> |
| In reply to | #81410 |
HorseyWorsey@the_stables.com writes:
>On Wed, 22 Sep 2021 10:51:23 +0100
>Bart <bc@freeuk.com> wrote:
>> #include <iostream>
>>
>> int main()
>> { std::string s="";
>> char t[100];
>>
>> for (int i=1; i<=10000000; ++i) {
>> s += itoa(i,t,10);
>> s += ' ';
>> }
>>
>> std::cout << "S.size = " << s.size() << "\n";
>> }
>>
>
>You learn something new every day. I'd never heard of itoa(). Apparently its
>an ancient K&R function which didn't get included into the ANSI C standard.
>
Because strtoul et al are far more useful than itoa/atoi for
error checking.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-09-22 07:18 -0700 |
| Message-ID | <87r1dgn179.fsf@nosuchdomain.example.com> |
| In reply to | #81408 |
Bart <bc@freeuk.com> writes:
[...]
> #include <iostream>
>
> int main()
> { std::string s="";
> char t[100];
>
> for (int i=1; i<=10000000; ++i) {
> s += itoa(i,t,10);
> s += ' ';
> }
>
> std::cout << "S.size = " << s.size() << "\n";
> }
>
> Compiled as g++ -O2, this runs in 1.3 seconds on my machine. My script
> language might take only twice as long, but is much simpler and
> quicker to write.
I'm a little surprised that compiles. It doesn't on my Linux system,
but it does under Cygwin (but fails with "g++ -std=c++11 -pedantic").
itoa() is non-standard, and apparently it's provided by newlib (Cygwin)
but not by GNU libc (most Linux systems).
std::to_string() (introduced in C++11) is the C++ equivalent.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-23 07:31 +0000 |
| Message-ID | <sihaga$1j77$1@gioia.aioe.org> |
| In reply to | #81408 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-23 11:05 +0300 |
| Message-ID | <sihch6$ms3$1@dont-email.me> |
| In reply to | #81442 |
23.09.2021 10:31 Juha Nieminen kirjutas: > 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. And how is it better to force every custom type to add support for std::ostream streaming? At least one can easily add formatting parameters to tostring() functions, with streams it becomes complicated and hidden. If memory and speed issues are critical then most probably one cannot or should not use iostreams anyway, so this point is moot.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-23 08:28 +0000 |
| Message-ID | <sihdr5$12es$1@gioia.aioe.org> |
| In reply to | #81445 |
Paavo Helde <myfirstname@osa.pri.ee> wrote:
> 23.09.2021 10:31 Juha Nieminen kirjutas:
>> 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.
>
> And how is it better to force every custom type to add support for
> std::ostream streaming? At least one can easily add formatting
> parameters to tostring() functions, with streams it becomes complicated
> and hidden.
So, what's *your* suggested alternative?
(One could suggest std::format(), but AFAIK that's not going to be enormously
more efficient either. It's more of a convenience thing than an efficiency
thing.)
Whatever your suggestion may be, it would be nice if it could be used in
generic code, without much hassle. In other words, being able to do this
kind of thing:
template<typename T>
void foobar(int value, const T& obj)
{
std::cout << "With value " << value << " we got:\n" << obj << "\n";
}
Preferably whatever the solution is, it shouldn't require the type
to dynamically construct a string to be printed, and instead the
type should get an std::ostream (or FILE*, or whatever) that it
can use to directly write whatever it wants there.
I'm not saying such an alternative is impossible (which is better than
overloading operator<< for std::ostream). I'm just asking what it would
look like.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-24 00:51 +0300 |
| Message-ID | <siissf$dqg$1@dont-email.me> |
| In reply to | #81446 |
23.09.2021 11:28 Juha Nieminen kirjutas:
> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> 23.09.2021 10:31 Juha Nieminen kirjutas:
>>> 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.
>>
>> And how is it better to force every custom type to add support for
>> std::ostream streaming? At least one can easily add formatting
>> parameters to tostring() functions, with streams it becomes complicated
>> and hidden.
>
> So, what's *your* suggested alternative?
Suggested alternative for what? Formatting or streaming?
The solutions like printf() and iostreams mix these two up and attempt
to solve them both in one go, and do not really succeed in either, IMO.
Or do you mean an alternative easy syntax for debug printouts? That's a
totally another topic (which I'm not very interested in).
>
> (One could suggest std::format(), but AFAIK that's not going to be enormously
> more efficient either. It's more of a convenience thing than an efficiency
> thing.)
The best performance is delivered by formatting the data into raw
memory. That's what std::to_chars() and Boost's double-conversion are doing.
To avoid memory and latency overheads, this raw memory should be
periodically flushed out to the final destination. For example, if the
output is sent out over network, ideally each TCP frame should be sent
out as soon as it is ready. If it is written in a disk file, the content
should be flushed before the computer free memory is exhausted, etc.
The idea with iostreams is that the data is flushed by each primitive
value written. This can become a bottleneck because iostreams are keen
on doing formatting in addition to streaming and are thus choked full of
virtual functions and multithread-hostile locale dependencies.
My solution would be to cleanly separate the formatting and the
streaming parts. The class would format its content to a raw memory
buffer as needed, and the streaming part would flush the buffer to the
destination as often as needed.
One thing with today's many-gigabyte machines is that in most cases this
need to flush never appears, the whole data structure can be easily
formatted into raw memory fully before sending it to anywhere. BTW, one
does not need to use a fixed-size buffer, for example
std::string::append() is perfectly capable of growing the buffer with
amortized constant complexity.
Some motivations for formatting the whole file in memory first: when
sending data over network one often wants to send Content-Length first
which might not be known before formatting the whole packet. When
storing the data in a local file it often does not really matter if the
file sits in RAM in a userland buffer or in the kernel disk cache.
Thus we arrive to the dreaded "tostring" solution (advocated by Bart for
example). The whole data structure is first formatted into a std::string
or equiv, then streamed out to std::cout or wherever.
Understandably, this solution does not fit 8-bit controllers and like,
but neither do iostreams! At least the "tostring" solution cleanly
separates the formatting and streaming parts, and allows for easy way to
pass formatting parameters to the formatting part. Tell me again how do
I instruct my class operator<< to place "</td><td>" between each output
number when formatting HTML output?
>
> Whatever your suggestion may be, it would be nice if it could be used in
> generic code, without much hassle. In other words, being able to do this
> kind of thing:
>
> template<typename T>
> void foobar(int value, const T& obj)
> {
> std::cout << "With value " << value << " we got:\n" << obj << "\n";
> }
>
> Preferably whatever the solution is, it shouldn't require the type
> to dynamically construct a string to be printed, and instead the
> type should get an std::ostream (or FILE*, or whatever) that it
> can use to directly write whatever it wants there.
Why? Is this just because of memory overhead concerns?
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-24 04:37 +0000 |
| Message-ID | <sijkll$m21$1@gioia.aioe.org> |
| In reply to | #81490 |
Paavo Helde <myfirstname@osa.pri.ee> wrote: >> Preferably whatever the solution is, it shouldn't require the type >> to dynamically construct a string to be printed, and instead the >> type should get an std::ostream (or FILE*, or whatever) that it >> can use to directly write whatever it wants there. > > Why? Is this just because of memory overhead concerns? What is this sudden strange attitude of "efficiency doesn't matter"? This is C++ we are talking about, not Python, or JavaScript, or PHP, or a shell script. The very reason why std::ostream uses operator overloading to become extensible to custom types is that it allows these custom types to output their data in any way they want, using the std::ostream object. If the custom type in question is a list of a million objects, you don't need to allocate and construct a string containing the textual representation of these million objects (the length of the string not even necessarily being known in advance, requiring multiple reallocations), then the string printed, and then the string destroyed... only to immediately doing the exact same thing again with another object (or, heck, with the same object). The operator overloading allows for the object to output one element at a time, without the overhead of constructing a gigantic string, using multiple reallocations. If an alternative to operator overloading is suggested, that alternative shouldn't be worse in terms of performance (and, preferably, not any more difficult to use). If someone says "using operator<< for this is horrible", then by all means suggest a better alternative, not a worse one. A "tostring()" method is *most definitely* a worse one.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-24 07:46 +0000 |
| Message-ID | <Anf3J.44290$ol1.36785@fx42.iad> |
| In reply to | #81498 |
I realy like to_string, to me it is *very usefull* and use it often since then. -- 7-77-777 \|/ --- /|\ On 2021-09-24, Juha Nieminen <nospam@thanks.invalid> wrote: > Paavo Helde <myfirstname@osa.pri.ee> wrote: >>> Preferably whatever the solution is, it shouldn't require the type >>> to dynamically construct a string to be printed, and instead the >>> type should get an std::ostream (or FILE*, or whatever) that it >>> can use to directly write whatever it wants there. >> >> Why? Is this just because of memory overhead concerns? > > What is this sudden strange attitude of "efficiency doesn't matter"? > > This is C++ we are talking about, not Python, or JavaScript, or PHP, > or a shell script. > > The very reason why std::ostream uses operator overloading to become > extensible to custom types is that it allows these custom types to > output their data in any way they want, using the std::ostream > object. If the custom type in question is a list of a million > objects, you don't need to allocate and construct a string > containing the textual representation of these million objects > (the length of the string not even necessarily being known in > advance, requiring multiple reallocations), then the string printed, > and then the string destroyed... only to immediately doing the > exact same thing again with another object (or, heck, with the > same object). > > The operator overloading allows for the object to output one element > at a time, without the overhead of constructing a gigantic string, > using multiple reallocations. > > If an alternative to operator overloading is suggested, that alternative > shouldn't be worse in terms of performance (and, preferably, not any > more difficult to use). If someone says "using operator<< for this > is horrible", then by all means suggest a better alternative, not > a worse one. > > A "tostring()" method is *most definitely* a worse one. -- Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2021-09-24 08:59 -0700 |
| Message-ID | <9cf25bdf-50c8-40cf-a022-3fb8a77574fen@googlegroups.com> |
| In reply to | #81502 |
On Friday, September 24, 2021 at 3:46:49 AM UTC-4, Branimir Maksimovic wrote: > I realy like to_string, to me it is *very usefull* and use it often > since then. It's inherently inefficient though, particularly as it's frequently used to append a small piece of text to a larger string, repeated many times. Thus are many copies created. Daniel
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-24 22:49 +0300 |
| Message-ID | <sila43$n5i$1@dont-email.me> |
| In reply to | #81516 |
24.09.2021 18:59 daniel...@gmail.com kirjutas: > On Friday, September 24, 2021 at 3:46:49 AM UTC-4, Branimir Maksimovic wrote: >> I realy like to_string, to me it is *very usefull* and use it often >> since then. > > It's inherently inefficient though, particularly as it's frequently used to append a > small piece of text to a larger string, repeated many times. Thus are many > copies created. Memory copy is very cheap nowadays. And std::string::append() grows the buffer in the same way as std::vector::push_back, i.e. the complexity of growing a large string piecewise is amortized constant.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-25 00:55 +0000 |
| Message-ID | <Pru3J.74154$QzOf.44513@fx17.iad> |
| In reply to | #81516 |
I don't care about such efficency, as then I would use mine natural language, assembler. -- 7-77-777 \|/ --- /|\ On 2021-09-24, daniel...@gmail.com <danielaparker@gmail.com> wrote: > On Friday, September 24, 2021 at 3:46:49 AM UTC-4, Branimir Maksimovic wrote: >> I realy like to_string, to me it is *very usefull* and use it often >> since then. > > It's inherently inefficient though, particularly as it's frequently used to append a > small piece of text to a larger string, repeated many times. Thus are many > copies created. > > Daniel -- Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-24 12:17 +0300 |
| Message-ID | <sik536$nus$1@dont-email.me> |
| In reply to | #81498 |
24.09.2021 07:37 Juha Nieminen kirjutas:
> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>> Preferably whatever the solution is, it shouldn't require the type
>>> to dynamically construct a string to be printed, and instead the
>>> type should get an std::ostream (or FILE*, or whatever) that it
>>> can use to directly write whatever it wants there.
>>
>> Why? Is this just because of memory overhead concerns?
>
> What is this sudden strange attitude of "efficiency doesn't matter"?
>
> This is C++ we are talking about, not Python, or JavaScript, or PHP,
> or a shell script.
>
It appears we are both concerned about efficiency. Alas, we have
drastically different opinions about where the inefficiencies lure.
Fortunately programming is strongly connected to reality, unlike some
other areas of human activity, so one can check the reality to see
what's really happening.
Here is a test program measuring the two different approaches to
streaming: (A) sending 100 million ints to std::ostream separately, and
(B) formatting them first into a huge std::string, then sending that to
std::ostream in one go. My results are here:
MSVC++ 2019 x64 Release (/O2 optimization):
Traditional streaming: 28561 ms
to_string() streaming: 2663 ms
to_string() is 10.7251 times faster than traditional streaming.
To be honest, g++ 8.3 on Linux (or more exactly, libstdc++) seems to be
much better with iostreams, but still to_string() beats iostreams:
$ g++ -Wall -O2 test5.cpp -std=c++17
$ ./a.out
Traditional streaming: 4268 ms
to_string() streaming: 2592 ms
to_string() is 1.6466 times faster than traditional streaming.
Source code:
#include <iostream>
#include <string>
#include <sstream>
#include <vector>
#include <numeric>
#include <charconv>
#include <chrono>
#include <cstdint>
class A {
public:
A();
// traditional operator<<
friend std::ostream& operator<<(std::ostream& os, const A& a);
// tostring() operator
std::string to_string() const;
private:
std::vector<int> data;
};
A::A() {
// Initialize data to something
data.resize(100000000);
std::iota(data.begin(), data.end(), 0);
}
std::ostream& operator<<(std::ostream& os, const A& a) {
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+0, buffer+k, x, 10).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() {
std::ostringstream sink1, sink2;
A a;
// traditional streaming
sclock::time_point start1 = sclock::now();
sink1 << a;
sclock::time_point finish1 = sclock::now();
std::cout << "Traditional streaming: " << ms(finish1-start1) << "
ms\n";
// tostring()
sclock::time_point start2 = sclock::now();
sink2 << a.to_string();
sclock::time_point finish2 = sclock::now();
std::cout << "to_string() streaming: " << ms(finish2-start2) << "
ms\n";
double ratio = double(ms(finish1-start1))/ms(finish2-start2);
std::cout << "to_string() is " << ratio << " times " <<
(ratio>1.0 ? "faster" : "slower") << " than traditional
streaming.\n";
// Make use of the results to ensure these were not optimized away.
return int(sink1.str().size()-sink2.str().size());
}
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-27 05:25 +0000 |
| Message-ID | <sirkkb$gk$1@gioia.aioe.org> |
| In reply to | #81506 |
Paavo Helde <myfirstname@osa.pri.ee> wrote: > It appears we are both concerned about efficiency. Alas, we have > drastically different opinions about where the inefficiencies lure. > Fortunately programming is strongly connected to reality, unlike some > other areas of human activity, so one can check the reality to see > what's really happening. > > Here is a test program measuring the two different approaches to > streaming: (A) sending 100 million ints to std::ostream separately, and > (B) formatting them first into a huge std::string, then sending that to > std::ostream in one go. My results are here: You are constructing a string with the contents of the data in both cases. This is not what I'm talking about. It's quite obvious (and I have never had any illusion otherwise) that std::ostringstream is extraordinarily inefficient. Obviously using other methods for constructing a string are going to be a million times faster. (I myself pretty much never use std::ostringstream if I can avoid it.) But I am not talking about constructing a string from the content of the data. In fact, I'm talking about the exact opposite: *Avoiding* constructing a string into memory with the data. How do you add support to the standard output functions for custom types without requiring those custom types to create strings from their data, and being able to directly output the data? Many people responding to this challenge are arguing against it by comparing the speed of std::ostream to the speed of some other ways of outputting data. This is not relevant to my question. Just substitute std::ostream with something more efficient. The question remains: How do you add native support for custom types to that output method, without requiring the custom types to create dynamically allocated strings in memory, and instead being able to directly use that output method to print their contents (in whichever way they choose)?
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-27 11:37 +0300 |
| Message-ID | <sirvrp$6jn$1@dont-email.me> |
| In reply to | #81607 |
27.09.2021 08:25 Juha Nieminen kirjutas:
> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> It appears we are both concerned about efficiency. Alas, we have
>> drastically different opinions about where the inefficiencies lure.
>> Fortunately programming is strongly connected to reality, unlike some
>> other areas of human activity, so one can check the reality to see
>> what's really happening.
>>
>> Here is a test program measuring the two different approaches to
>> streaming: (A) sending 100 million ints to std::ostream separately, and
>> (B) formatting them first into a huge std::string, then sending that to
>> std::ostream in one go. My results are here:
I used std::ostringstream only to exclude disk access from timings.
> You are constructing a string with the contents of the data in both cases.
No. In one case I construct a string with data indeed, but with
to_string() approach I construct this string *twice*! And it's still
faster than the first method!
> This is not what I'm talking about. It's quite obvious (and I have never
> had any illusion otherwise) that std::ostringstream is extraordinarily
> inefficient. Obviously using other methods for constructing a string
> are going to be a million times faster. (I myself pretty much never
> use std::ostringstream if I can avoid it.)
It's the general std::ostream interface which is slow. One can easily
switch to ofstream in my example if this feels better, this won't change
the timings much. Here are the results for std::ofstream:
MSVC++ 2019 x64 Release build:
Traditional streaming: 32367 ms
to_string() streaming: 3979 ms
to_string() is 8.13446 times faster than traditional streaming.
g++ 8.3 on Linux:
$ g++ -Wall -O2 test5.cpp -std=c++17
$ ./a.out
Traditional streaming: 3451 ms
to_string() streaming: 1771 ms
to_string() is 1.94862 times faster than traditional streaming.
Source code below.
>
> But I am not talking about constructing a string from the content of
> the data. In fact, I'm talking about the exact opposite: *Avoiding*
> constructing a string into memory with the data.
Why? In my practice this is a major usage scenario.
>
> How do you add support to the standard output functions for custom
> types without requiring those custom types to create strings from
> their data, and being able to directly output the data?
Why? What's wrong with creating strings?
> Just substitute std::ostream with something more efficient.
I just did. It's called to_string().
> The question remains: How do you add native support for custom
> types to that output method, without requiring the custom types
> to create dynamically allocated strings in memory, and instead
> being able to directly use that output method to print their
> contents (in whichever way they choose)?
Why? A lot of data transfer mechanisms use internal memory buffers,
which often are dynamically allocated.
Test source code without std::ostringstream:
#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;
private:
std::vector<int> data;
};
A::A() {
// Initialize data to something
data.resize(100000000);
std::iota(data.begin(), data.end(), 0);
}
std::ostream& operator<<(std::ostream& os, const A& a) {
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() {
std::ofstream sink1("sink1.txt"), sink2("sink2.txt");
A a;
// traditional streaming
sclock::time_point start1 = sclock::now();
sink1 << a;
sclock::time_point finish1 = sclock::now();
std::cout << "Traditional streaming: " << ms(finish1-start1) << "
ms\n";
// tostring()
sclock::time_point start2 = sclock::now();
sink2 << a.to_string();
sclock::time_point finish2 = sclock::now();
std::cout << "to_string() streaming: " << ms(finish2-start2) << "
ms\n";
double ratio = double(ms(finish1-start1))/ms(finish2-start2);
std::cout << "to_string() is " << ratio << " times " <<
(ratio>1.0 ? "faster" : "slower") << " than traditional
streaming.\n";
}
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-28 04:49 +0000 |
| Message-ID | <siu6s0$1qaa$1@gioia.aioe.org> |
| In reply to | #81620 |
Paavo Helde <myfirstname@osa.pri.ee> wrote: >> But I am not talking about constructing a string from the content of >> the data. In fact, I'm talking about the exact opposite: *Avoiding* >> constructing a string into memory with the data. > > Why? In my practice this is a major usage scenario. Because if I want to write something eg. into a file, I don't want to first to have to create a dynamically allocated string, just to write the contents of that string to the file and then destroy that string. I want to write directly to the file. >> How do you add support to the standard output functions for custom >> types without requiring those custom types to create strings from >> their data, and being able to directly output the data? > > Why? What's wrong with creating strings? Because it's useless and inefficient, fills caches with useless garbage and causes memory fragmentation. In the worst cases it consumes a lot of RAM for no good reason. Consider what happens if what you want to write to the file is, for example, three large strings, which you want to write to the file concatenated. What possible benefit would there be in first creating a new string that's a concatenation of those three strings, and then write that string, when you could just as well simply write the three strings directly to the file? I would ask you the reverse: Why dou you want to create a string first, if you could just write to the file directly? >> Just substitute std::ostream with something more efficient. > > I just did. It's called to_string(). to_string() does not write to a file. >> The question remains: How do you add native support for custom >> types to that output method, without requiring the custom types >> to create dynamically allocated strings in memory, and instead >> being able to directly use that output method to print their >> contents (in whichever way they choose)? > > Why? A lot of data transfer mechanisms use internal memory buffers, > which often are dynamically allocated. Because if I am, for example, writing a bunch of strings to a file, I don't want to first concatenate those strings to a new string in memory before writing it. I want to write the strings directly to the file without that useless middle step, which is just a waste of time and memory.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-23 11:29 +0100 |
| Message-ID | <sihkul$f4i$1@dont-email.me> |
| In reply to | #81442 |
On 23/09/2021 08:31, Juha Nieminen wrote: > 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. I'm not forcing anything at all. Custom types can have dedicated tostring routines; or use default ones; or have nothing. You should look more towards scripting languages, you can learn a lot from them! They will usually have default printing of any types. (The first one I implemented was on IBM PCs with floppy disks, in mid-80s. The advantage was that functionality of a program could be stored as separate bytecode modules that could be loaded as needed, easing pressure on main memory. Of course, there were used where appropriate; not for the core routines (of my GUI apps) that needed to be fast.) >> 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. My point is that sprintf is used when you /want/ to end up with a string. Which is what my sprint() version of my print statement does. You didn't seem to like the idea of any print routine generating strings.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-24 04:38 +0000 |
| Message-ID | <sijkoq$m21$2@gioia.aioe.org> |
| In reply to | #81457 |
Bart <bc@freeuk.com> wrote: > On 23/09/2021 08:31, Juha Nieminen wrote: >> 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. > > I'm not forcing anything at all. Custom types can have dedicated > tostring routines; or use default ones; or have nothing. Then how exactly do you add support for your type into the standard printing function, if not by forcing your type to have a "tostring" method?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-24 11:15 +0100 |
| Message-ID | <sik8ge$rcr$1@dont-email.me> |
| In reply to | #81499 |
On 24/09/2021 05:38, Juha Nieminen wrote: > Bart <bc@freeuk.com> wrote: >> On 23/09/2021 08:31, Juha Nieminen wrote: >>> 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. >> >> I'm not forcing anything at all. Custom types can have dedicated >> tostring routines; or use default ones; or have nothing. > > Then how exactly do you add support for your type into the standard > printing function, if not by forcing your type to have a "tostring" > method? > I've lost track of what you're asking. But if there is really a need to convert of value of some abstract type T into a sequenct of characters, then how else can be it done other than providing support functions which does that conversion? If your quibble about having to do the whole conversion into some intermediate string before starting to output characters from that new string, rather than do it a character at a time? I'm sure, it's possible to that that conversion incrementally, to provide that conversion in the form of a generator function, which yields the next character (not sure what C++ capabilities are here). Or to provide a callback function to the translation function to tell it what to do with each new generated character. Although both of sound a lot less efficient to me. Probably 99% of all print items would have an intermediate string less than 100 characters along, so that a simple fixed buffer would suffice. That's a better idea than sending a character at time to some stream-processing function (like fputc).
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-24 10:19 +0000 |
| Message-ID | <8Dh3J.92989$jl2.68599@fx34.iad> |
| In reply to | #81510 |
Efficincy in IO is not issue as IO itself is SLOW. Also ALGORITHM is WHAT COUNTS, this is how HUMANS can always BEAT compilers. -- 7-77-777 \|/ /|\ On 2021-09-24, Bart <bc@freeuk.com> wrote: > On 24/09/2021 05:38, Juha Nieminen wrote: >> Bart <bc@freeuk.com> wrote: >>> On 23/09/2021 08:31, Juha Nieminen wrote: >>>> 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. >>> >>> I'm not forcing anything at all. Custom types can have dedicated >>> tostring routines; or use default ones; or have nothing. >> >> Then how exactly do you add support for your type into the standard >> printing function, if not by forcing your type to have a "tostring" >> method? >> > > I've lost track of what you're asking. > > But if there is really a need to convert of value of some abstract type > T into a sequenct of characters, then how else can be it done other than > providing support functions which does that conversion? > > If your quibble about having to do the whole conversion into some > intermediate string before starting to output characters from that new > string, rather than do it a character at a time? > > I'm sure, it's possible to that that conversion incrementally, to > provide that conversion in the form of a generator function, which > yields the next character (not sure what C++ capabilities are here). > > Or to provide a callback function to the translation function to tell it > what to do with each new generated character. Although both of sound a > lot less efficient to me. > > Probably 99% of all print items would have an intermediate string less > than 100 characters along, so that a simple fixed buffer would suffice. > That's a better idea than sending a character at time to some > stream-processing function (like fputc). > -- Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-27 05:34 +0000 |
| Message-ID | <sirl5a$5e8$1@gioia.aioe.org> |
| In reply to | #81510 |
Bart <bc@freeuk.com> wrote: >> Then how exactly do you add support for your type into the standard >> printing function, if not by forcing your type to have a "tostring" >> method? >> > > I've lost track of what you're asking. > > But if there is really a need to convert of value of some abstract type > T into a sequenct of characters, then how else can be it done other than > providing support functions which does that conversion? By providing a way for the custom type to directly output its contents to the output (in whichever way it chooses), rather than forcing it to create a dynamically allocated string in memory (which then gets immediately destroyed afterwards). In C++, when you overload operator<< for std::ostream, the custom type does not need to construct any strings with its contents. It can output directly to that std::ostream object. (The speed of std::ostream itself is not the relevant thing here.) I am not asking to replicate the way in which C++ solved that problem. I am asking what's your own suggestion for a better alternative (that does not involve forcing types to create dynamically allocated strings). > Probably 99% of all print items would have an intermediate string less > than 100 characters along, so that a simple fixed buffer would suffice. Would that be a fixed buffer per object, or per type? If it's a fixed buffer per object, then if you have a million objects that would be 100 million bytes in buffers in total. If it's per type, then that's not very thread-safe. Nor is it completely safe even in single-threaded mode, if the references to the returned strings can outlive their retrieval (so that you can have several references to the strings returned by several objects... which would all in fact refer to the same fixed buffer, which contents would only be that of the last object called, making the other references invalid, with no warning.)
[toc] | [prev] | [next] | [standalone]
Page 10 of 12 — ← Prev page 1 … 8 9 [10] 11 12 Next page →
Back to top | Article view | comp.lang.c++
csiph-web