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 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-22 05:06 +0000 |
| Message-ID | <siedkq$1n0a$1@gioia.aioe.org> |
| In reply to | #81346 |
Bart <bc@freeuk.com> wrote: > Now you're saying that we need more templates on top of that to make the > syntax palatable. > > It's not surprising that people complain about C++ being slower to compile! So you want to trade runtime efficiency for compilation efficiency, essentially? > My print statements also come as the function-like sprint()/sfprint() > that just return a string anyway. 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. This is very typical of eg. scripting languages and many other similar languages (usually interpreted, sometimes compiled). Dynamically allocated strings and objects are liberally created at every turn, things are converted into strings and from strings all the time, and so on and so forth, with exactly zero regard to how costly that may or may not be. A rampant "as long as it works" mentality, with zero regard to efficiency. That's not C++ (nor C for that matter). If you don't like the design of the language, then don't use it. It's that simple.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-22 10:51 +0100 |
| Message-ID | <sieub2$trn$1@dont-email.me> |
| In reply to | #81402 |
On 22/09/2021 06:06, Juha Nieminen wrote:
> Bart <bc@freeuk.com> wrote:
>> Now you're saying that we need more templates on top of that to make the
>> syntax palatable.
>>
>> It's not surprising that people complain about C++ being slower to compile!
>
> So you want to trade runtime efficiency for compilation efficiency,
> essentially?
>
>> My print statements also come as the function-like sprint()/sfprint()
>> that just return a string anyway.
>
> 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!
But I develop two languages, one for systems programming, one scripting.
I understand when it is appropriate to use scripting techniques, and
when it isn't.
If you need to use sprintf() C, then that's when you might also consider
using sprint() elsewhere.
> This is very typical of eg. scripting languages and many other
> similar languages (usually interpreted, sometimes compiled). Dynamically
> allocated strings and objects are liberally created at every turn, things
> are converted into strings and from strings all the time, and so on and
> so forth, with exactly zero regard to how costly that may or may not be.
No; obviously you don't know how they work. Because they are slower, you
have even more regard for efficiency, and avoid gratuitous string
operations.
> A rampant "as long as it works" mentality, with zero regard to efficiency.
>
> That's not C++ (nor C for that matter). If you don't like the design of
> the language, then don't use it. It's that simple.
But if you are going to use strings, since sometimes you will need to
synthesise text files (eg. textual output of a compiler), have a look at
this little test in C++ which stringifies the numbers from 1 to 10M into
one string:
#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.
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-22 10:54 +0000 |
| Message-ID | <sif218$gmj$1@gioia.aioe.org> |
| In reply to | #81408 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-22 11:59 +0100 |
| Message-ID | <sif2b8$oto$1@dont-email.me> |
| In reply to | #81410 |
On 22/09/2021 11:54, HorseyWorsey@the_stables.com wrote:
> 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.
>
So what would be the shiny new alternative in C++?
I wanted to avoid sprintf which has extra overheads that would likely
dominate the timing.
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-22 11:04 +0000 |
| Message-ID | <sif2jd$oob$1@gioia.aioe.org> |
| In reply to | #81411 |
On Wed, 22 Sep 2021 11:59:46 +0100
Bart <bc@freeuk.com> wrote:
>On 22/09/2021 11:54, HorseyWorsey@the_stables.com wrote:
>> 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.
>>
>
>So what would be the shiny new alternative in C++?
stringstream which has always struck me as horrible inefficient and I've never
understood why std::string didn't have a built in number to string conversion.
>I wanted to avoid sprintf which has extra overheads that would likely
>dominate the timing.
Probably fewer overheads than stringstream. However there's always strtol().
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2021-09-22 14:17 +0200 |
| Message-ID | <sif6tl$pjq$1@dont-email.me> |
| In reply to | #81411 |
On 22 Sep 2021 12:59, Bart wrote:
> On 22/09/2021 11:54, HorseyWorsey@the_stables.com wrote:
>> 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.
>>
>
> So what would be the shiny new alternative in C++?
>
> I wanted to avoid sprintf which has extra overheads that would likely
> dominate the timing.
#include <stddef.h> // ptrdiff_t
#include <stdio.h> // printf, for the final output
using Size = ptrdiff_t;
#include <charconv> // std::to_chars
#include <limits> // std::numeric_limits
#include <string> // std::string
#include <stdexcept> // std::runtime_error
using namespace std::string_literals;
void append_to( std::string& s, const int v )
{
static const int radix = 10;
static const int max_int_digits =
std::numeric_limits<int>::digits10 + 1;
const Size original_size = s.size();
s.resize( original_size + max_int_digits + 1 ); // 1 for
possible sign.
using P_char = char*;
const P_char buffer_start = s.data() + original_size;
const P_char buffer_end = s.data() + s.size();
const std::to_chars_result tcr = std::to_chars( buffer_start,
buffer_end, v, radix );
if( tcr.ec == std::errc() ) {
s.resize( tcr.ptr - s.data() );
} else {
throw std::runtime_error( ""s + __func__ + " - std::to_chars
failed." );
}
}
auto main() -> int
{
const int n = 10'000'000;
std::string text;
text.reserve( 10*n ); // Avoid (most of the) repeated dynamic
allocations.
for( int i = 1; i <= n; ++i ) {
append_to( text, i );
text += ' ';
}
printf( "text.size = %d\n", int( text.size() ) );
}
Building and running it in Powershell (using that abomination b/c it's
got timing commands, and too lazy to enable dev mode in this Windows):
PS D:\temp> g++ -std=c++17 -O2 .\x.cpp
PS D:\temp> (measure-command { .\a.exe | out-default }).TotalMilliseconds
text.size = 78888897
264.2677
PS D:\temp> (measure-command { .\a.exe | out-default }).TotalMilliseconds
text.size = 78888897
219.7058
PS D:\temp> (measure-command { .\a.exe | out-default }).TotalMilliseconds
text.size = 78888897
204.7605
Apparently it runs faster each time. However, if anyone's particularly
interested in that, or how to report processor time instead of wall
clock time in Windows, then hey, you got a nice project to engage in.
- Alf
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-22 14:32 +0100 |
| Message-ID | <sifb9d$pl5$1@dont-email.me> |
| In reply to | #81414 |
On 22/09/2021 13:17, Alf P. Steinbach wrote:
> #include <stddef.h> // ptrdiff_t
> #include <stdio.h> // printf, for the final output
> using Size = ptrdiff_t;
>
> #include <charconv> // std::to_chars
> #include <limits> // std::numeric_limits
> #include <string> // std::string
> #include <stdexcept> // std::runtime_error
> using namespace std::string_literals;
>
> void append_to( std::string& s, const int v )
> {
> static const int radix = 10;
> static const int max_int_digits =
> std::numeric_limits<int>::digits10 + 1;
>
> const Size original_size = s.size();
> s.resize( original_size + max_int_digits + 1 ); // 1 for
> possible sign.
>
> using P_char = char*;
> const P_char buffer_start = s.data() + original_size;
> const P_char buffer_end = s.data() + s.size();
> const std::to_chars_result tcr = std::to_chars( buffer_start,
> buffer_end, v, radix );
> if( tcr.ec == std::errc() ) {
> s.resize( tcr.ptr - s.data() );
> } else {
> throw std::runtime_error( ""s + __func__ + " - std::to_chars
> failed." );
> }
> }
>
> auto main() -> int
> {
> const int n = 10'000'000;
> std::string text;
> text.reserve( 10*n ); // Avoid (most of the) repeated dynamic
> allocations.
> for( int i = 1; i <= n; ++i ) {
> append_to( text, i );
> text += ' ';
> }
> printf( "text.size = %d\n", int( text.size() ) );
> }
>
This fails rextester.com (doesn't know charconv); and my
g++/mingw/10.3.0, doesn't like converting const char to P_char.
If I use '-fpermissive' to get around that, then I get a timing of 0.56;
more than twice as fast was my earlier time. I think about 5 times as
fast as my dynamic code.
However, if you are going to write custom code, then I can do the same...
This is my script:
s ::= "" # ::= makes a mutable copy
for i to 10 million do
s +:= tostr(i)
s +:= ' '
od
println s.len
(It uses 64-bit ints which impact the int-to-text conversion, which is
not optimised for base-10.)
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2021-09-22 16:23 +0200 |
| Message-ID | <sife8n$f5u$1@dont-email.me> |
| In reply to | #81418 |
On 22 Sep 2021 15:32, Bart wrote:
> On 22/09/2021 13:17, Alf P. Steinbach wrote:
>> #include <stddef.h> // ptrdiff_t
>> #include <stdio.h> // printf, for the final output
>> using Size = ptrdiff_t;
>>
>> #include <charconv> // std::to_chars
>> #include <limits> // std::numeric_limits
>> #include <string> // std::string
>> #include <stdexcept> // std::runtime_error
>> using namespace std::string_literals;
>>
>> void append_to( std::string& s, const int v )
>> {
>> static const int radix = 10;
>> static const int max_int_digits =
>> std::numeric_limits<int>::digits10 + 1;
>>
>> const Size original_size = s.size();
>> s.resize( original_size + max_int_digits + 1 ); // 1 for
>> possible sign.
>>
>> using P_char = char*;
>> const P_char buffer_start = s.data() + original_size;
>> const P_char buffer_end = s.data() + s.size();
>> const std::to_chars_result tcr = std::to_chars( buffer_start,
>> buffer_end, v, radix );
>> if( tcr.ec == std::errc() ) {
>> s.resize( tcr.ptr - s.data() );
>> } else {
>> throw std::runtime_error( ""s + __func__ + " - std::to_chars
>> failed." );
>> }
>> }
>>
>> auto main() -> int
>> {
>> const int n = 10'000'000;
>> std::string text;
>> text.reserve( 10*n ); // Avoid (most of the) repeated
>> dynamic allocations.
>> for( int i = 1; i <= n; ++i ) {
>> append_to( text, i );
>> text += ' ';
>> }
>> printf( "text.size = %d\n", int( text.size() ) );
>> }
>>
>
> This fails rextester.com (doesn't know charconv); and my
> g++/mingw/10.3.0, doesn't like converting const char to P_char.
There's a good chance both problems are due to compiling for a too old
C++ standard.
Namely, `to_chars` was introduced in C++17, and the non-`const`
`basic_string::data()`, producing a `char*`, was introduced in C++17;
see <url: https://en.cppreference.com/w/cpp/string/basic_string/data>.
So, specify `-std=c++17` or later.
> If I use '-fpermissive' to get around that, then I get a timing of 0.56;
> more than twice as fast was my earlier time. I think about 5 times as
> fast as my dynamic code.
Not sure how you manage to compile this without `-std=c++17` though.
Now that begins to look like a mystery! :-o
> However, if you are going to write custom code, then I can do the same...
>
> This is my script:
>
> s ::= "" # ::= makes a mutable copy
>
> for i to 10 million do
> s +:= tostr(i)
> s +:= ' '
> od
>
> println s.len
>
> (It uses 64-bit ints which impact the int-to-text conversion, which is
> not optimised for base-10.)
I didn't present custom code for the conversion.
The added code was for a reasonable wrapping of the `std::to_chars` call.
- Alf
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-22 15:18 +0300 |
| Message-ID | <sif6u8$ogi$1@dont-email.me> |
| In reply to | #81411 |
22.09.2021 13:59 Bart kirjutas: > On 22/09/2021 11:54, HorseyWorsey@the_stables.com wrote: >> 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. >> > > So what would be the shiny new alternative in C++? std::to_string() https://en.cppreference.com/w/cpp/string/basic_string/to_string
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2021-09-22 16:16 +0200 |
| Message-ID | <sifdsq$bf5$1@dont-email.me> |
| In reply to | #81415 |
On 22 Sep 2021 14:18, Paavo Helde wrote: > 22.09.2021 13:59 Bart kirjutas: >> On 22/09/2021 11:54, HorseyWorsey@the_stables.com wrote: >>> 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. >>> >> >> So what would be the shiny new alternative in C++? > > std::to_string() > > https://en.cppreference.com/w/cpp/string/basic_string/to_string Not fast and not locale-independent (it uses the C library's locale). Better use C++17 `to_chars`, <url: https://en.cppreference.com/w/cpp/utility/to_chars>. I gave a more or less full example in reply to the same posting you replied to. - Alf
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-22 15:15 +0000 |
| Message-ID | <sifh9s$1hh$1@gioia.aioe.org> |
| In reply to | #81420 |
On Wed, 22 Sep 2021 16:16:57 +0200 "Alf P. Steinbach" <alf.p.steinbach@gmail.com> wrote: >On 22 Sep 2021 14:18, Paavo Helde wrote: >> 22.09.2021 13:59 Bart kirjutas: >>> On 22/09/2021 11:54, HorseyWorsey@the_stables.com wrote: >>>> 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. >>>> >>> >>> So what would be the shiny new alternative in C++? >> >> std::to_string() >> >> https://en.cppreference.com/w/cpp/string/basic_string/to_string > >Not fast and not locale-independent (it uses the C library's locale). > >Better use C++17 `to_chars`, <url: >https://en.cppreference.com/w/cpp/utility/to_chars>. > >I gave a more or less full example in reply to the same posting you >replied to. Because a 20 line user function just to convert a number into a string is soooo efficient. But then someone who writes "auto main() -> int" instead of "int main()" and then forgets the return value at the end anyway is probably not someone who writes sensible code.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2021-09-22 17:57 +0200 |
| Message-ID | <sifjps$paa$1@dont-email.me> |
| In reply to | #81425 |
On 22 Sep 2021 17:15, HorseyWorsey@the_stables.com wrote: > On Wed, 22 Sep 2021 16:16:57 +0200 > "Alf P. Steinbach" <alf.p.steinbach@gmail.com> wrote: >> On 22 Sep 2021 14:18, Paavo Helde wrote: >>> 22.09.2021 13:59 Bart kirjutas: >>>> On 22/09/2021 11:54, HorseyWorsey@the_stables.com wrote: >>>>> 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. >>>>> >>>> >>>> So what would be the shiny new alternative in C++? >>> >>> std::to_string() >>> >>> https://en.cppreference.com/w/cpp/string/basic_string/to_string >> >> Not fast and not locale-independent (it uses the C library's locale). >> >> Better use C++17 `to_chars`, <url: >> https://en.cppreference.com/w/cpp/utility/to_chars>. >> >> I gave a more or less full example in reply to the same posting you >> replied to. > > Because a 20 line user function just to convert a number into a string is > soooo efficient. > > But then someone who writes "auto main() -> int" instead of "int main()" > and then forgets the return value at the end anyway is probably not someone > who writes sensible code. Attempt to troll someone else, please. - Alf
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-22 16:05 +0000 |
| Message-ID | <sifk7r$1ksr$1@gioia.aioe.org> |
| In reply to | #81426 |
On Wed, 22 Sep 2021 17:57:46 +0200 "Alf P. Steinbach" <alf.p.steinbach@gmail.com> wrote: >On 22 Sep 2021 17:15, HorseyWorsey@the_stables.com wrote: >> On Wed, 22 Sep 2021 16:16:57 +0200 >> "Alf P. Steinbach" <alf.p.steinbach@gmail.com> wrote: >>> On 22 Sep 2021 14:18, Paavo Helde wrote: >>>> 22.09.2021 13:59 Bart kirjutas: >>>>> On 22/09/2021 11:54, HorseyWorsey@the_stables.com wrote: >>>>>> 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. >>>>>> >>>>> >>>>> So what would be the shiny new alternative in C++? >>>> >>>> std::to_string() >>>> >>>> https://en.cppreference.com/w/cpp/string/basic_string/to_string >>> >>> Not fast and not locale-independent (it uses the C library's locale). >>> >>> Better use C++17 `to_chars`, <url: >>> https://en.cppreference.com/w/cpp/utility/to_chars>. >>> >>> I gave a more or less full example in reply to the same posting you >>> replied to. >> >> Because a 20 line user function just to convert a number into a string is >> soooo efficient. >> >> But then someone who writes "auto main() -> int" instead of "int main()" >> and then forgets the return value at the end anyway is probably not someone >> who writes sensible code. > >Attempt to troll someone else, please. Your example was a joke. Thats not trolling, thats a fact.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-09-22 14:13 -0700 |
| Message-ID | <87fstwmhz0.fsf@nosuchdomain.example.com> |
| In reply to | #81425 |
HorseyWorsey@the_stables.com writes:
[...]
> But then someone who writes "auto main() -> int" instead of "int main()"
> and then forgets the return value at the end anyway is probably not someone
> who writes sensible code.
Were you not aware that reaching the closing "}" of main() does an
implicit "return 0;"?
--
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 | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-23 09:01 +0000 |
| Message-ID | <sihfof$1vc6$1@gioia.aioe.org> |
| In reply to | #81430 |
On Wed, 22 Sep 2021 14:13:39 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >HorseyWorsey@the_stables.com writes: >[...] >> But then someone who writes "auto main() -> int" instead of "int main()" >> and then forgets the return value at the end anyway is probably not someone >> who writes sensible code. > >Were you not aware that reaching the closing "}" of main() does an >implicit "return 0;"? And in C function return types default to int so perhaps for int functions we shouldn't bother to specify the types? Whats your point? If he decides to be a smartarse by using that syntax you'd think he'd dot all the i's etc.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-09-23 12:08 -0400 |
| Message-ID | <sii8q1$sqf$1@dont-email.me> |
| In reply to | #81448 |
On 9/23/21 5:01 AM, HorseyWorsey@the_stables.com wrote: > On Wed, 22 Sep 2021 14:13:39 -0700 > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: ... >> Were you not aware that reaching the closing "}" of main() does an >> implicit "return 0;"? > > And in C function return types default to int ... That hasn't been true since C99, 22 years ago, and that's the same version in which the rule that Keith mentioned was added to C. There's never been a version of standard C for which both features applied.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-09-23 10:55 -0700 |
| Message-ID | <878rznmb24.fsf@nosuchdomain.example.com> |
| In reply to | #81448 |
HorseyWorsey@the_stables.com writes:
> On Wed, 22 Sep 2021 14:13:39 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>HorseyWorsey@the_stables.com writes:
>>[...]
>>> But then someone who writes "auto main() -> int" instead of "int main()"
>>> and then forgets the return value at the end anyway is probably not someone
>>> who writes sensible code.
>>
>>Were you not aware that reaching the closing "}" of main() does an
>>implicit "return 0;"?
>
> And in C function return types default to int so perhaps for int functions
> we shouldn't bother to specify the types?
That is neither true nor relevant. C dropped the implicit int rule in 1999.
> Whats your point? If he decides
> to be a smartarse by using that syntax you'd think he'd dot all the i's etc.
My point is that your criticism is invalid. Omitting a final "return 0;"
in main is perfectly valid. It's not an i that needs to be dotted.
(See the code examples in Stroustrup's books.)
--
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 | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-22 20:46 +0300 |
| Message-ID | <sifq4r$bii$1@dont-email.me> |
| In reply to | #81420 |
22.09.2021 17:16 Alf P. Steinbach kirjutas: > On 22 Sep 2021 14:18, Paavo Helde wrote: >> 22.09.2021 13:59 Bart kirjutas: >>> On 22/09/2021 11:54, HorseyWorsey@the_stables.com wrote: >>>> 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. >>>> >>> >>> So what would be the shiny new alternative in C++? >> >> std::to_string() >> >> https://en.cppreference.com/w/cpp/string/basic_string/to_string > > Not fast and not locale-independent (it uses the C library's locale). > > Better use C++17 `to_chars`, <url: > https://en.cppreference.com/w/cpp/utility/to_chars>. > > I gave a more or less full example in reply to the same posting you > replied to. Yes, I saw your post later. You are right to_chars() ought to be faster indeed. Unfortunately I have not had a chance yet to try it out. Locale and speed issues are most severe for floating-point. At the moment we are using Google's double-conversion library for double->string conversion, this seems to be pretty fast as well.
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2021-09-22 14:42 -0700 |
| Message-ID | <9d6ae75b-52f8-46c8-a4e3-b4d3d8e58e32n@googlegroups.com> |
| In reply to | #81415 |
On Wednesday, September 22, 2021 at 8:18:27 AM UTC-4, Paavo Helde wrote: > 22.09.2021 13:59 Bart kirjutas: > > > > So what would be the shiny new alternative in C++? > std::to_string() > > https://en.cppreference.com/w/cpp/string/basic_string/to_string Strange that in a language that's supposed to support genericity and user provided allocators, we have these things that support neither genericity or user provided allocators. Daniel
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-09-23 09:15 +0300 |
| Message-ID | <sih621$erb$1@dont-email.me> |
| In reply to | #81431 |
23.09.2021 00:42 daniel...@gmail.com kirjutas: > On Wednesday, September 22, 2021 at 8:18:27 AM UTC-4, Paavo Helde wrote: >> 22.09.2021 13:59 Bart kirjutas: >>> >>> So what would be the shiny new alternative in C++? >> std::to_string() >> >> https://en.cppreference.com/w/cpp/string/basic_string/to_string > > Strange that in a language that's supposed to support genericity and > user provided allocators, we have these things that support neither > genericity or user provided allocators. std::to_string() is a convenience function, meant for people who are uncapable of writing their own 3-liner wrappers around sprintf(). stream<< is generic, but potentially slower and not so convenient to use, especially when the result should not go to a C++ stream. std::to_chars() is fast, but not generic (plus it also lacks locale support) and is not so convenient to use either as demonstrated by Alf's multi-page example about how to use it. It does not use allocators though. TBH, most std::string implementations are using short-string optimization nowadays, so in most cases std::to_string() should not involve any dynamic memory allocation either.
[toc] | [prev] | [next] | [standalone]
Page 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
Back to top | Article view | comp.lang.c++
csiph-web