Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #70446 > unrolled thread
| Started by | woodbrian77@gmail.com |
|---|---|
| First post | 2019-12-13 21:28 -0800 |
| Last post | 2019-12-15 09:49 +0000 |
| Articles | 20 on this page of 309 — 26 participants |
Back to article view | Back to comp.lang.c++
Don't be fooled by cpp.sh woodbrian77@gmail.com - 2019-12-13 21:28 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-14 09:23 +0000
Re: Don't be fooled by cpp.sh Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-14 17:19 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-14 09:54 -0800
Re: Don't be fooled by cpp.sh woodbrian77@gmail.com - 2019-12-14 12:00 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-14 13:51 -0800
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-14 22:19 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-14 16:13 -0800
Re: Don't be fooled by cpp.sh Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-15 15:35 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-14 22:17 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-14 16:03 -0800
Re: Don't be fooled by cpp.sh Ian Collins <ian-news@hotmail.com> - 2019-12-15 15:41 +1300
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-14 22:55 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-15 09:53 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-15 11:18 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-15 16:44 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-15 20:49 +0000
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-15 15:11 -0800
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-15 23:28 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-15 15:41 -0800
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-16 05:18 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-16 10:46 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-16 09:57 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-16 10:21 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-17 09:37 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-17 15:13 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-17 14:12 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-17 19:35 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-18 16:14 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-17 08:32 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-18 16:26 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-18 19:11 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-18 11:23 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-18 11:31 -0800
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-18 19:56 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-19 08:42 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-19 20:26 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-20 09:25 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-20 04:35 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-20 16:28 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-20 10:36 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-21 16:33 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-21 09:11 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-21 17:22 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-21 10:18 -0800
Re: Don't be fooled by cpp.sh Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-21 21:21 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-21 14:30 -0800
Re: Don't be fooled by cpp.sh Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-22 21:36 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-22 15:05 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-22 17:03 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-22 17:46 +0000
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-22 18:07 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-23 16:23 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-23 16:33 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-23 16:46 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-23 18:51 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-23 17:02 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-23 19:17 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-24 09:49 +0000
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-24 02:16 -0800
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-25 00:30 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-26 09:46 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-26 16:38 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-26 17:33 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-26 19:52 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-27 17:14 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-27 09:41 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-28 12:05 +0000
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-28 21:01 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-29 09:00 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-29 12:21 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-29 18:30 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-29 21:45 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-30 10:10 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-30 14:03 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-30 12:17 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-30 04:39 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-30 13:01 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-30 15:17 +0200
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 14:22 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 16:49 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 17:18 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 18:12 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 18:16 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 18:38 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 19:17 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 20:55 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 03:13 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 13:01 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 13:13 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 14:09 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 14:12 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 15:39 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 15:45 +0100
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-31 15:22 +0000
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 17:16 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 17:51 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 17:59 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 18:21 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 18:35 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 18:51 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 18:59 +0100
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-31 12:23 -0800
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-31 16:14 -0800
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-31 16:52 -0800
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-31 18:58 +0200
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 18:00 +0100
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-31 19:21 +0200
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 18:22 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 18:46 +0100
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-31 20:30 +0200
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 19:44 +0100
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 08:10 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-11 13:03 +0100
Re: Don't be fooled by cpp.sh Ian Collins <ian-news@hotmail.com> - 2020-01-12 07:50 +1300
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2020-01-11 11:55 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-11 23:59 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-01 23:04 +0100
Re: Don't be fooled by cpp.sh Richard Damon <Richard@Damon-Family.org> - 2020-01-04 20:04 -0500
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 13:36 +0100
Re: Don't be fooled by cpp.sh Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-06 18:39 +0000
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-31 16:16 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-31 17:01 -0800
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-01 17:34 +0200
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-01 23:09 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 03:29 +0100
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-30 19:37 -0800
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-31 11:19 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 13:14 +0100
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-31 16:06 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-30 05:39 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 16:39 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-31 09:25 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-31 12:00 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-31 16:10 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-31 16:42 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-01 09:07 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-01 15:48 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 09:24 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-02 12:02 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 10:52 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-02 13:27 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 16:45 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-02 16:55 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 17:24 +0000
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-02 18:30 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-03 09:40 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-02 22:58 +0100
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-02 22:28 -0500
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-02 22:56 -0500
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-02 22:20 -0500
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-03 14:53 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-03 17:22 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-04 12:45 +0000
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-03 09:01 -0800
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-03 10:29 -0800
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-03 21:05 -0500
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 08:46 -0800
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-10 09:51 -0800
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 14:59 -0800
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-31 19:06 +0200
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-31 14:06 +0200
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 13:38 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-31 16:13 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-31 17:06 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-01 09:09 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 18:11 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-01 09:13 +0000
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-01 09:09 -0600
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 09:25 +0000
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-03 10:09 -0600
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-04 12:43 +0000
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-04 18:02 -0600
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-05 10:41 +0000
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-05 12:31 -0600
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-05 20:11 +0100
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2020-01-05 11:22 -0800
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-05 21:07 -0600
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-05 20:40 -0800
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-06 18:08 -0600
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-06 23:17 -0500
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-07 08:37 +0100
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 14:51 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-07 08:28 +0100
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 14:19 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-01 23:15 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 09:33 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-02 12:16 +0100
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-31 18:14 +0000
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 19:16 +0100
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-31 18:48 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-31 12:29 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-01 09:17 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 16:32 +0100
Re: Don't be fooled by cpp.sh Bo Persson <bo@bo-persson.se> - 2019-12-30 14:57 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-31 09:23 +0000
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-30 22:16 -0500
Re: Don't be fooled by cpp.sh Siri Cruise <chine.bleu@yahoo.com> - 2019-12-30 20:30 -0800
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 21:12 -0800
Re: Don't be fooled by cpp.sh Siri Cruise <chine.bleu@yahoo.com> - 2019-12-30 20:07 -0800
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 13:50 +0100
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2020-01-01 08:11 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 09:28 +0000
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 21:26 -0800
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-29 11:31 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-29 18:35 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-29 18:40 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-30 10:12 +0000
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 14:10 +0100
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-29 12:11 -0800
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-29 22:20 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-30 01:23 -0800
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-30 15:54 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-30 17:07 +0000
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-30 19:58 +0000
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-30 23:59 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-30 21:23 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-28 18:09 -0800
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-26 18:30 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-27 17:17 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-27 09:58 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-28 12:06 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-28 08:39 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-28 16:57 +0000
Re: Don't be fooled by cpp.sh Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2020-01-02 23:18 -0500
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-26 10:54 -0800
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-26 22:50 +0200
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-26 10:38 -0800
Re: Don't be fooled by cpp.sh woodbrian77@gmail.com - 2019-12-24 17:52 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-24 23:53 -0800
Re: Don't be fooled by cpp.sh woodbrian77@gmail.com - 2019-12-25 08:51 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-25 10:54 -0800
Re: Don't be fooled by cpp.sh woodbrian77@gmail.com - 2019-12-21 08:42 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-21 09:25 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-18 11:28 -0800
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-18 20:00 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-18 22:12 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-19 08:47 +0000
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 14:03 +0100
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-18 09:47 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-18 11:49 -0800
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-18 12:05 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-18 12:19 -0800
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-16 21:13 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-17 09:38 +0000
Re: Don't be fooled by cpp.sh Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-17 09:14 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-17 17:50 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 09:35 +0100
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-15 20:48 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-16 09:55 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-15 11:12 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-15 06:53 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-15 16:48 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-15 09:10 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-15 18:33 +0000
Re: Don't be fooled by cpp.sh Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-15 19:29 +0000
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-15 23:38 -0500
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-15 21:23 -0800
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-15 21:36 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-15 21:43 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 09:44 +0100
Re: Don't be fooled by cpp.sh Bart <bc@freeuk.com> - 2019-12-16 12:10 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 16:21 +0100
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2019-12-16 10:54 -0600
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-16 10:47 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-16 11:19 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 21:15 +0100
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-16 22:23 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 09:31 +0100
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2019-12-16 23:23 -0600
Re: Don't be fooled by cpp.sh Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-16 21:45 +0000
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2019-12-16 23:20 -0600
Re: Don't be fooled by cpp.sh Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-17 21:56 +0000
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-16 22:06 -0800
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-16 19:42 -0800
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-16 11:56 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 21:18 +0100
Re: Don't be fooled by cpp.sh Bart <bc@freeuk.com> - 2019-12-16 21:03 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 00:04 +0100
Re: Don't be fooled by cpp.sh Bart <bc@freeuk.com> - 2019-12-17 01:06 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 14:51 +0100
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-16 07:25 -0500
Re: Don't be fooled by cpp.sh Bo Persson <bo@bo-persson.se> - 2019-12-16 14:13 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 16:32 +0100
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-16 10:52 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 21:24 +0100
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-16 10:56 -0800
Re: Don't be fooled by cpp.sh Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-16 20:45 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 22:00 +0100
Re: Don't be fooled by cpp.sh Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-17 04:07 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 15:00 +0100
Re: Don't be fooled by cpp.sh Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-17 14:44 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 15:54 +0100
Re: Don't be fooled by cpp.sh Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-17 15:52 +0000
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-17 11:51 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 22:10 +0100
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-17 22:08 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-18 08:56 +0100
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 08:29 -0800
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-17 23:55 -0500
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-18 09:36 -0800
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-16 22:29 -0800
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-16 22:40 -0500
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-16 07:17 -0500
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-15 21:24 -0800
Re: Don't be fooled by cpp.sh Bo Persson <bo@bo-persson.se> - 2019-12-16 12:13 +0100
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-16 07:44 -0500
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-16 18:53 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-15 09:49 +0000
Page 14 of 16 — ← Prev page 1 … 12 13 [14] 15 16 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-16 09:44 +0100 |
| Message-ID | <qt7g4h$2l0$1@dont-email.me> |
| In reply to | #70494 |
On 16/12/2019 06:43, Öö Tiib wrote: > On Monday, 16 December 2019 07:36:32 UTC+2, Daniel wrote: >> On Monday, December 16, 2019 at 12:23:39 AM UTC-5, Öö Tiib wrote: >>> >>> May be it is not about standard but about compiler makers who provide >>> 128 bit integers that are not conformant with std::int128_t. >> >> I don't know any compilers that have std::128_t. gcc and clang have __int128, >> but std::numeric_limits<__int128> is only defined if compiled with e.g. >> -std=gnu++11 and not -std=c++11. > > So don't I know of any. All compilers implement 128 bit integers as > non-standard extensions. > There are technical - but currently unavoidable - reasons why compilers don't provide a full 128-bit integer type. One of these is that if 64-bit gcc were to provide a 128-bit extended integer type (using the C and C++ technical term "extended integer type"), then "maxint_t" would have to be that type rather than "long long int". This would have a knock-on effect on ABI's, libraries, headers, etc., which would be out of the question. Other complications involve support for literals of the type. (That would open more challenges with user-defined literals - you'd need language support for operator "" X(unsigned __int128) as well.) Compilers are free to implement a type that is mostly like a 128-bit integer type. But it can't be classified as an "extended integer type". And thus it can't be added as int128_t and uint128_t. Hopefully the C and/or C++ folks will figure out a way to improve this deadlock, but this is not something the compiler writers can fix by themselves. The nearest they can get is collaborating on the name of the almost-integer-type __int128.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-12-16 12:10 +0000 |
| Message-ID | <ZuKJF.5231$v04.64@fx35.am4> |
| In reply to | #70496 |
On 16/12/2019 08:44, David Brown wrote:
> On 16/12/2019 06:43, Öö Tiib wrote:
>> On Monday, 16 December 2019 07:36:32 UTC+2, Daniel wrote:
>>> On Monday, December 16, 2019 at 12:23:39 AM UTC-5, Öö Tiib wrote:
>>>>
>>>> May be it is not about standard but about compiler makers who provide
>>>> 128 bit integers that are not conformant with std::int128_t.
>>>
>>> I don't know any compilers that have std::128_t. gcc and clang have __int128,
>>> but std::numeric_limits<__int128> is only defined if compiled with e.g.
>>> -std=gnu++11 and not -std=c++11.
>>
>> So don't I know of any. All compilers implement 128 bit integers as
>> non-standard extensions.
>>
>
> There are technical - but currently unavoidable - reasons why compilers
> don't provide a full 128-bit integer type. One of these is that if
> 64-bit gcc were to provide a 128-bit extended integer type (using the C
> and C++ technical term "extended integer type"), then "maxint_t" would
> have to be that type rather than "long long int". This would have a
> knock-on effect on ABI's, libraries, headers, etc., which would be out
> of the question. Other complications involve support for literals of
> the type.
You mean that even when int128 types are built-in, there is no support
for 128-bit constants? And presumably not for output either, according
to my tests with gcc and g++:
__int128_t a;
a=170141183460469231731687303715884105727;
std::cout << a;
The constant overflows, and if I skip that part, I get pages of errors
when trying to print it. On gcc, I have no idea what printf format to use.
This is frankly astonishing with such a big and important language, and
with comprehensive compilers such as gcc and g++. Even my own 'toy'
language can do this:
int128 a := 170'141'183'460'469'231'731'687'303'715'884'105'727
println a
println a:"hs'"
println word128.maxvalue # (ie. uint128)
Output is:
170141183460469231731687303715884105727
7fff'ffff'ffff'ffff'ffff'ffff'ffff'ffff
340282366920938463463374607431768211455
What exactly is the problem with allowing 128-bit constants at least?
(My implementation is by no means complete (eg. 128/128 is missing, it
does 128/64), but it can do most of the basics and I just need to get
around to filling in the gaps.
It will also have arbitrary precision decimal integers /and/ floats
(another thing that was mentioned as missing from core C++), which I'm
working on this month. That will have constant and output support too:
a := 123.456e1000'000L
println a
So mere 128-bit integer-only support is trivial!)
> (That would open more challenges with user-defined literals -
> you'd need language support for operator "" X(unsigned __int128) as well.)
But this would be just a natural extension? I assume that whatever that
means, there is already X(uint64_t). There is not a totally new feature
or concept to add.
(And if your example means there is no '__uint128', then that's another
incredibly easy thing to have fixed!)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-16 16:21 +0100 |
| Message-ID | <qt87dl$8tk$1@dont-email.me> |
| In reply to | #70501 |
On 16/12/2019 13:10, Bart wrote: > On 16/12/2019 08:44, David Brown wrote: >> On 16/12/2019 06:43, Öö Tiib wrote: >>> On Monday, 16 December 2019 07:36:32 UTC+2, Daniel wrote: >>>> On Monday, December 16, 2019 at 12:23:39 AM UTC-5, Öö Tiib wrote: >>>>> >>>>> May be it is not about standard but about compiler makers who provide >>>>> 128 bit integers that are not conformant with std::int128_t. >>>> >>>> I don't know any compilers that have std::128_t. gcc and clang have >>>> __int128, >>>> but std::numeric_limits<__int128> is only defined if compiled with e.g. >>>> -std=gnu++11 and not -std=c++11. >>> >>> So don't I know of any. All compilers implement 128 bit integers as >>> non-standard extensions. >>> >> >> There are technical - but currently unavoidable - reasons why compilers >> don't provide a full 128-bit integer type. One of these is that if >> 64-bit gcc were to provide a 128-bit extended integer type (using the C >> and C++ technical term "extended integer type"), then "maxint_t" would >> have to be that type rather than "long long int". This would have a >> knock-on effect on ABI's, libraries, headers, etc., which would be out >> of the question. Other complications involve support for literals of >> the type. > > You mean that even when int128 types are built-in, there is no support > for 128-bit constants? And presumably not for output either, according > to my tests with gcc and g++: > > __int128_t a; > a=170141183460469231731687303715884105727; > std::cout << a; > > The constant overflows, and if I skip that part, I get pages of errors > when trying to print it. On gcc, I have no idea what printf format to use. > There is no printf support for 128-bit integers, except for systems where "long long" is 128-bit. (Or, hypothetically, 128-bit "long", "int", "short" or "char".) As you know full well, gcc does not have printf, since gcc is a compiler and printf is from the standard library. > This is frankly astonishing with such a big and important language, and > with comprehensive compilers such as gcc and g++. Even my own 'toy' > language can do this: It is only astonishing if you don't understand what it means for a language to have a standard. It's easy to do this with a toy language (and that is an advantage of toy languages). It would not be particularly difficult for the gcc or clang developers to support it either. But the ecosystem around C is huge - you can't change the standard in a way that breaks compatibility, which is what would have to happen to make these types full integer types. I am not convinced that there is any great reason for having full support for 128-bit types here - how often do you really need them? There are plenty of use-cases for big integers, such as in cryptography, but then 128-bit is not nearly big enough. And for situations where 128-bit integers are useful, how often do you need literals of that size? With C++, it would not be difficult to put together a class that acts like a 128-bit integer type for most purposes - including support for literals and std::cout. Consider it a challenge to test your C++ knowledge. > > int128 a := 170'141'183'460'469'231'731'687'303'715'884'105'727 > > println a > println a:"hs'" > println word128.maxvalue # (ie. uint128) > > Output is: > > 170141183460469231731687303715884105727 > 7fff'ffff'ffff'ffff'ffff'ffff'ffff'ffff > 340282366920938463463374607431768211455 > > What exactly is the problem with allowing 128-bit constants at least? > > (My implementation is by no means complete (eg. 128/128 is missing, it > does 128/64), but it can do most of the basics and I just need to get > around to filling in the gaps. > > It will also have arbitrary precision decimal integers /and/ floats > (another thing that was mentioned as missing from core C++), which I'm > working on this month. That will have constant and output support too: > > a := 123.456e1000'000L > println a > > So mere 128-bit integer-only support is trivial!) Arbitrary precision arithmetic is, I think, a lot more useful than 128-bit integers. But it would be well outside the scope of C. It would be more reasonable to implement them it in a C++ library, but it is questionable whether it makes sense for the standard library. After all, there are many ways to implement arbitrary precision arithmetic with significantly different trade-offs in terms of speed, run-time memory efficiency, code space efficiency, and how these match with the type of usage you want for them. > >> (That would open more challenges with user-defined literals - >> you'd need language support for operator "" X(unsigned __int128) as >> well.) > > But this would be just a natural extension? I assume that whatever that > means, there is already X(uint64_t). There is not a totally new feature > or concept to add. > <https://en.cppreference.com/w/cpp/language/user_literal> > (And if your example means there is no '__uint128', then that's another > incredibly easy thing to have fixed!) >
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-12-16 10:54 -0600 |
| Message-ID | <h0dfve5mb6hldeb4agjr248gs6oslba8rq@4ax.com> |
| In reply to | #70506 |
On Mon, 16 Dec 2019 16:21:25 +0100, David Brown <david.brown@hesbynett.no> wrote: >On 16/12/2019 13:10, Bart wrote: >> On 16/12/2019 08:44, David Brown wrote: >>> On 16/12/2019 06:43, Öö Tiib wrote: >>>> On Monday, 16 December 2019 07:36:32 UTC+2, Daniel wrote: >>>>> On Monday, December 16, 2019 at 12:23:39 AM UTC-5, Öö Tiib wrote: >>>>>> >>>>>> May be it is not about standard but about compiler makers who provide >>>>>> 128 bit integers that are not conformant with std::int128_t. >>>>> >>>>> I don't know any compilers that have std::128_t. gcc and clang have >>>>> __int128, >>>>> but std::numeric_limits<__int128> is only defined if compiled with e.g. >>>>> -std=gnu++11 and not -std=c++11. >>>> >>>> So don't I know of any. All compilers implement 128 bit integers as >>>> non-standard extensions. >>>> >>> >>> There are technical - but currently unavoidable - reasons why compilers >>> don't provide a full 128-bit integer type. One of these is that if >>> 64-bit gcc were to provide a 128-bit extended integer type (using the C >>> and C++ technical term "extended integer type"), then "maxint_t" would >>> have to be that type rather than "long long int". This would have a >>> knock-on effect on ABI's, libraries, headers, etc., which would be out >>> of the question. Other complications involve support for literals of >>> the type. >> >> You mean that even when int128 types are built-in, there is no support >> for 128-bit constants? And presumably not for output either, according >> to my tests with gcc and g++: >> >> __int128_t a; >> a=170141183460469231731687303715884105727; >> std::cout << a; >> >> The constant overflows, and if I skip that part, I get pages of errors >> when trying to print it. On gcc, I have no idea what printf format to use. >> > >There is no printf support for 128-bit integers, except for systems >where "long long" is 128-bit. (Or, hypothetically, 128-bit "long", >"int", "short" or "char".) As you know full well, gcc does not have >printf, since gcc is a compiler and printf is from the standard library. > >> This is frankly astonishing with such a big and important language, and >> with comprehensive compilers such as gcc and g++. Even my own 'toy' >> language can do this: > >It is only astonishing if you don't understand what it means for a >language to have a standard. It's easy to do this with a toy language >(and that is an advantage of toy languages). It would not be >particularly difficult for the gcc or clang developers to support it >either. But the ecosystem around C is huge - you can't change the >standard in a way that breaks compatibility, which is what would have to >happen to make these types full integer types. > >I am not convinced that there is any great reason for having full >support for 128-bit types here - how often do you really need them? >There are plenty of use-cases for big integers, such as in cryptography, >but then 128-bit is not nearly big enough. And for situations where >128-bit integers are useful, how often do you need literals of that size? > >With C++, it would not be difficult to put together a class that acts >like a 128-bit integer type for most purposes - including support for >literals and std::cout. Consider it a challenge to test your C++ knowledge. > >> >> int128 a := 170'141'183'460'469'231'731'687'303'715'884'105'727 >> >> println a >> println a:"hs'" >> println word128.maxvalue # (ie. uint128) >> >> Output is: >> >> 170141183460469231731687303715884105727 >> 7fff'ffff'ffff'ffff'ffff'ffff'ffff'ffff >> 340282366920938463463374607431768211455 >> >> What exactly is the problem with allowing 128-bit constants at least? >> >> (My implementation is by no means complete (eg. 128/128 is missing, it >> does 128/64), but it can do most of the basics and I just need to get >> around to filling in the gaps. >> >> It will also have arbitrary precision decimal integers /and/ floats >> (another thing that was mentioned as missing from core C++), which I'm >> working on this month. That will have constant and output support too: >> >> a := 123.456e1000'000L >> println a >> >> So mere 128-bit integer-only support is trivial!) > >Arbitrary precision arithmetic is, I think, a lot more useful than >128-bit integers. But it would be well outside the scope of C. It >would be more reasonable to implement them it in a C++ library, but it >is questionable whether it makes sense for the standard library. After >all, there are many ways to implement arbitrary precision arithmetic >with significantly different trade-offs in terms of speed, run-time >memory efficiency, code space efficiency, and how these match with the >type of usage you want for them. Trivially, arbitrary precision arithmetic is more useful than 128-bit integers, in that the format can do everything the latter can do, and more. On the other hand, a proper bignum library will almost always carry a substantial performance penalty compared to fixed 128-bit integers. Consider that on x86-64 a typical add/subtract/compare reduces to two instructions (ignoring data movement), and a multiply to about three multiplies and two adds (division being the usual PITA). On the third hand, 128-bit integers allow a number of things that 64-bit integers don't - a useful type in which to perform currency calculations, usefully wide (and precise) times, and the like. Personally I think both 128-bit types and arbitrary precision arithmetic should be part of the language (whether in the language proper or the library).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2019-12-16 10:47 -0800 |
| Message-ID | <875zigw1iq.fsf@nosuchdomain.example.com> |
| In reply to | #70508 |
Robert Wessel <robertwessel2@yahoo.com> writes:
[...]
> Personally I think both 128-bit types and arbitrary precision
> arithmetic should be part of the language (whether in the language
> proper or the library).
128-bit integer types are already permitted by the C++ standard.
But adding a standard (extended or not) 128-bit integer type would
conflict with existing ABIs and libraries due to the effect on
[u]intmax_t.
I don't think making 128-bit integers mandatory would be practical,
given the difficulty (and questionable usefulness) of providing
them on small embedded systems. Note that gcc supports __int128,
but not on all targets.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
[Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-16 11:19 -0800 |
| Message-ID | <62a2a890-5519-4594-a7a9-b2dc1226327b@googlegroups.com> |
| In reply to | #70511 |
On Monday, 16 December 2019 20:47:53 UTC+2, Keith Thompson wrote: > Robert Wessel <robertwessel2@yahoo.com> writes: > [...] > > Personally I think both 128-bit types and arbitrary precision > > arithmetic should be part of the language (whether in the language > > proper or the library). > > 128-bit integer types are already permitted by the C++ standard. > But adding a standard (extended or not) 128-bit integer type would > conflict with existing ABIs and libraries due to the effect on > [u]intmax_t. Sure, when humans make ABI they make it non-extendable, immutable and carved into rock? I don't buy it. Didn't we evolve farther from troglodyte apes some time ago? > I don't think making 128-bit integers mandatory would be practical, > given the difficulty (and questionable usefulness) of providing > them on small embedded systems. Note that gcc supports __int128, > but not on all targets. Not mandatory. Even int_least128_t not mandatory ... but just adding some __int128 that is only barely good enough so evil monster companies can implement polished versions into their javas, c#s, gos and swifts is somewhat insulting. Maybe we, C and C++ programmers should give two months strike to those fat fuckers after February world-wide. ;)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-16 21:15 +0100 |
| Message-ID | <qt8ok8$on3$1@dont-email.me> |
| In reply to | #70511 |
On 16/12/2019 19:47, Keith Thompson wrote: > Robert Wessel <robertwessel2@yahoo.com> writes: > [...] >> Personally I think both 128-bit types and arbitrary precision >> arithmetic should be part of the language (whether in the language >> proper or the library). > > 128-bit integer types are already permitted by the C++ standard. > But adding a standard (extended or not) 128-bit integer type would > conflict with existing ABIs and libraries due to the effect on > [u]intmax_t. > > I don't think making 128-bit integers mandatory would be practical, > given the difficulty (and questionable usefulness) of providing > them on small embedded systems. Note that gcc supports __int128, > but not on all targets. > gcc supports 128-bit integers on 64-bit systems, which is not unreasonable. Support for "double size" integers can be done fairly simply and efficiently. I think it would be fine to support them on 32-bit systems too, but it's more effort than it's worth to ask compilers to support 128-bit types on 8-bit processors! I'd like to see some standard way (with standard names) to have 128-bit integer types without increasing intmax_t. I don't think there would be a need to make them mandatory - compilers would support them where they are practical and useful.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2019-12-16 22:23 -0800 |
| Message-ID | <87woavv5bs.fsf@nosuchdomain.example.com> |
| In reply to | #70516 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> I'd like to see some standard way (with standard names) to have
> 128-bit integer types without increasing intmax_t. I don't think
> there would be a need to make them mandatory - compilers would support
> them where they are practical and useful.
I'd greatly prefer to see the *existing* standard way to have 128-bit
integer types *along with* a redefinition of intmax_t as appropriate.
Because **that's what intmax_t means**.
I know that ABIs and existing libraries make that difficult, but
understanding the reasons does not lessen my annoyance.
On the other hand, 64 bits really are enough to count just about
anything. For example, we're not going to see files bigger than
2**64 bytes any time soon. Some standardized way of handling huge
integer-like entities without calling them "integer types" would
probably give us most of the benefits of 128-bit integer types,
and C++ has enough features that it's feasible to do that in the
library rather than in the language.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
[Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-17 09:31 +0100 |
| Message-ID | <qta3ok$h3d$1@dont-email.me> |
| In reply to | #70533 |
On 17/12/2019 07:23, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> I'd like to see some standard way (with standard names) to have >> 128-bit integer types without increasing intmax_t. I don't think >> there would be a need to make them mandatory - compilers would support >> them where they are practical and useful. > > I'd greatly prefer to see the *existing* standard way to have 128-bit > integer types *along with* a redefinition of intmax_t as appropriate. > I'd be fine with that too. > Because **that's what intmax_t means**. > > I know that ABIs and existing libraries make that difficult, but > understanding the reasons does not lessen my annoyance. > Fair enough. It is certainly easy to see that mistakes were made in the way intmax_t has been handled (without necessarily doing the blamestorming) and that this has restricted the way possibilities for bigger standard integer types in C and C++. The question is, where is it possible to go from here? If it is too late to fix maxint_t usage, then we must accept that maxint_t is effectively long long int, and 64-bit on modern "big" processors (as distinct from small embedded devices). Is it possible to get something that works at least as well as gcc's __int128 today, but can be supported with the same name in other compilers, along with appropriate limit macros (and C++ equivalents) ? Also, while it could be nice to have a 128-bit type and make maxint_t use this, I think that would limit the possibilities of 256-bit or 512-bit types in the future. (I am not sure what the usage of these would be - perhaps for sha512 checksums - but let's avoid saying that 128 bits should be big enough for anyone.) If a compiler has int128_t, int256_t and int512_t, do we really want intmax_t to be 512 bits? Do we want to have to use 512 bit arithmetic with imaxdiv when we actually want to divide 128 bit numbers? I think a better solution would be to phase out intmax_t entirely, and move to an explicit sized system. Have printf support explicit sizes for the integers, rather than an endless series of arbitrary letters or a single inefficient huge size. Have the functions named "abs32", "abs64", etc., rather than "imaxabs", and with a type-generic version. > On the other hand, 64 bits really are enough to count just about > anything. For example, we're not going to see files bigger than > 2**64 bytes any time soon. Some standardized way of handling huge > integer-like entities without calling them "integer types" would > probably give us most of the benefits of 128-bit integer types, > and C++ has enough features that it's feasible to do that in the > library rather than in the language. > That's it, yes. For C++, a standard library should be practical - with the size being a template parameter. For C, it would need to be part of the language. But if we had a new term rather than "integer type", the intmax_t problem could be circumvented.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-12-16 23:23 -0600 |
| Message-ID | <4epgvedhj32retat7677ij3rio1qsh1dsg@4ax.com> |
| In reply to | #70511 |
On Mon, 16 Dec 2019 10:47:41 -0800, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >Robert Wessel <robertwessel2@yahoo.com> writes: >[...] >> Personally I think both 128-bit types and arbitrary precision >> arithmetic should be part of the language (whether in the language >> proper or the library). > >128-bit integer types are already permitted by the C++ standard. >But adding a standard (extended or not) 128-bit integer type would >conflict with existing ABIs and libraries due to the effect on >[u]intmax_t. > >I don't think making 128-bit integers mandatory would be practical, >given the difficulty (and questionable usefulness) of providing >them on small embedded systems. Note that gcc supports __int128, >but not on all targets. I don't really buy it. On systems that small, the operations would almost certainly be RTL functions. If you don't define any large types, those routes won't get linked. The way floats are handled on many small systems is a parallel. And the RTL functions for the basic operations aren't actually going to be that large.
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2019-12-16 21:45 +0000 |
| Message-ID | <qt8tu7$l6n$1@dont-email.me> |
| In reply to | #70508 |
On 16/12/2019 16:54, Robert Wessel wrote: > On the third hand, 128-bit integers allow a number of things that > 64-bit integers don't - a useful type in which to perform currency > calculations, usefully wide (and precise) times, and the like. My mind boggles. 32 bit numbers are quite big enough for my financial needs, and the world GDP is only about 40 bits (in USD). What currency work have you done where 64 bit currency wasn't enough? However - the argument against _not_ implementing std::int128_t here seems to be that a lot of people have assumed that the biggest in is only 64 bits. When will people learn... I started in PCs when a pointer and an int were both 16 bit, and people misused int. A few years later they were both 32 bit... now they're generally a different size, and _still_ I see int x = sizeof(...) Andy
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-12-16 23:20 -0600 |
| Message-ID | <3qngvepon0tcn27tp6n0qmsg57fai1n952@4ax.com> |
| In reply to | #70523 |
On Mon, 16 Dec 2019 21:45:47 +0000, Vir Campestris <vir.campestris@invalid.invalid> wrote: >On 16/12/2019 16:54, Robert Wessel wrote: >> On the third hand, 128-bit integers allow a number of things that >> 64-bit integers don't - a useful type in which to perform currency >> calculations, usefully wide (and precise) times, and the like. > >My mind boggles. > >32 bit numbers are quite big enough for my financial needs, and the >world GDP is only about 40 bits (in USD). What currency work have you >done where 64 bit currency wasn't enough? Currency calculations are often performed in pennies or mills for dollars, sometimes even with finer divisions. Exxon's revenue, for example, requires 45 bits to store in pennies. Even global GDP in dollars requires 47 bits (about 85 *trillion* dollars). Toss in some of the badly inflated currencies, and things get worse (before it was reformed, the Turkish Lira was my go-to example - a less dramatic current example is the Iranian Rial, worth less than a thousandth of a penny each). That being said, it's not that 64-bit type are inadequate for stored formats - for the most part they are. Cobol, where if nothing else, they care about handling currency, for decades only required 18 decimal* digits for stored formats, although the more recent standards have doubled that. Some folks have recommended IEEE doubles as a storage format, as that nets you about 53 bits - that's tight for not-that-crazy scenarios (global GDP in pennies) - and that not an attempt to actually store currency in floats (which tends to be *really* problematic) - just to use a double as a fairly wide integer. In any event, 64 bits are usually enough to store currency related values. The problem is intermediate results. Multiply Exxon's revenue by a couple of percentages, and you'll overflow a 64-bit number (even with fairly "short" percentages - tell that you some states that have five digit percentages in their tax rates). So currency calculations really require something bigger than a 64-bit intermediate, in order to compute the exact (correctly rounded) result, since people get funny when you lop off bits of their bank balance. Again, Cobol usually requires longer intermediates in order to produce exact results (and they've understood that since about 1959). 32-bit numbers aren't actually good enough to manage *your* bank account - interest rates are commonly four digits, factor in pennies, and the bank's calculations for your account goes tilt at less than $4300. Again, it might be adequate for *storing* your bank balance (how many of us actually have more than $42 million in an account?), but the bank needs to perform operations on those balances. *Regardless of the actual stored representation, binary, decimal, or something else. In binary 18 decimal digits happens to fit neatly in a 64-bit int.
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2019-12-17 21:56 +0000 |
| Message-ID | <qtbiu4$dmt$1@dont-email.me> |
| In reply to | #70530 |
On 17/12/2019 05:20, Robert Wessel wrote: <snip> > but the bank needs to perform operations on those balances. Ah, that makes sense. Thanks Andy
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-12-16 22:06 -0800 |
| Message-ID | <qt9r9c$e7c$1@gioia.aioe.org> |
| In reply to | #70523 |
On 12/16/2019 1:45 PM, Vir Campestris wrote: > On 16/12/2019 16:54, Robert Wessel wrote: >> On the third hand, 128-bit integers allow a number of things that >> 64-bit integers don't - a useful type in which to perform currency >> calculations, usefully wide (and precise) times, and the like. > > My mind boggles. > > 32 bit numbers are quite big enough for my financial needs, and the > world GDP is only about 40 bits (in USD). What currency work have you > done where 64 bit currency wasn't enough? > > However - the argument against _not_ implementing std::int128_t here > seems to be that a lot of people have assumed that the biggest in is > only 64 bits. When will people learn... > > I started in PCs when a pointer and an int were both 16 bit, and people > misused int. A few years later they were both 32 bit... now they're > generally a different size, and _still_ I see int x = sizeof(...) 64 bits are not even close to what is needed to take a very deep zoom of a fractal.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-12-16 19:42 -0800 |
| Message-ID | <qt9ir4$192j$1@gioia.aioe.org> |
| In reply to | #70508 |
On 12/16/2019 8:54 AM, Robert Wessel wrote: > On Mon, 16 Dec 2019 16:21:25 +0100, David Brown > <david.brown@hesbynett.no> wrote: > >> On 16/12/2019 13:10, Bart wrote: >>> On 16/12/2019 08:44, David Brown wrote: >>>> On 16/12/2019 06:43, Öö Tiib wrote: >>>>> On Monday, 16 December 2019 07:36:32 UTC+2, Daniel wrote: >>>>>> On Monday, December 16, 2019 at 12:23:39 AM UTC-5, Öö Tiib wrote: >>>>>>> >>>>>>> May be it is not about standard but about compiler makers who provide >>>>>>> 128 bit integers that are not conformant with std::int128_t. >>>>>> >>>>>> I don't know any compilers that have std::128_t. gcc and clang have >>>>>> __int128, >>>>>> but std::numeric_limits<__int128> is only defined if compiled with e.g. >>>>>> -std=gnu++11 and not -std=c++11. >>>>> >>>>> So don't I know of any. All compilers implement 128 bit integers as >>>>> non-standard extensions. >>>>> >>>> >>>> There are technical - but currently unavoidable - reasons why compilers >>>> don't provide a full 128-bit integer type. One of these is that if >>>> 64-bit gcc were to provide a 128-bit extended integer type (using the C >>>> and C++ technical term "extended integer type"), then "maxint_t" would >>>> have to be that type rather than "long long int". This would have a >>>> knock-on effect on ABI's, libraries, headers, etc., which would be out >>>> of the question. Other complications involve support for literals of >>>> the type. >>> >>> You mean that even when int128 types are built-in, there is no support >>> for 128-bit constants? And presumably not for output either, according >>> to my tests with gcc and g++: >>> >>> __int128_t a; >>> a=170141183460469231731687303715884105727; >>> std::cout << a; >>> >>> The constant overflows, and if I skip that part, I get pages of errors >>> when trying to print it. On gcc, I have no idea what printf format to use. >>> >> >> There is no printf support for 128-bit integers, except for systems >> where "long long" is 128-bit. (Or, hypothetically, 128-bit "long", >> "int", "short" or "char".) As you know full well, gcc does not have >> printf, since gcc is a compiler and printf is from the standard library. >> >>> This is frankly astonishing with such a big and important language, and >>> with comprehensive compilers such as gcc and g++. Even my own 'toy' >>> language can do this: >> >> It is only astonishing if you don't understand what it means for a >> language to have a standard. It's easy to do this with a toy language >> (and that is an advantage of toy languages). It would not be >> particularly difficult for the gcc or clang developers to support it >> either. But the ecosystem around C is huge - you can't change the >> standard in a way that breaks compatibility, which is what would have to >> happen to make these types full integer types. >> >> I am not convinced that there is any great reason for having full >> support for 128-bit types here - how often do you really need them? >> There are plenty of use-cases for big integers, such as in cryptography, >> but then 128-bit is not nearly big enough. And for situations where >> 128-bit integers are useful, how often do you need literals of that size? >> >> With C++, it would not be difficult to put together a class that acts >> like a 128-bit integer type for most purposes - including support for >> literals and std::cout. Consider it a challenge to test your C++ knowledge. >> >>> >>> int128 a := 170'141'183'460'469'231'731'687'303'715'884'105'727 >>> >>> println a >>> println a:"hs'" >>> println word128.maxvalue # (ie. uint128) >>> >>> Output is: >>> >>> 170141183460469231731687303715884105727 >>> 7fff'ffff'ffff'ffff'ffff'ffff'ffff'ffff >>> 340282366920938463463374607431768211455 >>> >>> What exactly is the problem with allowing 128-bit constants at least? >>> >>> (My implementation is by no means complete (eg. 128/128 is missing, it >>> does 128/64), but it can do most of the basics and I just need to get >>> around to filling in the gaps. >>> >>> It will also have arbitrary precision decimal integers /and/ floats >>> (another thing that was mentioned as missing from core C++), which I'm >>> working on this month. That will have constant and output support too: >>> >>> a := 123.456e1000'000L >>> println a >>> >>> So mere 128-bit integer-only support is trivial!) >> >> Arbitrary precision arithmetic is, I think, a lot more useful than >> 128-bit integers. But it would be well outside the scope of C. It >> would be more reasonable to implement them it in a C++ library, but it >> is questionable whether it makes sense for the standard library. After >> all, there are many ways to implement arbitrary precision arithmetic >> with significantly different trade-offs in terms of speed, run-time >> memory efficiency, code space efficiency, and how these match with the >> type of usage you want for them. > > > Trivially, arbitrary precision arithmetic is more useful than 128-bit > integers, in that the format can do everything the latter can do, and > more. > > On the other hand, a proper bignum library will almost always carry a > substantial performance penalty compared to fixed 128-bit integers. > Consider that on x86-64 a typical add/subtract/compare reduces to two > instructions (ignoring data movement), and a multiply to about three > multiplies and two adds (division being the usual PITA). > > On the third hand, 128-bit integers allow a number of things that > 64-bit integers don't - a useful type in which to perform currency > calculations, usefully wide (and precise) times, and the like. > > Personally I think both 128-bit types and arbitrary precision > arithmetic should be part of the language (whether in the language > proper or the library). > I would not object to C/C++ supporting a standard bignum lib.
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2019-12-16 11:56 -0800 |
| Message-ID | <fdfa2553-96b6-411f-9f87-5f22ea890ab9@googlegroups.com> |
| In reply to | #70506 |
On Monday, December 16, 2019 at 10:21:36 AM UTC-5, David Brown wrote: > > With C++, it would not be difficult to put together a class that acts > like a 128-bit integer type for most purposes - including support for > literals and std::cout. Consider it a challenge to test your C++ knowledge. > That's one perspective, that of a lone C++ developer or team solving a particular problem, with the tools at hand, using a home wrapped 128-bit integer type here, some gcc extension there, and so on. Reading David's posts, it often sounds like that is all of C++. But it's not, that's only part of C++, and may not be the most important part. Generally speaking, open source libraries have come to provide the missing features in the C++ standard, some supported by vendors such as Microsoft and Google, some by individuals, and of course boost. Lord knows, the supply of free software, even of a very high quality, vastly exceeds the demand. The ability of open source to provide clean API's, though, depends on the coverage of basic types that are standard. There is no point, for example, for a database vendor to ship an API with a custom big decimal class. Consequently, most C++ API's have to be content with binding things like big integers and big decimals and big floats and int128 to strings, and leave it up to the user to convert the strings into some extension type supplied by their compiler, or some other things. Contrast that with practically all other modern languages with richer type systems, where it is straightforward to provide libraries that implement API's for standard things such as CBOR or SQL that bind directly into language types. Daniel
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-16 21:18 +0100 |
| Message-ID | <qt8ord$q2j$1@dont-email.me> |
| In reply to | #70515 |
On 16/12/2019 20:56, Daniel wrote: > On Monday, December 16, 2019 at 10:21:36 AM UTC-5, David Brown wrote: >> >> With C++, it would not be difficult to put together a class that acts >> like a 128-bit integer type for most purposes - including support for >> literals and std::cout. Consider it a challenge to test your C++ knowledge. >> > That's one perspective, that of a lone C++ developer or team solving a > particular problem, with the tools at hand, using a home wrapped 128-bit > integer type here, some gcc extension there, and so on. Reading David's posts, > it often sounds like that is all of C++. But it's not, that's only part > of C++, and may not be the most important part. Of course it is not the most important part of C++. And I think it would be nice if a 128-bit type was standardised in the C++ library so that you don't have to write your own (or use a third-party library - surely Boost has one). The point is merely that you /can/ write such a class in C++, and it will work fine as a 128-bit integer for most uses. And writing such a class can be an interesting exercise - I think it might open Bart's eyes to some of the things you can do with C++. > > Generally speaking, open source libraries have come to provide the missing > features in the C++ standard, some supported by vendors such as Microsoft and > Google, some by individuals, and of course boost. Lord knows, the supply of > free software, even of a very high quality, vastly exceeds the demand. The > ability of open source to provide clean API's, though, depends on the coverage > of basic types that are standard. There is no point, for example, for a > database vendor to ship an API with a custom big decimal class. Consequently, > most C++ API's have to be content with binding things like big integers and > big decimals and big floats and int128 to strings, and leave it up to the user > to convert the strings into some extension type supplied by their compiler, or > some other things. Contrast that with practically all other modern languages > with richer type systems, where it is straightforward to provide libraries > that implement API's for standard things such as CBOR or SQL that bind > directly into language types. > > Daniel >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-12-16 21:03 +0000 |
| Message-ID | <yiSJF.3222$Ol2.2903@fx22.am4> |
| In reply to | #70506 |
On 16/12/2019 15:21, David Brown wrote:
> On 16/12/2019 13:10, Bart wrote:
>> You mean that even when int128 types are built-in, there is no support
>> for 128-bit constants? And presumably not for output either, according
>> to my tests with gcc and g++:
>>
>> __int128_t a;
>> a=170141183460469231731687303715884105727;
>> std::cout << a;
>>
>> The constant overflows, and if I skip that part, I get pages of errors
>> when trying to print it. On gcc, I have no idea what printf format to use.
>>
>
> There is no printf support for 128-bit integers, except for systems
> where "long long" is 128-bit. (Or, hypothetically, 128-bit "long",
> "int", "short" or "char".) As you know full well, gcc does not have
> printf, since gcc is a compiler and printf is from the standard library.
So? printf is supposed to reflect the available primitive types. If a
compiler is extended to 128 buts, then printf should support that too.
How it does that is not the concern of the programmer.
(However printf currently doesn't even directly support int64_t, so
don't hold your breath for int128.)
>> This is frankly astonishing with such a big and important language, and
>> with comprehensive compilers such as gcc and g++. Even my own 'toy'
>> language can do this:
>
> It is only astonishing if you don't understand what it means for a
> language to have a standard. It's easy to do this with a toy language
> (and that is an advantage of toy languages). It would not be
> particularly difficult for the gcc or clang developers to support it
> either. But the ecosystem around C is huge - you can't change the
> standard in a way that breaks compatibility, which is what would have to
> happen to make these types full integer types.
What exactly would be the problem in supporting an integer constant
bigger than 2**64-1? This part is inside the compiler not the library,
so if a type bigger than 2**64-1 exists, then the constant can be of
that type.
> I am not convinced that there is any great reason for having full
> support for 128-bit types here - how often do you really need them?
A few weeks ago there was a thread on clc that made use of 128-bit
numbers to create perfect hashes of words in a dictionary. And the
longest word in the dictionary, with the correct ordering of prime
numbers, would just fit into 128 bits.
Anyway, there seems to have long been a tradition in programming
languages with a word-sized integer type, to also provide a
double-word-sized too.
So 32-bit ints were available on 16-bit hardware; and 64-bit on 32-bit
machines. Since most machines now are 64-bit (other than your specialist
processors), why not have a 128-bit type? Even my rubbish compiler can
turn this:
int128 a,b,c
a := b+c
into (Dn are 64-bit registers):
mov D0, [b]
mov D1, [b+8]
mov D2, [c]
mov D3, [c+8]
add D0, D2
adc D1, D3
mov [a], D0
mov [a+8], D1
> There are plenty of use-cases for big integers, such as in cryptography,
> but then 128-bit is not nearly big enough. And for situations where
> 128-bit integers are useful, how often do you need literals of that size?
That would be like creating an arbitrary precision library without
having a way to write arbitrarily long constants. They can occur either
in input data (needing support via scanf, atol etc) or in code or {...}
data generated by machine.
Doing it via string conversions is crass.
>> So mere 128-bit integer-only support is trivial!)
> Arbitrary precision arithmetic is, I think, a lot more useful than
> 128-bit integers.
As I think Robert mentioned, it can have considerably more overheads,
especially mine. So a:=b+c might involve executing many hundreds of
instructions involving function calls, loops, and memory allocation;
compare with the code above.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-17 00:04 +0100 |
| Message-ID | <qt92hk$p2g$1@dont-email.me> |
| In reply to | #70521 |
On 16/12/2019 22:03, Bart wrote:
> On 16/12/2019 15:21, David Brown wrote:
>> On 16/12/2019 13:10, Bart wrote:
>
>>> You mean that even when int128 types are built-in, there is no support
>>> for 128-bit constants? And presumably not for output either, according
>>> to my tests with gcc and g++:
>>>
>>> __int128_t a;
>>> a=170141183460469231731687303715884105727;
>>> std::cout << a;
>>>
>>> The constant overflows, and if I skip that part, I get pages of errors
>>> when trying to print it. On gcc, I have no idea what printf format to
>>> use.
>>>
>>
>> There is no printf support for 128-bit integers, except for systems
>> where "long long" is 128-bit. (Or, hypothetically, 128-bit "long",
>> "int", "short" or "char".) As you know full well, gcc does not have
>> printf, since gcc is a compiler and printf is from the standard library.
>
> So? printf is supposed to reflect the available primitive types. If a
> compiler is extended to 128 buts, then printf should support that too.
> How it does that is not the concern of the programmer.
The C standards form the contract. A C compiler supports a given C
standard, and a C library supports the given C standard. (A compiler
and library can also be designed together and made to support each
other.) If you have a C compiler that conforms to a standard and a C
library that conforms to a standard, then together they form a C
implementation for that standard. The same applies to C++.
It is entirely possible for one part of this to support features that
are not supported by the other. If these are extensions, not required
by the standards, then that's fine.
And printf - according to its definition in the standard - does not have
any support for integer sizes bigger than "intmax_t" as defined by the
implementation (generally, by the ABI for the platform). It doesn't
matter if the compiler has support for other types - the standard printf
does not support them.
>
> (However printf currently doesn't even directly support int64_t, so
> don't hold your breath for int128.)
Any conforming C99 printf will support "long long int", which is at
least 64 bits (and generally exactly 64 bits). You can't blame the
compiler just because /you/ happen to use it with an outdated and
non-conforming library. Anyone who uses gcc as part of a conforming
implementation has printf that supports int64_t.
(This discussion was somewhat interesting the first couple of times it
came up - it must have been explained to you a dozen times or more.)
>
>>> This is frankly astonishing with such a big and important language, and
>>> with comprehensive compilers such as gcc and g++. Even my own 'toy'
>>> language can do this:
>>
>> It is only astonishing if you don't understand what it means for a
>> language to have a standard. It's easy to do this with a toy language
>> (and that is an advantage of toy languages). It would not be
>> particularly difficult for the gcc or clang developers to support it
>> either. But the ecosystem around C is huge - you can't change the
>> standard in a way that breaks compatibility, which is what would have to
>> happen to make these types full integer types.
>
> What exactly would be the problem in supporting an integer constant
> bigger than 2**64-1? This part is inside the compiler not the library,
> so if a type bigger than 2**64-1 exists, then the constant can be of
> that type.
I don't think the size of the constants itself is an issue. The problem
is that you can't have a fully supported integer type bigger than
maxint_t in C, and maxint_t is constrained by the ABI for the platform.
>
>> I am not convinced that there is any great reason for having full
>> support for 128-bit types here - how often do you really need them?
>
> A few weeks ago there was a thread on clc that made use of 128-bit
> numbers to create perfect hashes of words in a dictionary. And the
> longest word in the dictionary, with the correct ordering of prime
> numbers, would just fit into 128 bits.
You don't mean "perfect hash" here - you mean "hash". "Perfect hash
function" has a specific meaning.
128-bit hashes are, in general, pointless. They are far bigger than
necessary to avoid a realistic possibility of an accidental clash, and
far too small to avoid intentional clashes.
Of course it is possible to find uses of 128-bit integers - especially
for obscure and artificial problems like that thread. I did not suggest
they were never useful - I am suggesting they are /rarely/ useful. And
I am suggesting that it is even rarer that there would be need for
/full/ support for such types. I didn't follow the thread in question,
but I doubt if it needed constants of 128 bit length, or printf support
for them, or support for abs, div, or other integer-related functions in
the C standard library. (Since it was a C discussion, I assume it
didn't need any integer functions from the C++ library.)
>
> Anyway, there seems to have long been a tradition in programming
> languages with a word-sized integer type, to also provide a
> double-word-sized too.
>
> So 32-bit ints were available on 16-bit hardware; and 64-bit on 32-bit
> machines. Since most machines now are 64-bit (other than your specialist
> processors), why not have a 128-bit type? Even my rubbish compiler can
> turn this:
>
> int128 a,b,c
> a := b+c
>
> into (Dn are 64-bit registers):
>
> mov D0, [b]
> mov D1, [b+8]
> mov D2, [c]
> mov D3, [c+8]
> add D0, D2
> adc D1, D3
> mov [a], D0
> mov [a+8], D1
>
>
>> There are plenty of use-cases for big integers, such as in cryptography,
>> but then 128-bit is not nearly big enough. And for situations where
>> 128-bit integers are useful, how often do you need literals of that size?
>
> That would be like creating an arbitrary precision library without
> having a way to write arbitrarily long constants. They can occur either
> in input data (needing support via scanf, atol etc) or in code or {...}
> data generated by machine.
>
> Doing it via string conversions is crass.
>
>>> So mere 128-bit integer-only support is trivial!)
>
>> Arbitrary precision arithmetic is, I think, a lot more useful than
>> 128-bit integers.
>
> As I think Robert mentioned, it can have considerably more overheads,
> especially mine. So a:=b+c might involve executing many hundreds of
> instructions involving function calls, loops, and memory allocation;
> compare with the code above.
>
Of course arbitrary precision arithmetic involves more work. But that's
what you need for things like public key cryptography. I am not
suggestion that you should use arbitrary precision arithmetic to handle
128 bit numbers - I am saying that it is rare that you need something
bigger than 64-bit but will be satisfied with 128-bit.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-12-17 01:06 +0000 |
| Message-ID | <wSVJF.63254$8X5.31675@fx08.am4> |
| In reply to | #70506 |
On 16/12/2019 15:21, David Brown wrote:
> On 16/12/2019 13:10, Bart wrote:
>> But this would be just a natural extension? I assume that whatever that
>> means, there is already X(uint64_t). There is not a totally new feature
>> or concept to add.
>>
>
> <https://en.cppreference.com/w/cpp/language/user_literal>
I didn't follow most of that (C++ has a knack of making what should be
simple things, complicated). But I did recognise these examples:
"1-4) user-defined integer literals, such as 12_km"
"5-6) user-defined floating-point literals, such as 0.5_Pa"
"double x = 90.0_deg;"
These are numeric suffixes like the ones I first introduced around 30
years ago. However I managed to do it without needing the "_"; just a space:
5 km
6 m
7 mm
(These ones represented 5000000.0, 6000.0 and 7.0. Actually, at the time
I didn't even need the space, and could write 5mm, but know I require it.)
This was achieved without the km, m, mm etc infringing on any other
name-spaces (they can still be used as identifiers).
The degree one could also be written as:
90°
In my scheme, these were just suffixes for numeric constants that
applied a scale-factor; they didn't result in any new user-type, or
prevent units being mixed (a full treatment requires a language like
Frink (frinklang.org)).
Creating true new literal types for user-defined types, even if limited
to numeric types, is difficult. But probably not as difficult as that
C++ link is making it.
[toc] | [prev] | [next] | [standalone]
Page 14 of 16 — ← Prev page 1 … 12 13 [14] 15 16 Next page →
Back to top | Article view | comp.lang.c++
csiph-web