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 9 of 16 — ← Prev page 1 … 7 8 [9] 10 11 … 16 Next page →
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-31 19:06 +0200 |
| Message-ID | <qufv64$tur$1@dont-email.me> |
| In reply to | #70873 |
On 31.12.2019 18:10, boltar@nowhere.org wrote: > On Tue, 31 Dec 2019 12:00:33 GMT > Melzzzzz <Melzzzzz@zzzzz.com> wrote: >> >> In C++11 you can use objects in union.... > > Possibly not a good idea if a virtual function table is anywhere in that > object. Otherwise it would be no different to a C struct. It seems you have learned nothing from this thread. C++ objects in unions are supported since C++11. Yes, you have to construct and destruct them explicitly via placement new and destructor calls, but this is not so tricky as it sounds because you have to keep track about the active member in the union anyway.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-31 14:06 +0200 |
| Message-ID | <qufdjo$mqp$1@dont-email.me> |
| In reply to | #70854 |
On 31.12.2019 11:25, boltar@nowhere.org wrote: > On Mon, 30 Dec 2019 16:39:03 +0100 > David Brown <david.brown@hesbynett.no> wrote: >> I don't think anyone will disagree that unions are /sometimes/ used for >> type-punning in C. >> >> But when you claim that this is the /only/ use, outside tiny embedded >> systems, you are talking drivel. > > So other than the VERY occasional uses of saving memory or reducing the amount > pushed onto a stack in a function call/return, what would you say is the main > use for a union then? There is no other use, at least not according to the C++ standard. Its usefulness can be "VERY occasional" or "sometimes useful", which basically mean the same if you remove the emotional dressing. I think nobody claims union is the most important construct in C++. This is also related to the zero overhead principle. If there is no reason to allocate any extra bytes for the object, the C++ language must provide means to avoid that, in order to maintain zero overhead.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-31 13:38 +0100 |
| Message-ID | <quffgt$1br$1@dont-email.me> |
| In reply to | #70854 |
On 31/12/2019 10:25, boltar@nowhere.org wrote:
> On Mon, 30 Dec 2019 16:39:03 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>> On 30/12/2019 14:01, boltar@nowhere.org wrote:
>>
>>>
>>> Want a better example? From math.h:
>>>
>>> __header_always_inline int __inline_signbitf(float __x) {
>>> union { float __f; unsigned int __u; } __u;
>>> __u.__f = __x;
>>> return (int)(__u.__u >> 31);
>>> }
>>>
>>
>> I don't think anyone will disagree that unions are /sometimes/ used for
>> type-punning in C.
>>
>> But when you claim that this is the /only/ use, outside tiny embedded
>> systems, you are talking drivel.
>
> So other than the VERY occasional uses of saving memory or reducing the amount
> pushed onto a stack in a function call/return, what would you say is the main
> use for a union then?
I'd say it is used for three things:
1. To avoid pointlessly wasting memory. PC's may have oodles of ram,
but they have small caches. Small unions don't even need to go into
memory - compilers optimise them like any other data.
2. To express "sum types" - a type that can be one of several other
types. (structs are "product types" in the same sense.)
3. For type punning.
If you know you need either an A or a B, but not both, it simply doesn't
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
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.
>
>> Type-punning through unions is defined in C standards, but referencing
>> examples from its use in C says nothing about unions in C++.
>
> Many C header files and source code will be included into a C++ project. In
> any sane world C++ *will* support the same union rules as C because it has
> to regardless of whatever the standards committee in their ivory tower say.
>
No, that is not an issue.
Header files will often have declarations of union types - either as
independent types, or specifically for parameters to functions or APIs.
But they will rarely contain code that /uses/ the union, and does any
type-punning. You can use the union for non-type-punning access in the
C++ code that includes the header, and for type-punning access in the C
code that implements the functions declared in the header. That's all
fine and standards-compliant.
Many C++ compilers /do/ support type-punning for POD unions, just
because it is simple to support and occasionally useful to programmers.
But they would not have to do so.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-31 16:13 +0000 |
| Message-ID | <qufs45$114l$1@gioia.aioe.org> |
| In reply to | #70862 |
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. >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. >Many C++ compilers /do/ support type-punning for POD unions, just Many? As I've asked in another post - name a single one that doesn't.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@i42.removethisbit.co.uk> |
|---|---|
| Date | 2019-12-31 17:06 +0000 |
| Message-ID | <MeLOF.261829$5I8.40379@fx04.dcg> |
| In reply to | #70874 |
On 31/12/2019 16: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. std::variant is a template. It seems you haven't acquired a cluebat yet like I suggested? You really should as we would all benefit from less ignorant noise in this forum. /Flibble -- “You won’t burn in hell. But be nice anyway.” – Ricky Gervais “I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-01 09:09 +0000 |
| Message-ID | <quhnjt$1d5i$1@gioia.aioe.org> |
| In reply to | #70885 |
On Tue, 31 Dec 2019 17:06:52 +0000 Mr Flibble <flibble@i42.removethisbit.co.uk> wrote: >On 31/12/2019 16: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. > >std::variant is a template. ITYM its a class that uses templates. However, congratulations on completely missing the point. Again.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-31 18:11 +0100 |
| Message-ID | <qufvfg$vm7$1@dont-email.me> |
| In reply to | #70874 |
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. >> 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. > >> Many C++ compilers /do/ support type-punning for POD unions, just > > 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. I /do/ know there 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.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-01 09:13 +0000 |
| Message-ID | <quhnrl$1e4j$1@gioia.aioe.org> |
| In reply to | #70886 |
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. >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.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2020-01-01 09:09 -0600 |
| Message-ID | <dgdp0f5cvp0cl90st9i2khqaoucbrnjqgu@4ax.com> |
| In reply to | #70921 |
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.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-02 09:25 +0000 |
| Message-ID | <qukcuc$1i8b$1@gioia.aioe.org> |
| In reply to | #70929 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2020-01-03 10:09 -0600 |
| Message-ID | <oipu0f9rccv1g767njqh18602vgjvrs23g@4ax.com> |
| In reply to | #70952 |
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, we might plausibly see more modern C support, but still without VLAs.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-04 12:43 +0000 |
| Message-ID | <quq18u$15gu$1@gioia.aioe.org> |
| In reply to | #71029 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2020-01-04 18:02 -0600 |
| Message-ID | <uj921f9ih223fneb5b70qj76nap03omq1k@4ax.com> |
| In reply to | #71106 |
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.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-05 10:41 +0000 |
| Message-ID | <qusegp$1lkt$1@gioia.aioe.org> |
| In reply to | #71122 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2020-01-05 12:31 -0600 |
| Message-ID | <sca41flpc6no0b156ounhkiqaokmjdf2ii@4ax.com> |
| In reply to | #71142 |
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. 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-05 20:11 +0100 |
| Message-ID | <qutccm$mci$1@dont-email.me> |
| In reply to | #71151 |
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. > 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. > > 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? I doubt if their lack will cause a big problem for many people - but sometimes they can be convenient.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-01-05 11:22 -0800 |
| Message-ID | <9ede2c0a-ac1d-4f17-8996-54746f50f647@googlegroups.com> |
| In reply to | #71153 |
On Sunday, 5 January 2020 21:11:28 UTC+2, David Brown 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? Yes, _Generic, <threads.h> and <stdatomic.h> sound like work, while VLA's and complex numbers sound like syntax sugar.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2020-01-05 21:07 -0600 |
| Message-ID | <9j851fhqe4focdnq2uie27brr8n7icpj2h@4ax.com> |
| In reply to | #71153 |
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. >> 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. 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. 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. >> >> 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. >I doubt if their lack will cause a big problem for many people - but >sometimes they can be convenient.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-05 20:40 -0800 |
| Message-ID | <87d0bxmc3o.fsf@nosuchdomain.example.com> |
| In reply to | #71164 |
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().
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2020-01-06 18:08 -0600 |
| Message-ID | <uji71flt02rkrvu3iaded7vm9pqbc4594e@4ax.com> |
| In reply to | #71166 |
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).
[toc] | [prev] | [next] | [standalone]
Page 9 of 16 — ← Prev page 1 … 7 8 [9] 10 11 … 16 Next page →
Back to top | Article view | comp.lang.c++
csiph-web