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 11 of 16 — ← Prev page 1 … 9 10 [11] 12 13 … 16 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-30 13:50 +0100 |
| Message-ID | <qucrqj$a1i$1@news.albasani.net> |
| In reply to | #70776 |
> The whole point of a union is not to save memory, > its to write as one type and read as another ... That's your taste, but not what it is usually used for.
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2020-01-01 08:11 -0800 |
| Message-ID | <7550eec0-8b46-40d9-8903-5bee38ebb37e@googlegroups.com> |
| In reply to | #70776 |
On Sunday, December 29, 2019 at 1:30:50 PM UTC-5, bol...@nowhere.org wrote:
>
> The whole point of a union is not to save memory, its to write as one type
> and read as another
Not according to K&R, 1st edition. K&R write
"This is the purpose of a union — to provide a single variable which can legitimately hold any one of several types.
union u_tag {
int ival;
float fval;
char *pval;
} uval;
The variable uval will be large enough to hold the largest of the three
types, regardless of the machine it is compiled on — the code is
independent of hardware characteristics. Any one of these types may be
assigned to uval and then used in expressions, so long as the usage is
consistent: the type retrieved must be the type most recently stored. It is
the responsibility of the programmer to keep track of what type is currently
stored in a union; the results are machine dependent if something is stored as
one type and extracted as another."
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-02 09:28 +0000 |
| Message-ID | <qukd3m$1j5u$1@gioia.aioe.org> |
| In reply to | #70933 |
On Wed, 1 Jan 2020 08:11:38 -0800 (PST)
Daniel <danielaparker@gmail.com> wrote:
>On Sunday, December 29, 2019 at 1:30:50 PM UTC-5, bol...@nowhere.org wrote:
>>=20
>> The whole point of a union is not to save memory, its to write as one typ=
>e
>> and read as another
>
>Not according to K&R, 1st edition. K&R write
Usage has changed since the early 1970s. We don't declare function parameters
twice either any more. eg:
main(argc, argv)
int argc;
char **argv;
{
}
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-10 21:26 -0800 |
| Message-ID | <86pnfq36nl.fsf@linuxsc.com> |
| In reply to | #70933 |
Daniel <danielaparker@gmail.com> writes:
> On Sunday, December 29, 2019 at 1:30:50 PM UTC-5, bol...@nowhere.org wrote:
>
>> The whole point of a union is not to save memory, its to write as
>> one type and read as another
>
> Not according to K&R, 1st edition. K&R write
>
> "This is the purpose of a union ? to provide a single variable which
> can legitimately hold any one of several types.
>
> union u_tag {
>
> int ival;
> float fval;
> char *pval;
> } uval;
>
> The variable uval will be large enough to hold the largest of the
> three types, regardless of the machine it is compiled on ? the code
> is independent of hardware characteristics. Any one of these types
> may be assigned to uval and then used in expressions, so long as the
> usage is consistent: the type retrieved must be the type most
> recently stored. It is the responsibility of the programmer to keep
> track of what type is currently stored in a union; the results are
> machine dependent if something is stored as one type and extracted
> as another."
As far as how unions behave goes, what this says is basically the
same as what C89/C90 says, which in turn has the same intended
meaning as the more complete descriptions in later C standards.
Note that I'm not saying anything about the main or intended purpose
of unions. Clearly though K&R recognized that unions could be used
for type punning (as it is called today).
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2019-12-29 11:31 +0000 |
| Message-ID | <20191229113100.bc52671cc816d46075e4dfea@cvine--nospam--.freeserve.co.uk> |
| In reply to | #70758 |
On Sun, 29 Dec 2019 09:00:09 +0000 (UTC) boltar@nowhere.org wrote: > On Sat, 28 Dec 2019 21:01:02 +0000 > Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote: > >On Sat, 28 Dec 2019 12:05:30 +0000 (UTC) > >boltar@nowhere.org wrote: > >> I give up , its like talking to geese sometimes. > > > >Please make sure you keep to your word and stop posting any further on > >this subject. You have separately been told (Keith Thompson 26 Dec 2019 > >10:54:48 -0800) of the requirement in the standard that the contents of > >optionals are to be subsumed within the storage of the option, and so > >are not to give rise to any additional allocations on the heap, and the > > Thats all well and good, but if the contained object DOES do its own further > dynamic allocations or assignments then there will be allocations on the heap. If the contained object happens to do its own allocations it does its own allocations, whether or not it is contained in a variant. You are missing the point I am afraid, so far as you ever had one. You claimed variants or options would give rise to additional allocations and would therefore be inefficient in use. The standard prohibits such additional allocations: end of story. > >same applies to variants (discriminated unions), of which optionals > >are just a specialization: variants act in a similar way to C-style > >unions (but with type safety). In most uses they will be significantly > > The whole point of C unions is that they're NOT type safe. A type safe union > is a contradiction. The whole point of variants is that they ARE type safe. You should stick to your original plan of giving up. > >more efficient than your earlier suggestion of using inheritance with > >virtual functions, and more convenient to write: visitors for > >std::visit are reasonably easy to write in C++17. > > Don't get me started on the visitor pattern - an absolute joke of a "solution" > looking for a problem. std::visit for variants isn't concerned with the GoF visitor pattern. > >Your condescending posts to those who have taken the trouble to explain > >this to you a number of times seems to show that have the emotional age > >of a teenager. > > If thats your opinion then do kindly go fuck yourself you patronising cunt > (as Flibble might say). I must decline your invitation. I imagine it is probably the opinion of anyone reading your posts, so your suggestion would give rise to an excessive amount of self-copulation taking place. If you carry on like this your mummy is going to send you to your bedroom without your supper.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-29 18:35 +0000 |
| Message-ID | <quarm6$1v86$1@gioia.aioe.org> |
| In reply to | #70771 |
On Sun, 29 Dec 2019 11:31:00 +0000 Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote: >On Sun, 29 Dec 2019 09:00:09 +0000 (UTC) >boltar@nowhere.org wrote: >> On Sat, 28 Dec 2019 21:01:02 +0000 >> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote: >> >On Sat, 28 Dec 2019 12:05:30 +0000 (UTC) >> >boltar@nowhere.org wrote: >> >> I give up , its like talking to geese sometimes. >> > >> >Please make sure you keep to your word and stop posting any further on >> >this subject. You have separately been told (Keith Thompson 26 Dec 2019 >> >10:54:48 -0800) of the requirement in the standard that the contents of >> >optionals are to be subsumed within the storage of the option, and so >> >are not to give rise to any additional allocations on the heap, and the >> >> Thats all well and good, but if the contained object DOES do its own further >> dynamic allocations or assignments then there will be allocations on the >heap. > >If the contained object happens to do its own allocations it does its >own allocations, whether or not it is contained in a variant. You are >missing the point I am afraid, so far as you ever had one. You >claimed variants or options would give rise to additional allocations >and would therefore be inefficient in use. The standard prohibits >such additional allocations: end of story. Used with any useful objects , eg even a string value that is modified on the fly beyond any fixed sized internal array then any hope of storing all data on the stack goes out the window. >> The whole point of C unions is that they're NOT type safe. A type safe union >> is a contradiction. > >The whole point of variants is that they ARE type safe. You should >stick to your original plan of giving up. The whole point of variants is .... beats me. Memory isn't an issue these days and you wouldn't be using them programming a PIC anyway, and they do not perform the type punning like a C union, which is the whole point of the latter. >excessive amount of self-copulation taking place. If you carry on like >this your mummy is going to send you to your bedroom without your >supper. Don't project your own personal circumstances onto those of others, it only ends in embarrasment.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@i42.removethisbit.co.uk> |
|---|---|
| Date | 2019-12-29 18:40 +0000 |
| Message-ID | <eq6OF.165404$eP4.109647@fx23.dcg> |
| In reply to | #70777 |
On 29/12/2019 18:35, boltar@nowhere.org wrote: > On Sun, 29 Dec 2019 11:31:00 +0000 > Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote: >> On Sun, 29 Dec 2019 09:00:09 +0000 (UTC) >> boltar@nowhere.org wrote: >>> On Sat, 28 Dec 2019 21:01:02 +0000 >>> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote: >>>> On Sat, 28 Dec 2019 12:05:30 +0000 (UTC) >>>> boltar@nowhere.org wrote: >>>>> I give up , its like talking to geese sometimes. >>>> >>>> Please make sure you keep to your word and stop posting any further on >>>> this subject. You have separately been told (Keith Thompson 26 Dec 2019 >>>> 10:54:48 -0800) of the requirement in the standard that the contents of >>>> optionals are to be subsumed within the storage of the option, and so >>>> are not to give rise to any additional allocations on the heap, and the >>> >>> Thats all well and good, but if the contained object DOES do its own further >>> dynamic allocations or assignments then there will be allocations on the >> heap. >> >> If the contained object happens to do its own allocations it does its >> own allocations, whether or not it is contained in a variant. You are >> missing the point I am afraid, so far as you ever had one. You >> claimed variants or options would give rise to additional allocations >> and would therefore be inefficient in use. The standard prohibits >> such additional allocations: end of story. > > Used with any useful objects , eg even a string value that is modified on the > fly beyond any fixed sized internal array then any hope of storing all data > on the stack goes out the window. > >>> The whole point of C unions is that they're NOT type safe. A type safe union >>> is a contradiction. >> >> The whole point of variants is that they ARE type safe. You should >> stick to your original plan of giving up. > > The whole point of variants is .... beats me. Memory isn't an issue these > days and you wouldn't be using them programming a PIC anyway, and they do not > perform the type punning like a C union, which is the whole point of the latter. > >> excessive amount of self-copulation taking place. If you carry on like >> this your mummy is going to send you to your bedroom without your >> supper. > > Don't project your own personal circumstances onto those of others, it only > ends in embarrasment. The only embarrassment here is your pathetic attempts at trolling to try to hide the fact that you fucked up. You are wrong and you know it. /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 | 2019-12-30 10:12 +0000 |
| Message-ID | <quciie$1opu$1@gioia.aioe.org> |
| In reply to | #70778 |
On Sun, 29 Dec 2019 18:40:09 +0000 Mr Flibble <flibble@i42.removethisbit.co.uk> wrote: >On 29/12/2019 18:35, boltar@nowhere.org wrote: >> Don't project your own personal circumstances onto those of others, it only >> ends in embarrasment. > >The only embarrassment here is your pathetic attempts at trolling to try >to hide the fact that you fucked up. You are wrong and you know it. You're a complete tit and you know it.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-30 14:10 +0100 |
| Message-ID | <qucsv9$74i$1@news.albasani.net> |
| In reply to | #70777 |
> The whole point of variants is .... beats me. Memory isn't an issue these > days and you wouldn't be using them programming a PIC anyway, and they do not > perform the type punning like a C union, which is the whole point of the latter. Boy, you're so ultimately stupid! If you don't have tiny objects in a variant but objects that handle their own dependent resources, memory does matter.
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2019-12-29 12:11 -0800 |
| Message-ID | <2a05f391-143c-427f-aa80-dc4d83032fb5@googlegroups.com> |
| In reply to | #70771 |
On Sunday, December 29, 2019 at 6:30:55 AM UTC-5, Chris Vine wrote: > On Sun, 29 Dec 2019 09:00:09 +0000 (UTC) > > > > kindly go fuck yourself > > (as Flibble might say). > While it's always interesting to speculate on what our excellent Mr Flibble might say, I doubt if he would say exactly this, as I don't recall him previously suggesting an anatomically impossibility. > I must decline your invitation. Nice way to bring things back on topic, to optionality. Daniel
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2019-12-29 22:20 -0800 |
| Message-ID | <228d01d3-e7d0-468b-bb7a-798fbf49bf71@googlegroups.com> |
| In reply to | #70743 |
On Saturday, December 28, 2019 at 4:00:59 PM UTC-5, Chris Vine wrote:
> visitors for std::visit are reasonably easy to write in C++17.
>
For some definition of easy, for a contrary opinion, see
https://bitbashing.io/std-visit.html
Do you really find (from https://en.cppreference.com/w/cpp/utility/variant/visit)
std::visit([](auto&& arg) {
using T = std::decay_t<decltype(arg)>;
if constexpr (std::is_same_v<T, int>)
std::cout << "int with value " << arg << '\n';
else if constexpr (std::is_same_v<T, long>)
std::cout << "long with value " << arg << '\n';
else if constexpr (std::is_same_v<T, double>)
std::cout << "double with value " << arg << '\n';
else if constexpr (std::is_same_v<T, std::string>)
std::cout << "std::string with value " << std::quoted(arg) << '\n';
else
static_assert(always_false<T>::value, "non-exhaustive visitor!");
}, w);
to be pleasing to the eye?
Daniel
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-30 01:23 -0800 |
| Message-ID | <fce2656d-5855-426b-a087-6e0acab72bdc@googlegroups.com> |
| In reply to | #70800 |
On Monday, 30 December 2019 08:20:15 UTC+2, Daniel wrote:
> On Saturday, December 28, 2019 at 4:00:59 PM UTC-5, Chris Vine wrote:
>
> > visitors for std::visit are reasonably easy to write in C++17.
> >
> For some definition of easy, for a contrary opinion, see
>
> https://bitbashing.io/std-visit.html
>
> Do you really find (from https://en.cppreference.com/w/cpp/utility/variant/visit)
>
> std::visit([](auto&& arg) {
> using T = std::decay_t<decltype(arg)>;
> if constexpr (std::is_same_v<T, int>)
> std::cout << "int with value " << arg << '\n';
> else if constexpr (std::is_same_v<T, long>)
> std::cout << "long with value " << arg << '\n';
> else if constexpr (std::is_same_v<T, double>)
> std::cout << "double with value " << arg << '\n';
> else if constexpr (std::is_same_v<T, std::string>)
> std::cout << "std::string with value " << std::quoted(arg) << '\n';
> else
> static_assert(always_false<T>::value, "non-exhaustive visitor!");
> }, w);
>
> to be pleasing to the eye?
Not too attractive but far better than what was available in C++98.
It is easy to understand why.
Types and functions were not made first-class citizens in C++ but kind
of compile-time phenomenon.
Compile-time processing was also not made normal like any other
processing in C++ but just accidental possibility using ugly template
hacks.
These have been tried to retrofit into C++. However not into
C++ language but by parroting best of those horrid template hacks
into library.
Only where even best of programmers could not make it without usage of
preprocessor hacks in C++98 (like range based for, variadic templates
and lambdas) have they added something to core language.
Also they next to never cut unfortunate features out of C++.
Results are what we see. However a tool is a tool. It must not be
pretty. Important is what can be done with it.
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2019-12-30 15:54 +0000 |
| Message-ID | <20191230155405.ddbde1794e8660a0c7a17be9@cvine--nospam--.freeserve.co.uk> |
| In reply to | #70800 |
On Sun, 29 Dec 2019 22:20:06 -0800 (PST)
Daniel <danielaparker@gmail.com> wrote:
> On Saturday, December 28, 2019 at 4:00:59 PM UTC-5, Chris Vine wrote:
>
> > visitors for std::visit are reasonably easy to write in C++17.
> >
> For some definition of easy, for a contrary opinion, see
>
> https://bitbashing.io/std-visit.html
>
> Do you really find (from https://en.cppreference.com/w/cpp/utility/variant/visit)
>
> std::visit([](auto&& arg) {
> using T = std::decay_t<decltype(arg)>;
> if constexpr (std::is_same_v<T, int>)
> std::cout << "int with value " << arg << '\n';
> else if constexpr (std::is_same_v<T, long>)
> std::cout << "long with value " << arg << '\n';
> else if constexpr (std::is_same_v<T, double>)
> std::cout << "double with value " << arg << '\n';
> else if constexpr (std::is_same_v<T, std::string>)
> std::cout << "std::string with value " << std::quoted(arg) << '\n';
> else
> static_assert(always_false<T>::value, "non-exhaustive visitor!");
> }, w);
>
> to be pleasing to the eye?
Not especially. I do it this way - you only need to write the Visitor
class once, which I think is "reasonably easy" (although I cannot
understand why the standard doesn't provide it):
template <class... Ts>
struct Visitor : Ts... {using Ts::operator()...;};
template <class... Ts> Visitor(Ts&&...) -> Visitor<Ts...>;
Then you can just do something like this
int main() {
using var_t = std::variant<int, long, const char*>;
std::vector<var_t> vars = {1, 2, 3L, "Hello, World!"};
for (auto& v : vars) {
std::visit(Visitor{[](const char* str) { puts(str); },
[](int i) { printf("%d\n", i); },
[](long l) { printf("%ldL\n", l); }
},
v);
}
return 0;
}
Sure, it's not quite as easy to use as proper pattern matching as in
functional languages (Haskell's and SML's 'case' and ocaml's 'match'),
but the way it uses overriding is I think quite clever and highly
efficient.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@i42.removethisbit.co.uk> |
|---|---|
| Date | 2019-12-30 17:07 +0000 |
| Message-ID | <29qOF.79196$zW6.65016@fx24.dcg> |
| In reply to | #70825 |
On 30/12/2019 15:54, Chris Vine wrote:
> On Sun, 29 Dec 2019 22:20:06 -0800 (PST)
> Daniel <danielaparker@gmail.com> wrote:
>> On Saturday, December 28, 2019 at 4:00:59 PM UTC-5, Chris Vine wrote:
>>
>>> visitors for std::visit are reasonably easy to write in C++17.
>>>
>> For some definition of easy, for a contrary opinion, see
>>
>> https://bitbashing.io/std-visit.html
>>
>> Do you really find (from https://en.cppreference.com/w/cpp/utility/variant/visit)
>>
>> std::visit([](auto&& arg) {
>> using T = std::decay_t<decltype(arg)>;
>> if constexpr (std::is_same_v<T, int>)
>> std::cout << "int with value " << arg << '\n';
>> else if constexpr (std::is_same_v<T, long>)
>> std::cout << "long with value " << arg << '\n';
>> else if constexpr (std::is_same_v<T, double>)
>> std::cout << "double with value " << arg << '\n';
>> else if constexpr (std::is_same_v<T, std::string>)
>> std::cout << "std::string with value " << std::quoted(arg) << '\n';
>> else
>> static_assert(always_false<T>::value, "non-exhaustive visitor!");
>> }, w);
>>
>> to be pleasing to the eye?
>
> Not especially. I do it this way - you only need to write the Visitor
> class once, which I think is "reasonably easy" (although I cannot
> understand why the standard doesn't provide it):
>
> template <class... Ts>
> struct Visitor : Ts... {using Ts::operator()...;};
> template <class... Ts> Visitor(Ts&&...) -> Visitor<Ts...>;
>
> Then you can just do something like this
>
> int main() {
> using var_t = std::variant<int, long, const char*>;
> std::vector<var_t> vars = {1, 2, 3L, "Hello, World!"};
>
> for (auto& v : vars) {
> std::visit(Visitor{[](const char* str) { puts(str); },
> [](int i) { printf("%d\n", i); },
> [](long l) { printf("%ldL\n", l); }
> },
> v);
> }
> return 0;
> }
>
> Sure, it's not quite as easy to use as proper pattern matching as in
> functional languages (Haskell's and SML's 'case' and ocaml's 'match'),
> but the way it uses overriding is I think quite clever and highly
> efficient.
Personally I prefer the "if constexpr" approach as one simply has to
grok that "if constexpr" is not the same as "if". Can be hard idiom to
for some to accept as they are ignorant twits assuming that lots of
"if/else constexpr" are bad because lots of "if/else" statements are bad.
/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 | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2019-12-30 19:58 +0000 |
| Message-ID | <20191230195852.f7ed748e122fcf318faec91f@cvine--nospam--.freeserve.co.uk> |
| In reply to | #70829 |
On Mon, 30 Dec 2019 17:07:04 +0000
Mr Flibble <flibble@i42.removethisbit.co.uk> wrote:
> On 30/12/2019 15:54, Chris Vine wrote:
> > On Sun, 29 Dec 2019 22:20:06 -0800 (PST)
> > Daniel <danielaparker@gmail.com> wrote:
> >> On Saturday, December 28, 2019 at 4:00:59 PM UTC-5, Chris Vine wrote:
> >>
> >>> visitors for std::visit are reasonably easy to write in C++17.
> >>>
> >> For some definition of easy, for a contrary opinion, see
> >>
> >> https://bitbashing.io/std-visit.html
> >>
> >> Do you really find (from https://en.cppreference.com/w/cpp/utility/variant/visit)
> >>
> >> std::visit([](auto&& arg) {
> >> using T = std::decay_t<decltype(arg)>;
> >> if constexpr (std::is_same_v<T, int>)
> >> std::cout << "int with value " << arg << '\n';
> >> else if constexpr (std::is_same_v<T, long>)
> >> std::cout << "long with value " << arg << '\n';
> >> else if constexpr (std::is_same_v<T, double>)
> >> std::cout << "double with value " << arg << '\n';
> >> else if constexpr (std::is_same_v<T, std::string>)
> >> std::cout << "std::string with value " << std::quoted(arg) << '\n';
> >> else
> >> static_assert(always_false<T>::value, "non-exhaustive visitor!");
> >> }, w);
> >>
> >> to be pleasing to the eye?
> >
> > Not especially. I do it this way - you only need to write the Visitor
> > class once, which I think is "reasonably easy" (although I cannot
> > understand why the standard doesn't provide it):
> >
> > template <class... Ts>
> > struct Visitor : Ts... {using Ts::operator()...;};
> > template <class... Ts> Visitor(Ts&&...) -> Visitor<Ts...>;
> >
> > Then you can just do something like this
> >
> > int main() {
> > using var_t = std::variant<int, long, const char*>;
> > std::vector<var_t> vars = {1, 2, 3L, "Hello, World!"};
> >
> > for (auto& v : vars) {
> > std::visit(Visitor{[](const char* str) { puts(str); },
> > [](int i) { printf("%d\n", i); },
> > [](long l) { printf("%ldL\n", l); }
> > },
> > v);
> > }
> > return 0;
> > }
> >
> > Sure, it's not quite as easy to use as proper pattern matching as in
> > functional languages (Haskell's and SML's 'case' and ocaml's 'match'),
> > but the way it uses overriding is I think quite clever and highly
> > efficient.
>
> Personally I prefer the "if constexpr" approach as one simply has to
> grok that "if constexpr" is not the same as "if". Can be hard idiom to
> for some to accept as they are ignorant twits assuming that lots of
> "if/else constexpr" are bad because lots of "if/else" statements are bad.
It is impressive that std::visit is built with std::variant in such a
way that the type of the object currently contained by a non-constexpr
variant can be presented in a way which is deducible at compile time in
the visitor function: a requirement for either "if constexpr" or
function overloading to work in the visitor. I haven't fully groked
how it manages to do that since (unlike, say, std::tuple) the actual
contained type is not revealed by the variant's template arguments, and
the results of applying std::variant::index() and
std::holds_alternative() are not constexpr unless the variant is
constexpr.
At some point I must take the time to work out how it is done.
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2019-12-30 23:59 +0000 |
| Message-ID | <20191230235955.f955c63eb24f35d99040ae55@cvine--nospam--.freeserve.co.uk> |
| In reply to | #70837 |
On Mon, 30 Dec 2019 19:58:52 +0000 Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote: [snip] > It is impressive that std::visit is built with std::variant in such a > way that the type of the object currently contained by a non-constexpr > variant can be presented in a way which is deducible at compile time in > the visitor function: a requirement for either "if constexpr" or > function overloading to work in the visitor. I haven't fully groked > how it manages to do that since (unlike, say, std::tuple) the actual > contained type is not revealed by the variant's template arguments, and > the results of applying std::variant::index() and > std::holds_alternative() are not constexpr unless the variant is > constexpr. > > At some point I must take the time to work out how it is done. On reflection, impressive but perhaps not super-impressive. At the conceptual level, std::visit (if it had access to std::variant's privates) could static_cast the address of the start of the variant's storage to the appropriate type conditional upon the variant's index variable (or whatever tag variable the variant keeps), and pass that (dereferenced) to the visitor function. This would be resolved at run time, after which ordinary function overload resolution would kick in for the visitor function.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-12-30 21:23 +0000 |
| Message-ID | <VUtOF.362949$o8x.100334@fx15.am4> |
| In reply to | #70825 |
On 2019-12-30, Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> On Sun, 29 Dec 2019 22:20:06 -0800 (PST)
> Daniel <danielaparker@gmail.com> wrote:
>> On Saturday, December 28, 2019 at 4:00:59 PM UTC-5, Chris Vine wrote:
>>
>> > visitors for std::visit are reasonably easy to write in C++17.
>> >
>> For some definition of easy, for a contrary opinion, see
>>
>> https://bitbashing.io/std-visit.html
>>
>> Do you really find (from https://en.cppreference.com/w/cpp/utility/variant/visit)
>>
>> std::visit([](auto&& arg) {
>> using T = std::decay_t<decltype(arg)>;
>> if constexpr (std::is_same_v<T, int>)
>> std::cout << "int with value " << arg << '\n';
>> else if constexpr (std::is_same_v<T, long>)
>> std::cout << "long with value " << arg << '\n';
>> else if constexpr (std::is_same_v<T, double>)
>> std::cout << "double with value " << arg << '\n';
>> else if constexpr (std::is_same_v<T, std::string>)
>> std::cout << "std::string with value " << std::quoted(arg) << '\n';
>> else
>> static_assert(always_false<T>::value, "non-exhaustive visitor!");
>> }, w);
>>
>> to be pleasing to the eye?
>
> Not especially. I do it this way - you only need to write the Visitor
> class once, which I think is "reasonably easy" (although I cannot
> understand why the standard doesn't provide it):
>
> template <class... Ts>
> struct Visitor : Ts... {using Ts::operator()...;};
> template <class... Ts> Visitor(Ts&&...) -> Visitor<Ts...>;
>
> Then you can just do something like this
>
> int main() {
> using var_t = std::variant<int, long, const char*>;
> std::vector<var_t> vars = {1, 2, 3L, "Hello, World!"};
>
> for (auto& v : vars) {
> std::visit(Visitor{[](const char* str) { puts(str); },
> [](int i) { printf("%d\n", i); },
> [](long l) { printf("%ldL\n", l); }
> },
> v);
> }
> return 0;
> }
>
> Sure, it's not quite as easy to use as proper pattern matching as in
> functional languages (Haskell's and SML's 'case' and ocaml's 'match'),
> but the way it uses overriding is I think quite clever and highly
> efficient.
Haskell does not requires case, you can just specify type in severeal
functions.
eg
fun (T1 a) = ...
fun (T2 a b) = ...
....
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2019-12-28 18:09 -0800 |
| Message-ID | <bc54bf7a-3c22-4805-bb59-676422ccde5b@googlegroups.com> |
| In reply to | #70732 |
On Saturday, December 28, 2019 at 7:05:39 AM UTC-5, bol...@nowhere.org wrote: > On Fri, 27 Dec 2019 09:41:26 -0800 (PST) > >> > >Then what exactly is your point? Are you suggesting that > >std::vector<std::optional<T>> is inferior to some other way of storing a > >collection of optional values? What other way are you thinking of? > > I give up Fair enough. That's the way it goes sometimes. Best regards, Daniel
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@i42.removethisbit.co.uk> |
|---|---|
| Date | 2019-12-26 18:30 +0000 |
| Message-ID | <M_6NF.45329$pk7.33071@fx05.dcg> |
| In reply to | #70667 |
On 26/12/2019 17:33, boltar@nowhere.org wrote:
> On Thu, 26 Dec 2019 16:38:12 +0200
> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> On 26.12.2019 11:46, boltar@nowhere.org wrote:
>>> Of course dynamic memory allocation takes place - its not going to be on
>>> the stack if its in a container is it?
>>
>> If a std::optional is stored as an automatic variable then of course it
>> is allocated at stack. Where else? And this includes also its contained
>> value, as there is absolutely no reason to allocate it dynamically.
>
> For some noddy function. If however you have a container that is added to
> based on some operation in a loop its hardly going to be allocated on the
> stack is it? (Unless you use an allocator that uses alloca() or similar. And
> good luck with that).
>
>> value contained in a std::optional is allocated. You can run it with
>> your favorite C++ compiler if you don't trust mine.
>
> A contrived example. Now allocate optionals containing objects in a loop.
#include <optional>
#include <iostream>
int main()
{
std::optional<int> o = 42;
std::cout << "address of optional on stack: " << std::hex << &o
<< std::endl;
std::cout << "address of optional contained value: " <<
std::hex << &*o << std::endl;
}
Output:
address of optional on stack: 0x7ffc35b03890
address of optional contained value: 0x7ffc35b03890
Now will you please fuck off you deliberately obtuse idiot.
/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 | 2019-12-27 17:17 +0000 |
| Message-ID | <qu5eal$1lcf$1@gioia.aioe.org> |
| In reply to | #70669 |
On Thu, 26 Dec 2019 18:30:02 +0000
Mr Flibble <flibble@i42.removethisbit.co.uk> wrote:
>On 26/12/2019 17:33, boltar@nowhere.org wrote:
>> On Thu, 26 Dec 2019 16:38:12 +0200
>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>> On 26.12.2019 11:46, boltar@nowhere.org wrote:
>>>> Of course dynamic memory allocation takes place - its not going to be on
>>>> the stack if its in a container is it?
>>>
>>> If a std::optional is stored as an automatic variable then of course it
>>> is allocated at stack. Where else? And this includes also its contained
>>> value, as there is absolutely no reason to allocate it dynamically.
>>
>> For some noddy function. If however you have a container that is added to
>> based on some operation in a loop its hardly going to be allocated on the
>> stack is it? (Unless you use an allocator that uses alloca() or similar. And
>> good luck with that).
>>
>>> value contained in a std::optional is allocated. You can run it with
>>> your favorite C++ compiler if you don't trust mine.
>>
>> A contrived example. Now allocate optionals containing objects in a loop.
>
>#include <optional>
>#include <iostream>
>
>int main()
>{
> std::optional<int> o = 42;
> std::cout << "address of optional on stack: " << std::hex << &o
><< std::endl;
> std::cout << "address of optional contained value: " <<
>std::hex << &*o << std::endl;
>}
>
>Output:
>address of optional on stack: 0x7ffc35b03890
>address of optional contained value: 0x7ffc35b03890
Fascinating.
>Now will you please fuck off you deliberately obtuse idiot.
Now why not go write yourself a program that, oh I don't know, loads in
biological data points as the OP was talking about in a fucking loop creating
data objects as it goes and try and store them on the stack without writing
your own allocator that uses alloca() or similar API stack functions.
Good luck, get back to me when you're done.
[toc] | [prev] | [next] | [standalone]
Page 11 of 16 — ← Prev page 1 … 9 10 [11] 12 13 … 16 Next page →
Back to top | Article view | comp.lang.c++
csiph-web