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 10 of 16 — ← Prev page 1 … 8 9 [10] 11 12 … 16 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-06 23:17 -0500 |
| Message-ID | <qv10pc$h0l$1@dont-email.me> |
| In reply to | #71183 |
On 1/6/20 7:08 PM, Robert Wessel wrote: > On Sun, 05 Jan 2020 20:40:27 -0800, Keith Thompson > <Keith.S.Thompson+u@gmail.com> wrote: > >> Robert Wessel <robertwessel2@yahoo.com> writes: >>> On Sun, 5 Jan 2020 20:11:17 +0100, David Brown >>> <david.brown@hesbynett.no> wrote: >> [...] >>>> I really don't understand why these were made optional in C11. Who is >>>> going to make a compiler that is C11 compliant but not C99 compliant? >>>> Who is going to be capable of making a C11 compiler but find supporting >>>> VLA's or complex numbers a major issue? >>> >>> My point exactly. I don't even understand why complex was optional in >>> C99 for freestanding implementations. >> >> Freestanding implementations don't have to provide library functions, >> and complex numbers aren't very useful without the functions declared in >> <complex.h> such as creal() and cimag(). > > > I've never really considered "no library" to really be a rule for > freestanding implementations (certainly C++ hasn't followed that > route). "Minimal" or "trivial" library, probably. "Two kinds of implementations are defined: a hosted implementation and a freestanding implementation. For a hosted implementation, this International Standard defines the set of available libraries. A freestanding implementation is one in which execution may take place without the benefit of an operating system, and has an implementation-defined set of libraries that includes certain language-support libraries (17.6.1.3)." (1.4p7). The first occurrence of "freestanding implementation" in that paragraph is italicized, and ISO convention indicating that this paragraph constitutes the official definition of that term. Nearly half of that definition is devoted to the fact that the library support required of freestanding implementations is much less complete than that required of hosted implementations. However, you have to look at 17.6.1.3 to fully understand that aspect. It refers you to table 16 "C++ headers for freestanding implementations". Those are: <ciso646> <cstddef> <cfloat> <limits> <climits> <cstdint> <cstdlib> <new> <typeinfo> <exception> <initializer_list> <cstdalign> <cstdarg> <cstdbool> <type_traits> <atomic> That list is nearly twice as long as the corresponding list in the C standard, but it still excludes most of the biggest and most complicated headers that a hosted implementation is required to support. Unlike the C list, includes some headers that declare functions, but not very many.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-07 08:37 +0100 |
| Message-ID | <qv1cf8$53q$1@dont-email.me> |
| In reply to | #71183 |
On 07/01/2020 01:08, Robert Wessel wrote: > On Sun, 05 Jan 2020 20:40:27 -0800, Keith Thompson > <Keith.S.Thompson+u@gmail.com> wrote: > >> Robert Wessel <robertwessel2@yahoo.com> writes: >>> On Sun, 5 Jan 2020 20:11:17 +0100, David Brown >>> <david.brown@hesbynett.no> wrote: >> [...] >>>> I really don't understand why these were made optional in C11. Who is >>>> going to make a compiler that is C11 compliant but not C99 compliant? >>>> Who is going to be capable of making a C11 compiler but find supporting >>>> VLA's or complex numbers a major issue? >>> >>> My point exactly. I don't even understand why complex was optional in >>> C99 for freestanding implementations. >> >> Freestanding implementations don't have to provide library functions, >> and complex numbers aren't very useful without the functions declared in >> <complex.h> such as creal() and cimag(). > > > I've never really considered "no library" to really be a rule for > freestanding implementations (certainly C++ hasn't followed that > route). "Minimal" or "trivial" library, probably. > Well, the rule is that little of the standard library /needs/ to be implemented for freestanding implementations. The practice is that just about all of it /is/ implemented, in just about all toolchains. Even for the smallest microcontrollers, you'll get a fairly full library - with some exceptions. Many I/O functions, and in particular the file functions, will be incomplete - you'll need to implement low-level (implementation specific) functions to do the reading and writing. And you will rarely get the wide character stuff. For small targets, you won't get the complex number support either. (There are also often non-compliant points, such as 32-bit "double", but that's another issue.) > Or you implement creal and cimag as macros (implementation dependent, > but trivial, in most cases). >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-10 14:51 -0800 |
| Message-ID | <86blra53hx.fsf@linuxsc.com> |
| In reply to | #71183 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Sun, 05 Jan 2020 20:40:27 -0800, Keith Thompson
> <Keith.S.Thompson+u@gmail.com> wrote:
>
>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>>> On Sun, 5 Jan 2020 20:11:17 +0100, David Brown
>>> <david.brown@hesbynett.no> wrote:
>>
>> [...]
>>
>>>> I really don't understand why these were made optional in C11. Who is
>>>> going to make a compiler that is C11 compliant but not C99 compliant?
>>>> Who is going to be capable of making a C11 compiler but find supporting
>>>> VLA's or complex numbers a major issue?
>>>
>>> My point exactly. I don't even understand why complex was optional in
>>> C99 for freestanding implementations.
>>
>> Freestanding implementations don't have to provide library functions,
>> and complex numbers aren't very useful without the functions declared in
>> <complex.h> such as creal() and cimag().
>
> I've never really considered "no library" to really be a rule for
> freestanding implementations (certainly C++ hasn't followed that
> route). "Minimal" or "trivial" library, probably.
>
> Or you implement creal and cimag as macros (implementation dependent,
> but trivial, in most cases).
These functions can be done completely portably for any implementation
that has _Complex. Here are the 'double' versions:
double
creal( _Complex double z ){
return (union { _Complex double z; double dd[2]; }){ z }.dd[0];
}
double
cimag( _Complex double z ){
return (union { _Complex double z; double dd[2]; }){ z }.dd[1];
}
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-07 08:28 +0100 |
| Message-ID | <qv1bug$2dr$1@dont-email.me> |
| In reply to | #71164 |
On 06/01/2020 04:07, Robert Wessel wrote: > On Sun, 5 Jan 2020 20:11:17 +0100, David Brown > <david.brown@hesbynett.no> wrote: > >> On 05/01/2020 19:31, Robert Wessel wrote: >>> On Sun, 5 Jan 2020 10:41:29 +0000 (UTC), boltar@nowhere.org wrote: >>> >>>> On Sat, 04 Jan 2020 18:02:10 -0600 >>>> Robert Wessel <robertwessel2@yahoo.com> wrote: >>>>> On Sat, 4 Jan 2020 12:43:10 +0000 (UTC), boltar@nowhere.org wrote: >>>>> >>>>>> On Fri, 03 Jan 2020 10:09:04 -0600 >>>>>> Robert Wessel <robertwessel2@yahoo.com> wrote: >>>>>>> On Thu, 2 Jan 2020 09:25:32 +0000 (UTC), boltar@nowhere.org wrote: >>>>>>> >>>>>>>> On Wed, 01 Jan 2020 09:09:32 -0600 >>>>>>>> Robert Wessel <robertwessel2@yahoo.com> wrote: >>>>>>>>> On Wed, 1 Jan 2020 09:13:25 +0000 (UTC), boltar@nowhere.org wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Variable length C99 arrays arn't in the C++ standard but I've yet to come >>>>>>>>>> across a C++ compiler that didn't support them either. >>>>>>>>> >>>>>>>>> >>>>>>>>> MSVC. >>>>>>>> >>>>>>>> Fair enough, but last time I used it a few years back MSVC didn't support >>>>>>> some >>>>>>>> features of modern C++ either. >>>>>>> >>>>>>> >>>>>>> An important difference is that MS for a long time has intended to >>>>>>> fully support modern C++ (that it often took some time get everything >>>>>>> done is not really relevant), but has explicitly decided *not* to >>>>>>> support C99 and later. That's changed a smidgen, of late, and will >>>>>>> VLAs no longer being mandatory, >>>>>> >>>>>> They're not? Figures, aside from variadic macros they're the only thing in >>>>>> C99 that I found useful. >>>>> >>>>> >>>>> C11 made both complex support and VLAs optional. Complex was already >>>>> optional in C99 for freestanding implementations, C11 extended the >>>>> dispensation to hosted implementations. >>>> >>>> Complex has a very niche use case so I can understand that, but VLAs are very >>>> useful if just writing plain C and can't be hard to implement so I don't >>>> understand the decision to make them optional. >>> >>> >>> If so, only because most folks who needed complex numbers moved on to >>> C++ (or rolled their own support in C long ago, and have not replaced >>> that). >>> >>> And don't be so quick to condemn a facility *you* don't happen to use >>> as "niche". In my experience there is *far* more use of complex >>> numbers in C than VLAs. Admittedly only part of that is done with the >>> native C complex type. >>> >> >> I think it is extremely difficult to guess which features are more or >> less used, and any attempts will be very biased based on the area of >> experience of the guesser. With that proviso, I'd be surprised if >> complex types really were used more than VLAs. > > > I'm not going to take much of a position on the usage of the native C > complex type, given the slow pickup of C99, it really never got a huge > amount of traction, but it is there. On the other hand, plenty of > folks have done complex arithmetic in C my rolling their own > functions. > Fair enough. > >>> On the other hand, VLAs present considerable implementation >>> difficulties on some small systems, and present a number of issues >>> with regards to stack growth on all implementations that make people >>> wary of them. >> >> I disagree. I don't see that VLA implementation would be particularly >> difficult (in small systems or otherwise). And while it is absolutely >> correct that you need to be careful about stack use before using them, >> you don't need more care than you should be taking for any other kind of >> non-variable local array, or for any other kind of memory allocation. > > > For very small systems, especially ones where recursive calls are also > difficult to support, VLAs may well present some challenges. VLA's need a calculation for the total size, adjusting the stack pointer, perhaps a frame pointer for other local data, and calculations for indexing the array. None of this is particular to VLA's - any system that can implement C in general can implement VLA's. VLA support can be inefficient - if you have a limited 8-bit accumulator-based device with poor "sp + offset" and other addressing modes, then the code will be painfully slow. But these kinds of devices (like 8051's) are painfully slow for recursive or re-entrant calls, local arrays, and many other types of code. > > In the more ordinary case, I think VLAs doe present an additional > challenge to stack management, since the frame size required by a > function is now at the mercy of its callers. That at least > theoretically creates some new paths for storage overlays and the > like. Nah, no problem - at least, not a /new/ problem. On devices where you have awkward memory overlays or page limits, you have exactly the same issues with large local data, even if you know the size. Either you say "you can't have a local stack frame bigger than X bytes" and make a limited C compiler, or you say "large local stack frames are allowed but really inefficient", or you let the programmer choose through options and/or annotations or pragmas. And if you have "alloca" support, as most reasonable C compilers do, you have almost all the bits anyway. > > I'm not sure it's as big a deal as some people made it out to be, but > there are a few new pitfalls there. > Of course it is extremely difficult and challenging to write a good C compiler for such limited devices. But VLA's pose few /new/ challenges. Anyone capable of writing a decent code generator for C without VLA's could extend it to cope with VLA's - of that I have little doubt. The only real complications I can see would be if you have jumps (gotos, switches, longjmp) that jump around VLA declarations - but again, the compiler already has to deal with such messes with normal variables. (Some may still decide not to support them due to the time and effort involved, which is fair enough.) > >>> >>> Complex support does require some compiler support, but it's just >>> another data type. The actual implementations of the basic functions >>> is pretty trivial, and for small systems can be dumped in a library >>> where it won't get linked if it's not used, so it has no impact on >>> small systems. >>> >> >> I don't imagine C's complex number support would be that hard to >> implement either. >> >> I really don't understand why these were made optional in C11. Who is >> going to make a compiler that is C11 compliant but not C99 compliant? >> Who is going to be capable of making a C11 compiler but find supporting >> VLA's or complex numbers a major issue? > > > My point exactly. I don't even understand why complex was optional in > C99 for freestanding implementations. My guess there is that it was to avoid bigger libraries. Not all toolchains are smart enough to skip library functions that are not used, at least in all cases - it is not an uncommon problem in small embedded development that you accidentally end up with a large floating point library linked into your code. Complex support would make this even worse. > > >> I doubt if their lack will cause a big problem for many people - but >> sometimes they can be convenient.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-10 14:19 -0800 |
| Message-ID | <86ftgn3qg6.fsf@linuxsc.com> |
| In reply to | #71151 |
Robert Wessel <robertwessel2@yahoo.com> writes: [...] > VLAs present considerable implementation difficulties on some > small systems, Do you mean small in the sense of limited resources? Or small in the sense of not having a full hosted library? What problems are there in these small systems that don't come up in larger systems? > and present a number of issues with regards to stack growth on all > implementations VLAs may present some issues with regard to stack growth, but they don't have to. The Standard admits implemenations that put VLAs somewhere other than on the stack, eg, allocated with malloc().
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-01 23:15 +0100 |
| Message-ID | <quj5mt$4tr$1@dont-email.me> |
| In reply to | #70921 |
On 01/01/2020 10:13, boltar@nowhere.org wrote: > On Tue, 31 Dec 2019 18:11:11 +0100 > David Brown <david.brown@hesbynett.no> wrote: >> On 31/12/2019 17:13, boltar@nowhere.org wrote: >>> On Tue, 31 Dec 2019 13:38:52 +0100 >>> David Brown <david.brown@hesbynett.no> wrote: >>>> On 31/12/2019 10:25, boltar@nowhere.org wrote: >>>> make sense to have a type holding both (like a struct). You have >>>> something like a union. In C++, a std::variant makes this safer, and >>>> makes it easier to keep track of the construction and destruction of the >>> >>> If you don't know what type you'll have at a given point in code then >>> that is what templates were invented for. They're also more flexible than >>> variants. >>> >> >> I think you are /seriously/ confused. I am not convinced you know >> enough C++ or programming to understand how little you know. > > No, you're just as thick as Leigh who didn't get the point either but you're > too arrogant to realise. > >>> Many? As I've asked in another post - name a single one that doesn't. >>> >> >> I don't know if there are any that don't support it. > > Thats because there arn't any because all C++ compilers are also C compilers. MSVC doesn't support modern C. Anyway, compilers support different languages - and they support the semantics of the language they are using at the time. When you use gcc to compile C++ code, it uses C++ semantics. When you use it for C code, it uses C semantics. (And when you use it for Fortran, or Ada, it uses those language semantics.) > >> are many that /do/ support type-punning of POD types with unions, and I >> know that the C++ standards specifically say that it is not allowed. So >> I think it is reasonable to say "Many C++ compilers support it", but >> there is no justification for claiming it applies to all. > > Variable length C99 arrays arn't in the C++ standard but I've yet to come > across a C++ compiler that didn't support them either. > gcc doesn't support them when you use it in standard modes.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-02 09:33 +0000 |
| Message-ID | <qukddu$1khk$1@gioia.aioe.org> |
| In reply to | #70946 |
On Wed, 1 Jan 2020 23:15:56 +0100 David Brown <david.brown@hesbynett.no> wrote: >On 01/01/2020 10:13, boltar@nowhere.org wrote: >> Thats because there arn't any because all C++ compilers are also C compilers. > > >MSVC doesn't support modern C. It doesn't support all of modern C++ either so no surprises there. >to compile C++ code, it uses C++ semantics. When you use it for C code, >it uses C semantics. (And when you use it for Fortran, or Ada, it uses >those language semantics.) Fortran isn't a subset of Ada. >> Variable length C99 arrays arn't in the C++ standard but I've yet to come >> across a C++ compiler that didn't support them either. >> > >gcc doesn't support them when you use it in standard modes. What gcc does and doesn't do is highly dependant on version. C99 support seems to be standard in the more recent versions and about time given the standard is now more than 20 years old.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-02 12:16 +0100 |
| Message-ID | <qukjee$j0b$1@dont-email.me> |
| In reply to | #70954 |
On 02/01/2020 10:33, boltar@nowhere.org wrote: > On Wed, 1 Jan 2020 23:15:56 +0100 > David Brown <david.brown@hesbynett.no> wrote: >> On 01/01/2020 10:13, boltar@nowhere.org wrote: >>> Thats because there arn't any because all C++ compilers are also C compilers. >> >> >> MSVC doesn't support modern C. > > It doesn't support all of modern C++ either so no surprises there. It does rather well at supporting modern C++ standards. But its C support is limited to C90 - it does not even have proper C99. <https://en.cppreference.com/w/cpp/compiler_support> > >> to compile C++ code, it uses C++ semantics. When you use it for C code, >> it uses C semantics. (And when you use it for Fortran, or Ada, it uses >> those language semantics.) > > Fortran isn't a subset of Ada. C is not a subset of C++. > >>> Variable length C99 arrays arn't in the C++ standard but I've yet to come >>> across a C++ compiler that didn't support them either. >>> >> >> gcc doesn't support them when you use it in standard modes. > > What gcc does and doesn't do is highly dependant on version. Not in this case. gcc has never supported VLA's in C++ when using standard modes, and never will - unless a later C++ standard incorporates VLA's. > C99 support seems > to be standard in the more recent versions and about time given the standard > is now more than 20 years old. > I'm guessing you are referring to the standard used by gcc by default if you don't specify "-std". To get standard modes - aiming for closer conformance to a particular C or C++ standard - you need to specify the standard you want (along with -pedantic or -pedantic-errors). By default, you get a C or C++ standard with gcc extensions (currently gnu17 for C and gnu++14 for C++).
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2019-12-31 18:14 +0000 |
| Message-ID | <20191231181428.940f7eeecc80334c9477dbe9@cvine--nospam--.freeserve.co.uk> |
| In reply to | #70874 |
On Tue, 31 Dec 2019 16:13:57 +0000 (UTC) boltar@nowhere.org wrote: > On Tue, 31 Dec 2019 13:38:52 +0100 > David Brown <david.brown@hesbynett.no> wrote: > >On 31/12/2019 10:25, boltar@nowhere.org wrote: > >make sense to have a type holding both (like a struct). You have > >something like a union. In C++, a std::variant makes this safer, and > >makes it easier to keep track of the construction and destruction of the > > If you don't know what type you'll have at a given point in code then > that is what templates were invented for. They're also more flexible than > variants. First, the purpose of variants is not to provide an alternative to templates for polymorphic code. Their main purpose is to allow values of a limited set of alternative types to be passed in a type safe way. Secondly, variants are constructed from templates. Templates are not "more flexible than variants": they are different things. Variants test the contained type within the permitted set of types at run time by reference to an index or tag; templates discriminate their types at compile time (which includes trying to instantiate a variant with a type not within its permitted variant set, which will give a compile time error). > >objects. With a union, you have to do the tracking manually. Either > >way, you avoid having objects that you don't need or want - and thus > >avoid the responsibility of creating, tracking and destroying them. > > No true. Unless you use the visit() horror then you need to know the index > position or type of what you want to access. If you need to interrogate the variant at run time to find out what it holds you can use std::variant::index (std::holds_alternative and std::get_if are also available). But in almost all real-life cases, you want to use std::visit. You have an astonishing lack of knowledge about C++. Almost everything you post is wrong.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-31 19:16 +0100 |
| Message-ID | <qug3ah$2rn$1@news.albasani.net> |
| In reply to | #70897 |
>> If you don't know what type you'll have at a given point in code then >> that is what templates were invented for. They're also more flexible than >> variants. > First, the purpose of variants is not to provide an alternative to > templates for polymorphic code. Their main purpose is to allow values > of a limited set of alternative types to be passed in a type safe way. > Secondly, variants are constructed from templates. Templates are not > "more flexible than variants": they are different things. Variants > test the contained type within the permitted set of types at run time > by reference to an index or tag; templates discriminate their types at > compile time (which includes trying to instantiate a variant with a > type not within its permitted variant set, which will give a compile > time error). Is this a nonsense-pettifogging-contest here?
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2019-12-31 18:48 +0000 |
| Message-ID | <20191231184815.800355acb5a79745ec3e9003@cvine--nospam--.freeserve.co.uk> |
| In reply to | #70898 |
On Tue, 31 Dec 2019 19:16:50 +0100 Bonita Montero <Bonita.Montero@gmail.com> wrote: > >> If you don't know what type you'll have at a given point in code then > >> that is what templates were invented for. They're also more flexible than > >> variants. > > > First, the purpose of variants is not to provide an alternative to > > templates for polymorphic code. Their main purpose is to allow values > > of a limited set of alternative types to be passed in a type safe way. > > Secondly, variants are constructed from templates. Templates are not > > "more flexible than variants": they are different things. Variants > > test the contained type within the permitted set of types at run time > > by reference to an index or tag; templates discriminate their types at > > compile time (which includes trying to instantiate a variant with a > > type not within its permitted variant set, which will give a compile > > time error). > > Is this a nonsense-pettifogging-contest here? So you really think that "If you don't know what type you'll have at a given point in code then that is what templates were invented for. They're also more flexible than variants" is an accurate discription of the purpose of variants and templates. If so, you are as clueless as Boltar. Have you ever used discriminated unions in your programming life? (Clearly Boltar hasn't)
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2019-12-31 12:29 -0800 |
| Message-ID | <e4bb929e-8ac1-4d90-9b35-640e2f4e8ef0@googlegroups.com> |
| In reply to | #70902 |
On Tuesday, December 31, 2019 at 1:48:50 PM UTC-5, Chris Vine wrote: > On Tue, 31 Dec 2019 19:16:50 +0100 > Bonita Montero <Bonita.Montero@gmail.com> wrote: > > > "Variants test the contained type within the permitted set of types at > > > run time by reference to an index or tag > > > > Is this a nonsense-pettifogging-contest here? > > So you really think that <quote from bol...> > I think Bonita is permitted to question your wording in the quote above, without a suggestion that that implies bol...'s position :-) Daniel
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-01 09:17 +0000 |
| Message-ID | <quho2v$1f92$1@gioia.aioe.org> |
| In reply to | #70897 |
On Tue, 31 Dec 2019 18:14:28 +0000 Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote: >On Tue, 31 Dec 2019 16:13:57 +0000 (UTC) >boltar@nowhere.org wrote: >> On Tue, 31 Dec 2019 13:38:52 +0100 >> David Brown <david.brown@hesbynett.no> wrote: >> >On 31/12/2019 10:25, boltar@nowhere.org wrote: >> >make sense to have a type holding both (like a struct). You have >> >something like a union. In C++, a std::variant makes this safer, and >> >makes it easier to keep track of the construction and destruction of the >> >> If you don't know what type you'll have at a given point in code then >> that is what templates were invented for. They're also more flexible than >> variants. > >First, the purpose of variants is not to provide an alternative to >templates for polymorphic code. Their main purpose is to allow values >of a limited set of alternative types to be passed in a type safe way. > >Secondly, variants are constructed from templates. Templates are not There's nothing more amusing than people who think they're smart attempting to demonstrate it by stating the bleeding obvious. That makes 3 of you now :) So the chevrons with the types following the variant class name are a template def are they? Gosh, thanks for the heads up there Einstein, I never knew! LOL :) Happy New Year you bunch of muppets :)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-30 16:32 +0100 |
| Message-ID | <qud59s$p20$1@dont-email.me> |
| In reply to | #70810 |
On 30/12/2019 13:03, Paavo Helde wrote: > On 30.12.2019 12:10, boltar@nowhere.org wrote: >> On Sun, 29 Dec 2019 21:45:14 +0200 >> Paavo Helde <myfirstname@osa.pri.ee> wrote: >>> On 29.12.2019 20:30, boltar@nowhere.org wrote: >>>> On Sun, 29 Dec 2019 12:21:33 +0200 >>>> Paavo Helde <myfirstname@osa.pri.ee> wrote: >>>>> On 29.12.2019 11:00, boltar@nowhere.org wrote: >>>>> >>>>>> The whole point of C unions is that they're NOT type safe. A type >>>>>> safe >>> union >>>>>> is a contradiction. >>>>> >>>>> In case you haven't noticed yet we are talking C++ here, not C. A >>>>> major >>>>> strength of C++ is to build higher level abstractions, in particular >>>>> typesafe and zero overhead abstractions over low-level unsafe >>>>> primitives >>>>> like C unions. >>>> >>>> The whole point of a union is not to save memory, its to write as >>>> one type >>>> and read as another , >>> >>> You wish. However, this is undefined behavior by the standard. >> >> Oh dear, someone better tell the authors of the standard unix networking >> libraries then. Clearly they have no clue, I mean look at this horror >> from >> net/if.h: > > There is no problem with unions when they are used correctly. This means > one can only read the union member which was written last. I am sure > Unix programmers know all about this. > >> >> fenris$ grep union $(find usr/include -name "*.h") | wc -l >> 386 > > What's your point in grepping the source code for "union"? Union is not > a prohibited word, neither in C++ nor in C, and can be used perfectly > fine, assuming one is able to follow a few simple rules. > And the code in question is C, which has slightly different semantics than C++. In particular, type punning via unions is defined by the standard in C but not C++. Not that the code in question uses type punning as far as I can guess.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2019-12-30 14:57 +0100 |
| Message-ID | <h6ue26Ft5sjU1@mid.individual.net> |
| In reply to | #70805 |
On 2019-12-30 at 11:10, boltar@nowhere.org wrote:
> On Sun, 29 Dec 2019 21:45:14 +0200
> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> On 29.12.2019 20:30, boltar@nowhere.org wrote:
>>> On Sun, 29 Dec 2019 12:21:33 +0200
>>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>>> On 29.12.2019 11:00, boltar@nowhere.org wrote:
>>>>
>>>>> The whole point of C unions is that they're NOT type safe. A type safe
>> union
>>>>> is a contradiction.
>>>>
>>>> In case you haven't noticed yet we are talking C++ here, not C. A major
>>>> strength of C++ is to build higher level abstractions, in particular
>>>> typesafe and zero overhead abstractions over low-level unsafe primitives
>>>> like C unions.
>>>
>>> The whole point of a union is not to save memory, its to write as one type
>>> and read as another ,
>>
>> You wish. However, this is undefined behavior by the standard.
>
> Oh dear, someone better tell the authors of the standard unix networking
> libraries then. Clearly they have no clue, I mean look at this horror from
> net/if.h:
>
> struct ifreq {
> #ifndef IFNAMSIZ
> #define IFNAMSIZ IF_NAMESIZE
> #endif
> char ifr_name[IFNAMSIZ]; /* if name, e.g. "en0" */
> union {
> struct sockaddr ifru_addr;
> struct sockaddr ifru_dstaddr;
> struct sockaddr ifru_broadaddr;
> short ifru_flags;
> int ifru_metric;
> int ifru_mtu;
> int ifru_phys;
> int ifru_media;
> int ifru_intval;
> caddr_t ifru_data;
>
> etc etc etc.
>
Seems to me that they know exactly what they are doing.
So this is C code (not C++) for a specific compiler on a specific
operating system. As gcc has always defined the behavior, it "just
works" there.
However, not recommended for portable code.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-31 09:23 +0000 |
| Message-ID | <quf42p$1g1t$1@gioia.aioe.org> |
| In reply to | #70820 |
On Mon, 30 Dec 2019 14:57:25 +0100
Bo Persson <bo@bo-persson.se> wrote:
>On 2019-12-30 at 11:10, boltar@nowhere.org wrote:
>> On Sun, 29 Dec 2019 21:45:14 +0200
>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>> On 29.12.2019 20:30, boltar@nowhere.org wrote:
>>>> On Sun, 29 Dec 2019 12:21:33 +0200
>>>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>>>> On 29.12.2019 11:00, boltar@nowhere.org wrote:
>>>>>
>>>>>> The whole point of C unions is that they're NOT type safe. A type safe
>>> union
>>>>>> is a contradiction.
>>>>>
>>>>> In case you haven't noticed yet we are talking C++ here, not C. A major
>>>>> strength of C++ is to build higher level abstractions, in particular
>>>>> typesafe and zero overhead abstractions over low-level unsafe primitives
>>>>> like C unions.
>>>>
>>>> The whole point of a union is not to save memory, its to write as one type
>>>> and read as another ,
>>>
>>> You wish. However, this is undefined behavior by the standard.
>>
>> Oh dear, someone better tell the authors of the standard unix networking
>> libraries then. Clearly they have no clue, I mean look at this horror from
>> net/if.h:
>>
>> struct ifreq {
>> #ifndef IFNAMSIZ
>> #define IFNAMSIZ IF_NAMESIZE
>> #endif
>> char ifr_name[IFNAMSIZ]; /* if name, e.g. "en0" */
>> union {
>> struct sockaddr ifru_addr;
>> struct sockaddr ifru_dstaddr;
>> struct sockaddr ifru_broadaddr;
>> short ifru_flags;
>> int ifru_metric;
>> int ifru_mtu;
>> int ifru_phys;
>> int ifru_media;
>> int ifru_intval;
>> caddr_t ifru_data;
>>
>> etc etc etc.
>>
>
>Seems to me that they know exactly what they are doing.
>
>So this is C code (not C++) for a specific compiler on a specific
>operating system. As gcc has always defined the behavior, it "just
>works" there.
Its from MacOS so its compiled with Clang.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-12-30 22:16 -0500 |
| Message-ID | <queeiv$iqr$1@dont-email.me> |
| In reply to | #70805 |
On 12/30/19 5:10 AM, boltar@nowhere.org wrote:
> On Sun, 29 Dec 2019 21:45:14 +0200
> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> On 29.12.2019 20:30, boltar@nowhere.org wrote:
>>> On Sun, 29 Dec 2019 12:21:33 +0200
...
>>> The whole point of a union is not to save memory, its to write as one type
>>> and read as another ,
>>
>> You wish. However, this is undefined behavior by the standard.
>
> Oh dear, someone better tell the authors of the standard unix networking
> libraries then. Clearly they have no clue, I mean look at this horror from
> net/if.h:
>
> struct ifreq {
> #ifndef IFNAMSIZ
> #define IFNAMSIZ IF_NAMESIZE
> #endif
> char ifr_name[IFNAMSIZ]; /* if name, e.g. "en0" */
> union {
> struct sockaddr ifru_addr;
> struct sockaddr ifru_dstaddr;
> struct sockaddr ifru_broadaddr;
> short ifru_flags;
> int ifru_metric;
> int ifru_mtu;
> int ifru_phys;
> int ifru_media;
> int ifru_intval;
> caddr_t ifru_data;
How does that declaration prove your point? It doesn't involve any
examples of "write as one type and read as another'.
Also,on Unix platforms, the C compiler is part of the same
implementation that provides those headers. The reason why portable code
should avoid "write as one type and read as another' is that the
behavior of such code is undefined (except in C2011). The implementors
KNOW what form the undefined behavior of such code takes on their
platform, and therefore can write code which relies upon that behavior.
Code intended to be portable can't do that.
Also, don't you find it a bit odd that what you consider to be "the
whole point of a union" has always had undefined behavior in C++, and
had undefined behavior in C all the way up until C2011? If the C and C++
committees had considered that "write as one type and read as another"
to be the whole point of unions, or even just the main point, or even
just a commonplace usage, you would think they would have explicitly
defined what the behavior of such usage was. In fact, the main point of
unions was originally the ability to store objects of multiple different
types in the same piece of memory, so long as the storage periods didn't
overlap.
It wasn't until C2011 that a footnote was added to the C standard
identifying that the behavior of "write as one type and read as another"
is to reinterpret the associated memory as having the type of the lvalue
used to read it. This still makes it completely dependent upon the
implementation-defined representation of the two types involved, so it
still can't be used in code that's intended to be portable, but the new
wording does allow it be used in code that doesn't need to be portable.
Footnotes are non-normative, and I've been unable to locate any
corresponding normative text in the C standard. People who should know
claim that this can be derived from other things the standard says about
obect representations, but when I asked for the details of that
derivation, all I got in response was silence. However, I haven't
bothered complaining much about it, because that's what most people have
always expected, what most C and C++ compilers have actually done, and
the footnote makes it clear that this is the C committee's intent - so
the absence of supporting normative text isn't a particularly important
problem.
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2019-12-30 20:30 -0800 |
| Message-ID | <chine.bleu-F87883.20305030122019@reader.eternal-september.org> |
| In reply to | #70846 |
In article <queeiv$iqr$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> implementation-defined representation of the two types involved, so it
> still can't be used in code that's intended to be portable, but the new
> wording does allow it be used in code that doesn't need to be portable.
typedef enum {
BigEndian = 0,
HoneywellEndian = 1,
PDPEndian = 2,
LittleEndian = 3
};
#define nativeByteOrder ( \
((union{char b[4]; uint32_t n;}){.b={
LittleEndian, HoneywellEndian, \
PDP11Endian, BigEndian}}).n & 0xFF)
#define bigEndian (nativeByteOrder==BigEndian)
#define honeywellEndian (nativeByteOrder==HoneywellEndian)
#define pdpEndian (nativeByteOrder==PDPEndian)
#define littleEndian (nativeByteOrder==LittleEndian)
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
The first law of discordiamism: The more energy This post / \
to make order is nore energy made into entropy. insults Islam. Mohammed
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-10 21:12 -0800 |
| Message-ID | <86tv5237ae.fsf@linuxsc.com> |
| In reply to | #70846 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> Also, don't you find it a bit odd that what you consider to be
> "the whole point of a union" has always had undefined behavior in
> C++, and had undefined behavior in C all the way up until C2011?
Note that James's opinion on when the behavior was defined in C
doesn't match the C standard committee's opinion on when the
behavior was defined in C. See for example DR 283 (dated 2002)
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_283.htm
> It wasn't until C2011 that a footnote was added to the C standard
> identifying that the behavior of "write as one type and read as
> another" is to reinterpret the associated memory as having the
> type of the lvalue used to read it.
False. See N1256 if you don't believe me.
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2019-12-30 20:07 -0800 |
| Message-ID | <chine.bleu-A1829C.20065830122019@reader.eternal-september.org> |
| In reply to | #70805 |
In article <qucif8$1oa0$1@gioia.aioe.org>, boltar@nowhere.org wrote: > >You wish. However, this is undefined behavior by the standard. > > Oh dear, someone better tell the authors of the standard unix networking > libraries then. Clearly they have no clue, I mean look at this horror from > net/if.h: If your contract for C source code demands it conform to ANS C, if.h violates the contract. If the contract has some different requirement, like compatiable with gcc -lplugh2.77.1, then maybe if.h is okay. If the contract requires Ada, you ain't even close. There's no international treaty of C Standard Compliance. You choose what you and the customers agree to. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ The first law of discordiamism: The more energy This post / \ to make order is nore energy made into entropy. insults Islam. Mohammed
[toc] | [prev] | [next] | [standalone]
Page 10 of 16 — ← Prev page 1 … 8 9 [10] 11 12 … 16 Next page →
Back to top | Article view | comp.lang.c++
csiph-web