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 15 of 16 — ← Prev page 1 … 13 14 [15] 16 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-17 14:51 +0100 |
| Message-ID | <qtamg9$pll$1@dont-email.me> |
| In reply to | #70525 |
On 17/12/2019 02:06, Bart wrote: > 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;" The real benefit of these is when you can write: distance x = 2210_m; distance y = 3_km; time t = 300_sec; and then you c compile-time error when you try: speed v = (x + t) + y; but are allowed to write: seed v = (x + y) / t; > > 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° Unicode symbols sound nice, until you have to distinguish between 90° and 90˚ or 90⁰, or between 90℃ and 90°C. And it looks great being able to write π = 3.14 and y = x², until the next programmer is using Windows instead of *nix and can't type those symbols without a character map applet. > > 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. Nah, it's easy in C++. And it's the user-defined types that are the real feature here. Otherwise, it's almost nothing more than you could have in C with: #define km *1000.0 #define m *1.0 #define mm *0.001 double x = 5 km; double y = 5 mm; Your language apparently lets you make these context sensitive in some way, which is nice.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-12-16 07:25 -0500 |
| Message-ID | <qt7t3h$a2l$1@dont-email.me> |
| In reply to | #70496 |
On 12/16/19 3:44 AM, David Brown wrote: ... > 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. The fundamental problem is that people didn't want to implement [u]intmax_t as intended: the largest supported integer type, a type that must necessarily change every time that the list of supported integer types expands to include a larger type. Instead, for some reason, they wanted to use it as a synonym for int64_t. Why they didn't use int64_t as the type for such interfaces, I don't know. This was in fact predicted before the proposal to add [u]intmax_t to the C standard was approved: someone (I think it was Doug Gwynn) predicted that someday we would need to add something like really_really_max_int_type_this_time_we_really_mean_it - and then people would get into the habit of assuming that really_really_max_int_type_this_time_we_really_mean_it was just a synonym for int128_t, and they'd have to do it all over again. I suspect he's right.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2019-12-16 14:13 +0100 |
| Message-ID | <h5pe7aF92deU1@mid.individual.net> |
| In reply to | #70503 |
On 2019-12-16 at 13:25, James Kuyper wrote:
> On 12/16/19 3:44 AM, David Brown wrote:
> ...
>> 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.
>
> The fundamental problem is that people didn't want to implement
> [u]intmax_t as intended: the largest supported integer type, a type that
> must necessarily change every time that the list of supported integer
> types expands to include a larger type. Instead, for some reason, they
> wanted to use it as a synonym for int64_t. Why they didn't use int64_t
> as the type for such interfaces, I don't know.
When C was first standardized we still had some mainframes that used
36-bit ones' complement. On those intmax_t could be 72-bits and int64_t
was just not available.
> This was in fact
> predicted before the proposal to add [u]intmax_t to the C standard was
> approved: someone (I think it was Doug Gwynn) predicted that someday we
> would need to add something like
> really_really_max_int_type_this_time_we_really_mean_it - and then people
> would get into the habit of assuming that
> really_really_max_int_type_this_time_we_really_mean_it was just a
> synonym for int128_t, and they'd have to do it all over again. I suspect
> he's right.
>
We never learn, of course. :-)
Bo Persson
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-16 16:32 +0100 |
| Message-ID | <qt8824$coh$1@dont-email.me> |
| In reply to | #70503 |
On 16/12/2019 13:25, James Kuyper wrote: > On 12/16/19 3:44 AM, David Brown wrote: > ... >> 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. > > The fundamental problem is that people didn't want to implement > [u]intmax_t as intended: the largest supported integer type, a type that > must necessarily change every time that the list of supported integer > types expands to include a larger type. Instead, for some reason, they > wanted to use it as a synonym for int64_t. Why they didn't use int64_t > as the type for such interfaces, I don't know. This was in fact > predicted before the proposal to add [u]intmax_t to the C standard was > approved: someone (I think it was Doug Gwynn) predicted that someday we > would need to add something like > really_really_max_int_type_this_time_we_really_mean_it - and then people > would get into the habit of assuming that > really_really_max_int_type_this_time_we_really_mean_it was just a > synonym for int128_t, and they'd have to do it all over again. I suspect > he's right. > I suspect that at the time, no one really thought about the possibility of 128-bit integers. After all, 64-bit integers were new, and 64 bits should be enough for anybody! Personally, I think the whole "intmax_t" concept was a mistake. But it's easier to see that kind of thing afterwards. "intmax_t" is defined (roughly) as being the biggest integer type. I wonder if the definition could be changed in the standards to apply only to being the biggest /standard/ integer type? That would leave the door open for /extended/ integer types that are larger. As far as I have know, compilers that actually implement extended integer types are rare or non-existent, so this could be done without breaking existing code or tools.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2019-12-16 10:52 -0800 |
| Message-ID | <871rt4w1b4.fsf@nosuchdomain.example.com> |
| In reply to | #70507 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Personally, I think the whole "intmax_t" concept was a mistake. But
> it's easier to see that kind of thing afterwards.
[...]
Personally, I think intmax_t is useful (perhaps more in C than in C++).
For example:
some_integer_type x = some_value;
printf("x = %jd\n", (intmax_t)x);
The zoo of ugly format macros in <cinttypes> doesn't cover all
possible cases.
Of course in C++ you can just write:
std::cout << "x = " << x << "\n";
--
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-16 21:24 +0100 |
| Message-ID | <qt8p6h$sd4$1@dont-email.me> |
| In reply to | #70512 |
On 16/12/2019 19:52, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> Personally, I think the whole "intmax_t" concept was a mistake. But
>> it's easier to see that kind of thing afterwards.
> [...]
>
> Personally, I think intmax_t is useful (perhaps more in C than in C++).
> For example:
>
> some_integer_type x = some_value;
> printf("x = %jd\n", (intmax_t)x);
>
Fair enough. In my coding, I invariably know the sizes I am dealing
with (and I usually use the <stdint.h> or <cstdint> types). So it is
good to hear the opinions of people who do other kinds of programming.
> The zoo of ugly format macros in <cinttypes> doesn't cover all
> possible cases.
>
Indeed.
> Of course in C++ you can just write:
>
> std::cout << "x = " << x << "\n";
>
Yes.
In C, you can use _Generic to handle this, but it is not as easily
extended as std::cout.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-16 10:56 -0800 |
| Message-ID | <7f14cd0b-d1d8-4872-ac4a-a38fd6e15de8@googlegroups.com> |
| In reply to | #70507 |
On Monday, 16 December 2019 17:32:34 UTC+2, David Brown wrote: > On 16/12/2019 13:25, James Kuyper wrote: > > On 12/16/19 3:44 AM, David Brown wrote: > > ... > >> 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. > > > > The fundamental problem is that people didn't want to implement > > [u]intmax_t as intended: the largest supported integer type, a type that > > must necessarily change every time that the list of supported integer > > types expands to include a larger type. Instead, for some reason, they > > wanted to use it as a synonym for int64_t. Why they didn't use int64_t > > as the type for such interfaces, I don't know. This was in fact > > predicted before the proposal to add [u]intmax_t to the C standard was > > approved: someone (I think it was Doug Gwynn) predicted that someday we > > would need to add something like > > really_really_max_int_type_this_time_we_really_mean_it - and then people > > would get into the habit of assuming that > > really_really_max_int_type_this_time_we_really_mean_it was just a > > synonym for int128_t, and they'd have to do it all over again. I suspect > > he's right. > > > > I suspect that at the time, no one really thought about the possibility > of 128-bit integers. After all, 64-bit integers were new, and 64 bits > should be enough for anybody! > > Personally, I think the whole "intmax_t" concept was a mistake. But > it's easier to see that kind of thing afterwards. Sure it was, it did not take into account how dimwittedly shortshighted humans (even most bright engineers) are forever. > "intmax_t" is defined (roughly) as being the biggest integer type. I > wonder if the definition could be changed in the standards to apply only > to being the biggest /standard/ integer type? That would leave the door > open for /extended/ integer types that are larger. As far as I have > know, compilers that actually implement extended integer types are rare > or non-existent, so this could be done without breaking existing code or > tools. Non-existent at least on case of C++.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-12-16 20:45 +0000 |
| Message-ID | <87v9qgvw28.fsf@bsb.me.uk> |
| In reply to | #70507 |
David Brown <david.brown@hesbynett.no> writes:
> On 16/12/2019 13:25, James Kuyper wrote:
>> On 12/16/19 3:44 AM, David Brown wrote:
>> ...
>>> 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.
>>
>> The fundamental problem is that people didn't want to implement
>> [u]intmax_t as intended: the largest supported integer type, a type that
>> must necessarily change every time that the list of supported integer
>> types expands to include a larger type. Instead, for some reason, they
>> wanted to use it as a synonym for int64_t. Why they didn't use int64_t
>> as the type for such interfaces, I don't know. This was in fact
>> predicted before the proposal to add [u]intmax_t to the C standard was
>> approved: someone (I think it was Doug Gwynn) predicted that someday we
>> would need to add something like
>> really_really_max_int_type_this_time_we_really_mean_it - and then people
>> would get into the habit of assuming that
>> really_really_max_int_type_this_time_we_really_mean_it was just a
>> synonym for int128_t, and they'd have to do it all over again. I suspect
>> he's right.
>>
>
> I suspect that at the time, no one really thought about the possibility
> of 128-bit integers. After all, 64-bit integers were new, and 64 bits
> should be enough for anybody!
>
> Personally, I think the whole "intmax_t" concept was a mistake. But
> it's easier to see that kind of thing afterwards.
I disagree. See below for at least one reason.
> "intmax_t" is defined (roughly) as being the biggest integer type. I
> wonder if the definition could be changed in the standards to apply only
> to being the biggest /standard/ integer type? That would leave the door
> open for /extended/ integer types that are larger. As far as I have
> know, compilers that actually implement extended integer types are rare
> or non-existent, so this could be done without breaking existing code or
> tools.
This puzzles me. gcc (I am talking mainly about C here as I don't know
the C++ standard well enough) implements extended integer types (like
__int128) but not in conforming mode because that would entail making
intmax_t 128 bits wide. Did you intend a rather narrower remark that
compilers that implement extended integer types in conforming mode are
rare or non-existent?
intmax_t is useful, in part because it solves the printf problem. You
can portably print any integer i using
printf("%ld\n", (intmax_t)i);
whether i is an extended type like __int128 or even some weird 99-bit
integer type.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-16 22:00 +0100 |
| Message-ID | <qt8r9o$a9i$1@dont-email.me> |
| In reply to | #70519 |
On 16/12/2019 21:45, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 16/12/2019 13:25, James Kuyper wrote:
>>> On 12/16/19 3:44 AM, David Brown wrote:
>>> ...
>>>> 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.
>>>
>>> The fundamental problem is that people didn't want to implement
>>> [u]intmax_t as intended: the largest supported integer type, a type that
>>> must necessarily change every time that the list of supported integer
>>> types expands to include a larger type. Instead, for some reason, they
>>> wanted to use it as a synonym for int64_t. Why they didn't use int64_t
>>> as the type for such interfaces, I don't know. This was in fact
>>> predicted before the proposal to add [u]intmax_t to the C standard was
>>> approved: someone (I think it was Doug Gwynn) predicted that someday we
>>> would need to add something like
>>> really_really_max_int_type_this_time_we_really_mean_it - and then people
>>> would get into the habit of assuming that
>>> really_really_max_int_type_this_time_we_really_mean_it was just a
>>> synonym for int128_t, and they'd have to do it all over again. I suspect
>>> he's right.
>>>
>>
>> I suspect that at the time, no one really thought about the possibility
>> of 128-bit integers. After all, 64-bit integers were new, and 64 bits
>> should be enough for anybody!
>>
>> Personally, I think the whole "intmax_t" concept was a mistake. But
>> it's easier to see that kind of thing afterwards.
>
> I disagree. See below for at least one reason.
>
>> "intmax_t" is defined (roughly) as being the biggest integer type. I
>> wonder if the definition could be changed in the standards to apply only
>> to being the biggest /standard/ integer type? That would leave the door
>> open for /extended/ integer types that are larger. As far as I have
>> know, compilers that actually implement extended integer types are rare
>> or non-existent, so this could be done without breaking existing code or
>> tools.
>
> This puzzles me. gcc (I am talking mainly about C here as I don't know
> the C++ standard well enough) implements extended integer types (like
> __int128) but not in conforming mode because that would entail making
> intmax_t 128 bits wide. Did you intend a rather narrower remark that
> compilers that implement extended integer types in conforming mode are
> rare or non-existent?
>
gcc supports 128-bit types even with "-std=c11 -pedantic" (or other C or
C++ standards), but requires "__extension__" to avoid a warning:
__extension__ typedef __int128 int128;
int foo(void) {
return sizeof(int128);
}
__int128 is a gcc extension, and is treated as an "integer scalar type",
but it is /not/ an "extended integer type" as defined by the C
standards. That applies whether you are in conforming modes or not.
<https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html>
"""
GCC does not support any extended integer types.
"""
> intmax_t is useful, in part because it solves the printf problem. You
> can portably print any integer i using
>
> printf("%ld\n", (intmax_t)i);
>
> whether i is an extended type like __int128 or even some weird 99-bit
> integer type.
>
Yes, Keith mentioned that use, which I had not thought about (it's not
something that turns up in my kind of coding).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-12-17 04:07 +0000 |
| Message-ID | <878snbwq5h.fsf@bsb.me.uk> |
| In reply to | #70520 |
David Brown <david.brown@hesbynett.no> writes:
> On 16/12/2019 21:45, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 16/12/2019 13:25, James Kuyper wrote:
>>>> On 12/16/19 3:44 AM, David Brown wrote:
>>>> ...
>>>>> 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.
>>>>
>>>> The fundamental problem is that people didn't want to implement
>>>> [u]intmax_t as intended: the largest supported integer type, a type that
>>>> must necessarily change every time that the list of supported integer
>>>> types expands to include a larger type. Instead, for some reason, they
>>>> wanted to use it as a synonym for int64_t. Why they didn't use int64_t
>>>> as the type for such interfaces, I don't know. This was in fact
>>>> predicted before the proposal to add [u]intmax_t to the C standard was
>>>> approved: someone (I think it was Doug Gwynn) predicted that someday we
>>>> would need to add something like
>>>> really_really_max_int_type_this_time_we_really_mean_it - and then people
>>>> would get into the habit of assuming that
>>>> really_really_max_int_type_this_time_we_really_mean_it was just a
>>>> synonym for int128_t, and they'd have to do it all over again. I suspect
>>>> he's right.
>>>>
>>>
>>> I suspect that at the time, no one really thought about the possibility
>>> of 128-bit integers. After all, 64-bit integers were new, and 64 bits
>>> should be enough for anybody!
>>>
>>> Personally, I think the whole "intmax_t" concept was a mistake. But
>>> it's easier to see that kind of thing afterwards.
>>
>> I disagree. See below for at least one reason.
>>
>>> "intmax_t" is defined (roughly) as being the biggest integer type. I
>>> wonder if the definition could be changed in the standards to apply only
>>> to being the biggest /standard/ integer type? That would leave the door
>>> open for /extended/ integer types that are larger. As far as I have
>>> know, compilers that actually implement extey srnded integer types are rare
>>> or non-existent, so this could be done without breaking existing code or
>>> tools.
>>
>> This puzzles me. gcc (I am talking mainly about C here as I don't know
>> the C++ standard well enough) implements extended integer types (like
>> __int128) but not in conforming mode because that would entail making
>> intmax_t 128 bits wide. Did you intend a rather narrower remark that
>> compilers that implement extended integer types in conforming mode are
>> rare or non-existent?
>>
>
> gcc supports 128-bit types even with "-std=c11 -pedantic" (or other C
> or C++ standards), but requires "__extension__" to avoid a warning:
>
> __extension__ typedef __int128 int128;
Right, but that amounts to something very similar. It's not standard C.
> int foo(void) {
> return sizeof(int128);
> }
>
>
> __int128 is a gcc extension, and is treated as an "integer scalar
> type", but it is /not/ an "extended integer type" as defined by the C
> standards. That applies whether you are in conforming modes or not.
If you need __extension__ or a non-conforming mode I don't see that it
matters what gcc calls it.
Is it your contention that gcc /could/ provide __int128 in conforming
mode (with no extra syntax) and, just by declaring it so, not have it be
considered and extended integer type? You may be right about that, but
then what is the __extension__ there for? gcc could do without it,
declare __int128 not an extended type, and all would be fine.
> <https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html>
> """
> GCC does not support any extended integer types.
> """
I can see how they can say that! There are none in conforming mode
without a special extension, and in other modes the language is not C so
that can say anything they like about it! In that sense I was wrong to
say that gcc "implements extended integer types but not in conforming
mode". In non-C mode everything it's up to the gcc authors to say what
these types are called.
>> intmax_t is useful, in part because it solves the printf problem. You
>> can portably print any integer i using
>>
>> printf("%ld\n", (intmax_t)i);
>>
>> whether i is an extended type like __int128 or even some weird 99-bit
>> integer type.
>>
>
> Yes, Keith mentioned that use, which I had not thought about (it's not
> something that turns up in my kind of coding).
Yes, noise on my part because I'd not refreshed the thread before
replying.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-17 15:00 +0100 |
| Message-ID | <qtan22$t3o$1@dont-email.me> |
| In reply to | #70529 |
On 17/12/2019 05:07, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 16/12/2019 21:45, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 16/12/2019 13:25, James Kuyper wrote:
>>>>> On 12/16/19 3:44 AM, David Brown wrote:
>>>>> ...
>>>>>> 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.
>>>>>
>>>>> The fundamental problem is that people didn't want to implement
>>>>> [u]intmax_t as intended: the largest supported integer type, a type that
>>>>> must necessarily change every time that the list of supported integer
>>>>> types expands to include a larger type. Instead, for some reason, they
>>>>> wanted to use it as a synonym for int64_t. Why they didn't use int64_t
>>>>> as the type for such interfaces, I don't know. This was in fact
>>>>> predicted before the proposal to add [u]intmax_t to the C standard was
>>>>> approved: someone (I think it was Doug Gwynn) predicted that someday we
>>>>> would need to add something like
>>>>> really_really_max_int_type_this_time_we_really_mean_it - and then people
>>>>> would get into the habit of assuming that
>>>>> really_really_max_int_type_this_time_we_really_mean_it was just a
>>>>> synonym for int128_t, and they'd have to do it all over again. I suspect
>>>>> he's right.
>>>>>
>>>>
>>>> I suspect that at the time, no one really thought about the possibility
>>>> of 128-bit integers. After all, 64-bit integers were new, and 64 bits
>>>> should be enough for anybody!
>>>>
>>>> Personally, I think the whole "intmax_t" concept was a mistake. But
>>>> it's easier to see that kind of thing afterwards.
>>>
>>> I disagree. See below for at least one reason.
>>>
>>>> "intmax_t" is defined (roughly) as being the biggest integer type. I
>>>> wonder if the definition could be changed in the standards to apply only
>>>> to being the biggest /standard/ integer type? That would leave the door
>>>> open for /extended/ integer types that are larger. As far as I have
>>>> know, compilers that actually implement extey srnded integer types are rare
>>>> or non-existent, so this could be done without breaking existing code or
>>>> tools.
>>>
>>> This puzzles me. gcc (I am talking mainly about C here as I don't know
>>> the C++ standard well enough) implements extended integer types (like
>>> __int128) but not in conforming mode because that would entail making
>>> intmax_t 128 bits wide. Did you intend a rather narrower remark that
>>> compilers that implement extended integer types in conforming mode are
>>> rare or non-existent?
>>>
>>
>> gcc supports 128-bit types even with "-std=c11 -pedantic" (or other C
>> or C++ standards), but requires "__extension__" to avoid a warning:
>>
>> __extension__ typedef __int128 int128;
>
> Right, but that amounts to something very similar. It's not standard C.
>
>> int foo(void) {
>> return sizeof(int128);
>> }
>>
>>
>> __int128 is a gcc extension, and is treated as an "integer scalar
>> type", but it is /not/ an "extended integer type" as defined by the C
>> standards. That applies whether you are in conforming modes or not.
>
> If you need __extension__ or a non-conforming mode I don't see that it
> matters what gcc calls it.
>
It doesn't really matter what /we/ call it - it matters what /gcc/ calls
it. And they say it is not an extended integer type, regardless of the
compiler flags, precisely because they can't have an extended integer
type that is bigger than maxint_t.
> Is it your contention that gcc /could/ provide __int128 in conforming
> mode (with no extra syntax) and, just by declaring it so, not have it be
> considered and extended integer type?
Yes.
__int128 is in a reserved namespace - they can put whatever types they
want there, even in conforming modes. They can't make an "extended
integer type" that is bigger than maxint_t while remaining conforming,
and it would be ridiculous to say it is an extended integer type with
"-std=gnu11" and a different name (but identical functionality) with
"-std=c11".
It is an implementation-specific type that handles 128-bit integers, but
it is not an "integer type" as defined by the C standards.
> You may be right about that, but
> then what is the __extension__ there for? gcc could do without it,
> declare __int128 not an extended type, and all would be fine.
It could, yes. You only need the "__extension__" marker if you are
specifying "-pedantic", and even then it is just to avoid getting a
warning. __int128 is supported in the most standards-compliant and
pedantic warning modes gcc has. But the "-pedantic" warnings don't just
ensure that gcc emits all required diagnostics, it also gives warnings
on gcc extensions that would limit portability another compilers.
"__extensions__" tells the compiler that you know this thing is a gcc
extension, and you know you asked for warnings about gcc-specific
features, but you want to hide the warning in this particular case.
>
>> <https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html>
>> """
>> GCC does not support any extended integer types.
>> """
>
> I can see how they can say that! There are none in conforming mode
> without a special extension, and in other modes the language is not C so
> that can say anything they like about it! In that sense I was wrong to
> say that gcc "implements extended integer types but not in conforming
> mode". In non-C mode everything it's up to the gcc authors to say what
> these types are called.
>
>>> intmax_t is useful, in part because it solves the printf problem. You
>>> can portably print any integer i using
>>>
>>> printf("%ld\n", (intmax_t)i);
>>>
>>> whether i is an extended type like __int128 or even some weird 99-bit
>>> integer type.
>>>
>>
>> Yes, Keith mentioned that use, which I had not thought about (it's not
>> something that turns up in my kind of coding).
>
> Yes, noise on my part because I'd not refreshed the thread before
> replying.
>
No problem - it is useful to know that such uses are not just a
peculiarity of a single person.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-12-17 14:44 +0000 |
| Message-ID | <87r213ui3i.fsf@bsb.me.uk> |
| In reply to | #70541 |
David Brown <david.brown@hesbynett.no> writes:
> On 17/12/2019 05:07, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 16/12/2019 21:45, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
<cut>
>>>>> "intmax_t" is defined (roughly) as being the biggest integer type. I
>>>>> wonder if the definition could be changed in the standards to apply only
>>>>> to being the biggest /standard/ integer type? That would leave the door
>>>>> open for /extended/ integer types that are larger. As far as I have
>>>>> know, compilers that actually implement extey srnded integer types are rare
>>>>> or non-existent, so this could be done without breaking existing code or
>>>>> tools.
>>>>
>>>> This puzzles me. gcc (I am talking mainly about C here as I don't know
>>>> the C++ standard well enough) implements extended integer types (like
>>>> __int128) but not in conforming mode because that would entail making
>>>> intmax_t 128 bits wide. Did you intend a rather narrower remark that
>>>> compilers that implement extended integer types in conforming mode are
>>>> rare or non-existent?
>>>>
>>>
>>> gcc supports 128-bit types even with "-std=c11 -pedantic" (or other C
>>> or C++ standards), but requires "__extension__" to avoid a warning:
>>>
>>> __extension__ typedef __int128 int128;
>>
>> Right, but that amounts to something very similar. It's not standard C.
>>
>>> int foo(void) {
>>> return sizeof(int128);
>>> }
>>>
>>>
>>> __int128 is a gcc extension, and is treated as an "integer scalar
>>> type", but it is /not/ an "extended integer type" as defined by the C
>>> standards. That applies whether you are in conforming modes or not.
>>
>> If you need __extension__ or a non-conforming mode I don't see that it
>> matters what gcc calls it.
>>
>
> It doesn't really matter what /we/ call it - it matters what /gcc/ calls
> it. And they say it is not an extended integer type, regardless of the
> compiler flags, precisely because they can't have an extended integer
> type that is bigger than maxint_t.
>
>> Is it your contention that gcc /could/ provide __int128 in conforming
>> mode (with no extra syntax) and, just by declaring it so, not have it be
>> considered and extended integer type?
>
> Yes.
>
> __int128 is in a reserved namespace - they can put whatever types they
> want there, even in conforming modes. They can't make an "extended
> integer type" that is bigger than maxint_t while remaining conforming,
> and it would be ridiculous to say it is an extended integer type with
> "-std=gnu11" and a different name (but identical functionality) with
> "-std=c11".
>
> It is an implementation-specific type that handles 128-bit integers, but
> it is not an "integer type" as defined by the C standards.
(I think you mean "signed integer type" -- the C standard does not
define the term "integer type" as far as I can see.)
The only way that it can not be a signed integer type is by a decree
from gcc. I am not saying this is wrong -- maybe that was the intent of
the committee -- but then I'm not sure why gcc uses the __extension__
keyword. Maybe, as you say below, that's all about managing diagnostics
for portability.
>> You may be right about that, but
>> then what is the __extension__ there for? gcc could do without it,
>> declare __int128 not an extended type, and all would be fine.
>
> It could, yes.
And it turns out clang decided to do just that. __int128 is there in
conforming modes, but sizeof (intmax_t) is 8. Presumably they too have
decreed that __int128 is not a signed integer type, despite meeting all
the technical requirements to be one!
<cut>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-17 15:54 +0100 |
| Message-ID | <qtaq7j$glq$1@dont-email.me> |
| In reply to | #70543 |
On 17/12/2019 15:44, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 17/12/2019 05:07, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 16/12/2019 21:45, Ben Bacarisse wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
> <cut>
>>>>>> "intmax_t" is defined (roughly) as being the biggest integer type. I
>>>>>> wonder if the definition could be changed in the standards to apply only
>>>>>> to being the biggest /standard/ integer type? That would leave the door
>>>>>> open for /extended/ integer types that are larger. As far as I have
>>>>>> know, compilers that actually implement extey srnded integer types are rare
>>>>>> or non-existent, so this could be done without breaking existing code or
>>>>>> tools.
>>>>>
>>>>> This puzzles me. gcc (I am talking mainly about C here as I don't know
>>>>> the C++ standard well enough) implements extended integer types (like
>>>>> __int128) but not in conforming mode because that would entail making
>>>>> intmax_t 128 bits wide. Did you intend a rather narrower remark that
>>>>> compilers that implement extended integer types in conforming mode are
>>>>> rare or non-existent?
>>>>>
>>>>
>>>> gcc supports 128-bit types even with "-std=c11 -pedantic" (or other C
>>>> or C++ standards), but requires "__extension__" to avoid a warning:
>>>>
>>>> __extension__ typedef __int128 int128;
>>>
>>> Right, but that amounts to something very similar. It's not standard C.
>>>
>>>> int foo(void) {
>>>> return sizeof(int128);
>>>> }
>>>>
>>>>
>>>> __int128 is a gcc extension, and is treated as an "integer scalar
>>>> type", but it is /not/ an "extended integer type" as defined by the C
>>>> standards. That applies whether you are in conforming modes or not.
>>>
>>> If you need __extension__ or a non-conforming mode I don't see that it
>>> matters what gcc calls it.
>>>
>>
>> It doesn't really matter what /we/ call it - it matters what /gcc/ calls
>> it. And they say it is not an extended integer type, regardless of the
>> compiler flags, precisely because they can't have an extended integer
>> type that is bigger than maxint_t.
>>
>>> Is it your contention that gcc /could/ provide __int128 in conforming
>>> mode (with no extra syntax) and, just by declaring it so, not have it be
>>> considered and extended integer type?
>>
>> Yes.
>>
>> __int128 is in a reserved namespace - they can put whatever types they
>> want there, even in conforming modes. They can't make an "extended
>> integer type" that is bigger than maxint_t while remaining conforming,
>> and it would be ridiculous to say it is an extended integer type with
>> "-std=gnu11" and a different name (but identical functionality) with
>> "-std=c11".
>>
>> It is an implementation-specific type that handles 128-bit integers, but
>> it is not an "integer type" as defined by the C standards.
>
> (I think you mean "signed integer type" -- the C standard does not
> define the term "integer type" as far as I can see.)
It does (C11 6.2.5p17) - "integer types" cover "char, the signed and
unsigned integer types, and the enumerated types". The "signed integer
types" covers the "standard signed integer types" and "extended signed
integer types".
>
> The only way that it can not be a signed integer type is by a decree
> from gcc. I am not saying this is wrong -- maybe that was the intent of
> the committee -- but then I'm not sure why gcc uses the __extension__
> keyword. Maybe, as you say below, that's all about managing diagnostics
> for portability.
>
>>> You may be right about that, but
>>> then what is the __extension__ there for? gcc could do without it,
>>> declare __int128 not an extended type, and all would be fine.
>>
>> It could, yes.
>
> And it turns out clang decided to do just that. __int128 is there in
> conforming modes, but sizeof (intmax_t) is 8. Presumably they too have
> decreed that __int128 is not a signed integer type, despite meeting all
> the technical requirements to be one!
>
__int128 meets almost all the technical requirements to be a signed
integer type - the only missing one is the classification, as that would
mean maxint_t would have to be (at least) 128 bits.
It is a strange situation indeed.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-12-17 15:52 +0000 |
| Message-ID | <87a77rueyj.fsf@bsb.me.uk> |
| In reply to | #70544 |
David Brown <david.brown@hesbynett.no> writes: > On 17/12/2019 15:44, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: <cut> >>> It is an implementation-specific type that handles 128-bit integers, but >>> it is not an "integer type" as defined by the C standards. >> >> (I think you mean "signed integer type" -- the C standard does not >> define the term "integer type" as far as I can see.) > > It does (C11 6.2.5p17) - "integer types" cover "char, the signed and > unsigned integer types, and the enumerated types". The "signed integer > types" covers the "standard signed integer types" and "extended signed > integer types". So it does. Thanks. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2019-12-17 11:51 -0800 |
| Message-ID | <87o8w6vihg.fsf@nosuchdomain.example.com> |
| In reply to | #70544 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> __int128 meets almost all the technical requirements to be a signed
> integer type - the only missing one is the classification, as that would
> mean maxint_t would have to be (at least) 128 bits.
It doesn't meet *all* the requirements. N1570 6.4.4.1p6 (Integer
constants):
If an integer constant cannot be represented by any type in its
list, it may have an extended integer type, if the extended integer
type can represent its value.
In gcc, there are no constants of type __int128.
(The word "may" is a bit ambiguous, and it could be argued that an
implementation isn't required to support constants of type int128_t
even if it's an extended integer type.)
--
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 22:10 +0100 |
| Message-ID | <qtbg8f$v2o$1@dont-email.me> |
| In reply to | #70549 |
On 17/12/2019 20:51, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> __int128 meets almost all the technical requirements to be a signed >> integer type - the only missing one is the classification, as that would >> mean maxint_t would have to be (at least) 128 bits. > > It doesn't meet *all* the requirements. N1570 6.4.4.1p6 (Integer > constants): > > If an integer constant cannot be represented by any type in its > list, it may have an extended integer type, if the extended integer > type can represent its value. > > In gcc, there are no constants of type __int128. > > (The word "may" is a bit ambiguous, and it could be argued that an > implementation isn't required to support constants of type int128_t > even if it's an extended integer type.) > That is how I have always read that part of the standard - I hadn't considered your reading. But I agree that your interpretation is just as valid. Certainly (based on other discussions involving gcc developers) the lack of 128-bit integer constants is viewed as one reason why __int128 is not a "full" integer type to the same degree as the other integer types. (With the maxint_t issue being another key reason, and lack of support in library functions such as printf, *abs, strto*, etc., being others.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2019-12-17 22:08 -0800 |
| Message-ID | <87fthiupx9.fsf@nosuchdomain.example.com> |
| In reply to | #70550 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Certainly (based on other discussions involving gcc developers) the
> lack of 128-bit integer constants is viewed as one reason why __int128
> is not a "full" integer type to the same degree as the other integer
> types. (With the maxint_t issue being another key reason, and lack of
> support in library functions such as printf, *abs, strto*, etc., being
> others.)
It's intmax_t, not maxint_t. (I've seen this misspelling several times
in this thread.)
--
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-18 08:56 +0100 |
| Message-ID | <qtcm48$m15$1@dont-email.me> |
| In reply to | #70553 |
On 18/12/2019 07:08, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> Certainly (based on other discussions involving gcc developers) the >> lack of 128-bit integer constants is viewed as one reason why __int128 >> is not a "full" integer type to the same degree as the other integer >> types. (With the maxint_t issue being another key reason, and lack of >> support in library functions such as printf, *abs, strto*, etc., being >> others.) > > It's intmax_t, not maxint_t. (I've seen this misspelling several times > in this thread.) > Yes, of course. It's obvious when you use it (it's an "intXXX_t" type), but it's easy to mix when typing a post. Sorry if I have caused confusion by my misspellings.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-10 08:29 -0800 |
| Message-ID | <86sgkn46mb.fsf@linuxsc.com> |
| In reply to | #70549 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>
>> __int128 meets almost all the technical requirements to be a signed
>> integer type - the only missing one is the classification, as that would
>> mean maxint_t would have to be (at least) 128 bits.
>
> It doesn't meet *all* the requirements. N1570 6.4.4.1p6 (Integer
> constants):
>
> If an integer constant cannot be represented by any type in its
> list, it may have an extended integer type, if the extended integer
> type can represent its value.
>
> In gcc, there are no constants of type __int128.
>
> (The word "may" is a bit ambiguous, and it could be argued that an
> implementation isn't required to support constants of type int128_t
> even if it's an extended integer type.)
Not really convincingly. The end of that paragrah says
If an integer constant cannot be represented by any type in
its list and has no extended integer type, then the integer
constant has no type.
I don't see any sensible way of reading those sentences together
and concluding that using an extended integer type is allowed to
be optional.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-12-17 23:55 -0500 |
| Message-ID | <qtcbge$7q9$1@dont-email.me> |
| In reply to | #70543 |
On 12/17/19 9:44 AM, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 17/12/2019 05:07, Ben Bacarisse wrote: ... >> __int128 is in a reserved namespace - they can put whatever types they >> want there, even in conforming modes. They can't make an "extended >> integer type" that is bigger than maxint_t while remaining conforming, >> and it would be ridiculous to say it is an extended integer type with >> "-std=gnu11" and a different name (but identical functionality) with >> "-std=c11". >> >> It is an implementation-specific type that handles 128-bit integers, but >> it is not an "integer type" as defined by the C standards. ... > The only way that it can not be a signed integer type is by a decree > from gcc. You say that as if you think there's something odd about it. The set of extended integer types that are supported by a given implementation is implementation-defined (3.9.1p2). _int128_t fails to be an extended integer type, despite being a type supported by gcc, because gcc has exercised it's prerogative of choosing not to define it as an extended integer type. This has some consequences: _int128_t also cannot be an integer type, since it isn't any of the other things that can be integer types (standard integer types, bool, char, char16_t, char32_t, wchar_t). It also can't be an arithmetic type, because it isn't a floating point type, the only kind of non-integer type that can be an arithmetic type (note: n4578.pdf uses the term "arithmetic type" without ever defining it - I suspect this was an oversight, and the intended definition is similar to the one provided in the C standard). It also can't be a scalar type, because it certainly doesn't qualify as an enumerated type, a pointer type, a pointer to member type, or std::nullptr_t. It can't qualify as a POD type, since it certainly isn't a POD class type or an array of POD types. Similarly, it isn't a fundamental type, a trivially-copyable type, a trivial type, or a standard-layout type, or a literal type. Therefore, when invoked in fully conforming mode, gcc must diagnose any use of _int128_t in any context where the C++ standard requires a type that is in one of those categories. When discussing the corresponding issue in comp.lang.c, I was told that gcc does in fact issue all of the diagnostics required by the C standard when using _int128_t. I would presume that it does the same when compiling in C++ mode. After issuing that diagnostic message, the behavior is undefined, so gcc is free to handle _int128_t exactly the way it would have handled it if gcc had chosen to define it as being an extended integer type. It's also free not to define intmax_t as large enough to hold all values that are representable as _int128_t.
[toc] | [prev] | [next] | [standalone]
Page 15 of 16 — ← Prev page 1 … 13 14 [15] 16 Next page →
Back to top | Article view | comp.lang.c++
csiph-web