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 4 of 16 — ← Prev page 1 2 3 [4] 5 6 … 16 Next page →
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-25 00:30 +0200 |
| Message-ID | <qtu3in$t56$1@dont-email.me> |
| In reply to | #70629 |
On 24.12.2019 11:49, boltar@nowhere.org wrote: > On Mon, 23 Dec 2019 19:17:12 +0200 > Paavo Helde <myfirstname@osa.pri.ee> wrote: >> The objects don't need to be exactly adjacent in order to end up in the >> same cache line. > > Cache line or cache? Cache lines are tiny and it wouldn't take a large object > for a complete miss. As for the cache - that depends on how the allocater > allocates memory, if the memory is already fragmented there is no guarantee > that 2 allocations will be anywhere near each other in virtual memory in which > case the cache will miss one or more of them. We are not talking about dynamic allocation here. FYI: this subthread is about the value objects contained in std::optional. This url might be helpful for you to understand the difference between dynamic memory allocation and automatic storage duration: https://en.cppreference.com/w/cpp/utility/optional "If an optional<T> contains a value, the value is guaranteed to be allocated as part of the optional object footprint, i.e. no dynamic memory allocation ever takes place. Thus, an optional object models an object, not a pointer, even though operator*() and operator->() are defined."
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-26 09:46 +0000 |
| Message-ID | <qu1vhf$1vn6$1@gioia.aioe.org> |
| In reply to | #70638 |
On Wed, 25 Dec 2019 00:30:46 +0200 Paavo Helde <myfirstname@osa.pri.ee> wrote: >On 24.12.2019 11:49, boltar@nowhere.org wrote: >> On Mon, 23 Dec 2019 19:17:12 +0200 >> Paavo Helde <myfirstname@osa.pri.ee> wrote: >>> The objects don't need to be exactly adjacent in order to end up in the >>> same cache line. >> >> Cache line or cache? Cache lines are tiny and it wouldn't take a large object > >> for a complete miss. As for the cache - that depends on how the allocater >> allocates memory, if the memory is already fragmented there is no guarantee >> that 2 allocations will be anywhere near each other in virtual memory in >which >> case the cache will miss one or more of them. > >We are not talking about dynamic allocation here. > >FYI: this subthread is about the value objects contained in >std::optional. This url might be helpful for you to understand the >difference between dynamic memory allocation and automatic storage duration: > >https://en.cppreference.com/w/cpp/utility/optional > >"If an optional<T> contains a value, the value is guaranteed to be >allocated as part of the optional object footprint, i.e. no dynamic >memory allocation ever takes place. Thus, an optional object models an Of course dynamic memory allocation takes place - its not going to be on the stack if its in a container is it? It might be implicit rather than explicit but its still dynamic and as such is subject to where the allocator puts it.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-26 16:38 +0200 |
| Message-ID | <qu2gkl$hqr$1@dont-email.me> |
| In reply to | #70660 |
On 26.12.2019 11:46, boltar@nowhere.org wrote:
> On Wed, 25 Dec 2019 00:30:46 +0200
> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> On 24.12.2019 11:49, boltar@nowhere.org wrote:
>>> On Mon, 23 Dec 2019 19:17:12 +0200
>>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>>> The objects don't need to be exactly adjacent in order to end up in the
>>>> same cache line.
>>>
>>> Cache line or cache? Cache lines are tiny and it wouldn't take a large object
>>
>>> for a complete miss. As for the cache - that depends on how the allocater
>>> allocates memory, if the memory is already fragmented there is no guarantee
>>> that 2 allocations will be anywhere near each other in virtual memory in
>> which
>>> case the cache will miss one or more of them.
>>
>> We are not talking about dynamic allocation here.
>>
>> FYI: this subthread is about the value objects contained in
>> std::optional. This url might be helpful for you to understand the
>> difference between dynamic memory allocation and automatic storage duration:
>>
>> https://en.cppreference.com/w/cpp/utility/optional
>>
>> "If an optional<T> contains a value, the value is guaranteed to be
>> allocated as part of the optional object footprint, i.e. no dynamic
>> memory allocation ever takes place. Thus, an optional object models an
>
> 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.
> It might be implicit rather than
> explicit but its still dynamic and as such is subject to where the allocator
> puts it.
Fortunately programming is a concrete field and one can answer concrete
enough questions factually, no need to decide anything be shouting
louder than others. Here is a little program to find out where a class A
value contained in a std::optional is allocated. You can run it with
your favorite C++ compiler if you don't trust mine.
#include <optional>
#include <iostream>
class A {
public:
A(int a) : a_(a) {}
void foo() const {
std::cout << "Hello, I'm an A at address: " << this << "\n";
}
private:
int a_;
};
int main() {
int x = 1;
std::optional opt1 = A(42);
int y = 2;
std::cout << "Stack variable x is at address: " << &x << "\n";
std::cout << "Stack variable y is at address: " << &y << "\n";
opt1->foo();
}
Output:
Stack variable x is at address: 00000000002CF874
Stack variable y is at address: 00000000002CF8B4
Hello, I'm an A at address: 00000000002CF898
So, what's next? Will you claim that x and y are not stack variables? Or
will you deny 0x2CF898 lies between 0x2CF874 and 0x2CF8B4? Or will you
say that the dynamic allocator somehow is able to use memory space
between two stack variables for a dynamic allocation? Or will you say
that all existing implementations of std::optional are wrong in storing
the value on stack and should use the more expensive dynamic allocation
instead?
Note that if the value contained in a std::optional would be indeed
allocated dynamically, there would be no need for std::optional in the
first place as then one would have a (raw or smart) pointer pointing to
this dynamically allocated value, and one could just use the special
nullptr value for indicating the "missing value" condition.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-26 17:33 +0000 |
| Message-ID | <qu2qtb$1taa$1@gioia.aioe.org> |
| In reply to | #70663 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-26 19:52 +0200 |
| Message-ID | <qu2s15$ent$1@dont-email.me> |
| In reply to | #70667 |
On 26.12.2019 19: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). True for some kind of containers, but std::optional is not one of those. > >> 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. You cannot refute direct evidence just be calling it "contrived" (which it isn't). And loops have nothing to do with how std::optional works.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-27 17:14 +0000 |
| Message-ID | <qu5e6j$1kjq$1@gioia.aioe.org> |
| In reply to | #70668 |
On Thu, 26 Dec 2019 19:52:36 +0200 Paavo Helde <myfirstname@osa.pri.ee> wrote: >On 26.12.2019 19: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). > >True for some kind of containers, but std::optional is not one of those. The whole point of this discussion is optionals being used inside standard STL containers. >>> 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. > >You cannot refute direct evidence just be calling it "contrived" (which >it isn't). And loops have nothing to do with how std::optional works. It is contrived since any non trivial program will create and destroy depending on processing factors. They're not predeclared beforehand so they can be stored on the stack!
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2019-12-27 09:41 -0800 |
| Message-ID | <79fbc109-a9d8-47a2-a150-a74b09de4d75@googlegroups.com> |
| In reply to | #70689 |
On Friday, December 27, 2019 at 12:15:13 PM UTC-5, bol...@nowhere.org wrote: > > The whole point of this discussion is optionals being used inside standard > STL containers. > 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? Thanks, Daniel
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-28 12:05 +0000 |
| Message-ID | <qu7gea$rhc$1@gioia.aioe.org> |
| In reply to | #70692 |
On Fri, 27 Dec 2019 09:41:26 -0800 (PST) Daniel <danielaparker@gmail.com> wrote: >On Friday, December 27, 2019 at 12:15:13 PM UTC-5, bol...@nowhere.org wrote: >> >> The whole point of this discussion is optionals being used inside standard >> STL containers. >> >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 , its like talking to geese sometimes.
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2019-12-28 21:01 +0000 |
| Message-ID | <20191228210102.7a79a100573646105f604b46@cvine--nospam--.freeserve.co.uk> |
| In reply to | #70732 |
On Sat, 28 Dec 2019 12:05:30 +0000 (UTC) boltar@nowhere.org wrote: > On Fri, 27 Dec 2019 09:41:26 -0800 (PST) > Daniel <danielaparker@gmail.com> wrote: > >On Friday, December 27, 2019 at 12:15:13 PM UTC-5, bol...@nowhere.org wrote: > >> > >> The whole point of this discussion is optionals being used inside standard > >> STL containers. > >> > >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 , 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 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 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-29 09:00 +0000 |
| Message-ID | <qu9puo$155k$1@gioia.aioe.org> |
| In reply to | #70743 |
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: >> On Fri, 27 Dec 2019 09:41:26 -0800 (PST) >> Daniel <danielaparker@gmail.com> wrote: >> >On Friday, December 27, 2019 at 12:15:13 PM UTC-5, bol...@nowhere.org wrote: > >> >> >> >> The whole point of this discussion is optionals being used inside standard > >> >> STL containers. >> >> >> >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 , 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. >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. >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. >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).
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-29 12:21 +0200 |
| Message-ID | <qu9ung$fhu$1@dont-email.me> |
| In reply to | #70758 |
On 29.12.2019 11:00, boltar@nowhere.org wrote: > The whole point of C unions is that they're NOT type safe. A type safe union > is a contradiction. In case you haven't noticed yet we are talking C++ here, not C. A major strength of C++ is to build higher level abstractions, in particular typesafe and zero overhead abstractions over low-level unsafe primitives like C unions.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-29 18:30 +0000 |
| Message-ID | <quarce$1tq7$1@gioia.aioe.org> |
| In reply to | #70765 |
On Sun, 29 Dec 2019 12:21:33 +0200 Paavo Helde <myfirstname@osa.pri.ee> wrote: >On 29.12.2019 11:00, boltar@nowhere.org wrote: > >> The whole point of C unions is that they're NOT type safe. A type safe union >> is a contradiction. > >In case you haven't noticed yet we are talking C++ here, not C. A major >strength of C++ is to build higher level abstractions, in particular >typesafe and zero overhead abstractions over low-level unsafe primitives >like C unions. The whole point of a union is not to save memory, its to write as one type and read as another , eg fill a char buffer from a network interface and read it out as packet fields. An "unsafe" C union would be a useless C union. And as such a variant is not a union. I'm sure it has its niche uses but I've yet to see a convincing one that couldn't have been done in a clearer more expandable way.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-29 21:45 +0200 |
| Message-ID | <quavoc$522$1@dont-email.me> |
| In reply to | #70776 |
On 29.12.2019 20:30, boltar@nowhere.org wrote: > On Sun, 29 Dec 2019 12:21:33 +0200 > Paavo Helde <myfirstname@osa.pri.ee> wrote: >> On 29.12.2019 11:00, boltar@nowhere.org wrote: >> >>> The whole point of C unions is that they're NOT type safe. A type safe union >>> is a contradiction. >> >> In case you haven't noticed yet we are talking C++ here, not C. A major >> strength of C++ is to build higher level abstractions, in particular >> typesafe and zero overhead abstractions over low-level unsafe primitives >> like C unions. > > The whole point of a union is not to save memory, its to write as one type > and read as another , You wish. However, this is undefined behavior by the standard. 12.3 [class.union]: "In a union, a non-static data member is active if its name refers to an object whose lifetime has begun and has not ended (6.8). At most one of the non-static data members of an object of union type can be active at any time." Accessing an object outside of its lifetime is UB. The only exception is for matching common initial sequences, which is not what you are talking about. It's true that some C++ implementations support type punning via unions as an extension, but by the letter of standard this is still UB and relying on this will make the code unportable. > eg fill a char buffer from a network interface and read > it out as packet fields. There is no special exception for unions containing a char array.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-30 10:10 +0000 |
| Message-ID | <qucif8$1oa0$1@gioia.aioe.org> |
| In reply to | #70779 |
On Sun, 29 Dec 2019 21:45:14 +0200
Paavo Helde <myfirstname@osa.pri.ee> wrote:
>On 29.12.2019 20:30, boltar@nowhere.org wrote:
>> On Sun, 29 Dec 2019 12:21:33 +0200
>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>> On 29.12.2019 11:00, boltar@nowhere.org wrote:
>>>
>>>> The whole point of C unions is that they're NOT type safe. A type safe
>union
>>>> is a contradiction.
>>>
>>> In case you haven't noticed yet we are talking C++ here, not C. A major
>>> strength of C++ is to build higher level abstractions, in particular
>>> typesafe and zero overhead abstractions over low-level unsafe primitives
>>> like C unions.
>>
>> The whole point of a union is not to save memory, its to write as one type
>> and read as another ,
>
>You wish. However, this is undefined behavior by the standard.
Oh dear, someone better tell the authors of the standard unix networking
libraries then. Clearly they have no clue, I mean look at this horror from
net/if.h:
struct ifreq {
#ifndef IFNAMSIZ
#define IFNAMSIZ IF_NAMESIZE
#endif
char ifr_name[IFNAMSIZ]; /* if name, e.g. "en0" */
union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
short ifru_flags;
int ifru_metric;
int ifru_mtu;
int ifru_phys;
int ifru_media;
int ifru_intval;
caddr_t ifru_data;
etc etc etc.
In fact:
fenris$ grep union $(find usr/include -name "*.h") | wc -l
386
>> eg fill a char buffer from a network interface and read
>> it out as packet fields.
>
>There is no special exception for unions containing a char array.
Uh huh. Go do some systems programming one day then get back to me.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-30 14:03 +0200 |
| Message-ID | <qucp27$m3n$1@dont-email.me> |
| In reply to | #70805 |
On 30.12.2019 12:10, boltar@nowhere.org wrote: > On Sun, 29 Dec 2019 21:45:14 +0200 > Paavo Helde <myfirstname@osa.pri.ee> wrote: >> On 29.12.2019 20:30, boltar@nowhere.org wrote: >>> On Sun, 29 Dec 2019 12:21:33 +0200 >>> Paavo Helde <myfirstname@osa.pri.ee> wrote: >>>> On 29.12.2019 11:00, boltar@nowhere.org wrote: >>>> >>>>> The whole point of C unions is that they're NOT type safe. A type safe >> union >>>>> is a contradiction. >>>> >>>> In case you haven't noticed yet we are talking C++ here, not C. A major >>>> strength of C++ is to build higher level abstractions, in particular >>>> typesafe and zero overhead abstractions over low-level unsafe primitives >>>> like C unions. >>> >>> The whole point of a union is not to save memory, its to write as one type >>> and read as another , >> >> You wish. However, this is undefined behavior by the standard. > > Oh dear, someone better tell the authors of the standard unix networking > libraries then. Clearly they have no clue, I mean look at this horror from > net/if.h: There is no problem with unions when they are used correctly. This means one can only read the union member which was written last. I am sure Unix programmers know all about this. > > fenris$ grep union $(find usr/include -name "*.h") | wc -l > 386 What's your point in grepping the source code for "union"? Union is not a prohibited word, neither in C++ nor in C, and can be used perfectly fine, assuming one is able to follow a few simple rules.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-30 12:17 +0000 |
| Message-ID | <qucptj$smc$1@gioia.aioe.org> |
| In reply to | #70810 |
On Mon, 30 Dec 2019 14:03:18 +0200
Paavo Helde <myfirstname@osa.pri.ee> wrote:
>On 30.12.2019 12:10, boltar@nowhere.org wrote:
>> On Sun, 29 Dec 2019 21:45:14 +0200
>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>> On 29.12.2019 20:30, boltar@nowhere.org wrote:
>>>> On Sun, 29 Dec 2019 12:21:33 +0200
>>>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>>>> On 29.12.2019 11:00, boltar@nowhere.org wrote:
>>>>>
>>>>>> The whole point of C unions is that they're NOT type safe. A type safe
>>> union
>>>>>> is a contradiction.
>>>>>
>>>>> In case you haven't noticed yet we are talking C++ here, not C. A major
>>>>> strength of C++ is to build higher level abstractions, in particular
>>>>> typesafe and zero overhead abstractions over low-level unsafe primitives
>>>>> like C unions.
>>>>
>>>> The whole point of a union is not to save memory, its to write as one type
>>>> and read as another ,
>>>
>>> You wish. However, this is undefined behavior by the standard.
>>
>> Oh dear, someone better tell the authors of the standard unix networking
>> libraries then. Clearly they have no clue, I mean look at this horror from
>> net/if.h:
>
>There is no problem with unions when they are used correctly. This means
>one can only read the union member which was written last. I am sure
Complete rubbish. The point of a union is to write as one thing and read as
another otherwise there is NO point in using a union since saving a few bytes
of memory is utterly irrelevant in the 21st century unless doing PIC or other
embedded programming.
Here's another example, see if you can figure it out. If you can't then perhaps
stay silent on a subject you clearly know the square root of nothing about:
union un_pkt
{
u_char packet[ETH_FRAME_LEN];
struct ip ip;
struct ip6_hdr ip6;
};
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-30 04:39 -0800 |
| Message-ID | <61d5c593-1c53-4097-b69e-cb519dec0749@googlegroups.com> |
| In reply to | #70811 |
On Monday, 30 December 2019 14:18:05 UTC+2, bol...@nowhere.org wrote:
> On Mon, 30 Dec 2019 14:03:18 +0200
> Paavo Helde <myfirstname@osa.pri.ee> wrote:
> >On 30.12.2019 12:10, boltar@nowhere.org wrote:
> >> On Sun, 29 Dec 2019 21:45:14 +0200
> >> Paavo Helde <myfirstname@osa.pri.ee> wrote:
> >>> On 29.12.2019 20:30, boltar@nowhere.org wrote:
> >>>> On Sun, 29 Dec 2019 12:21:33 +0200
> >>>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
> >>>>> On 29.12.2019 11:00, boltar@nowhere.org wrote:
> >>>>>
> >>>>>> The whole point of C unions is that they're NOT type safe. A type safe
> >>> union
> >>>>>> is a contradiction.
> >>>>>
> >>>>> In case you haven't noticed yet we are talking C++ here, not C. A major
> >>>>> strength of C++ is to build higher level abstractions, in particular
> >>>>> typesafe and zero overhead abstractions over low-level unsafe primitives
> >>>>> like C unions.
> >>>>
> >>>> The whole point of a union is not to save memory, its to write as one type
> >>>> and read as another ,
> >>>
> >>> You wish. However, this is undefined behavior by the standard.
> >>
> >> Oh dear, someone better tell the authors of the standard unix networking
> >> libraries then. Clearly they have no clue, I mean look at this horror from
> >> net/if.h:
> >
> >There is no problem with unions when they are used correctly. This means
> >one can only read the union member which was written last. I am sure
>
> Complete rubbish. The point of a union is to write as one thing and read as
> another otherwise there is NO point in using a union since saving a few bytes
> of memory is utterly irrelevant in the 21st century unless doing PIC or other
> embedded programming.
So the example you brought was meant to be used like that? Let me quote:
"union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
short ifru_flags;
int ifru_metric;
int ifru_mtu;
int ifru_phys;
int ifru_media;
int ifru_intval;
caddr_t ifru_data;
etc etc etc."
Show me where they write into ifru_data and read from fru_broadaddr. :D
I am actually happy that people like you have started to post topical
nonsense in this group. Otherwise it was off topic philosophy and
boring pickering about coding style. Nothing entertaining.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-30 13:01 +0000 |
| Message-ID | <qucsfl$18vp$1@gioia.aioe.org> |
| In reply to | #70812 |
On Mon, 30 Dec 2019 04:39:41 -0800 (PST)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Monday, 30 December 2019 14:18:05 UTC+2, bol...@nowhere.org wrote:
>> On Mon, 30 Dec 2019 14:03:18 +0200
>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> >On 30.12.2019 12:10, boltar@nowhere.org wrote:
>> >> On Sun, 29 Dec 2019 21:45:14 +0200
>> >> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> >>> On 29.12.2019 20:30, boltar@nowhere.org wrote:
>> >>>> On Sun, 29 Dec 2019 12:21:33 +0200
>> >>>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> >>>>> On 29.12.2019 11:00, boltar@nowhere.org wrote:
>> >>>>>
>> >>>>>> The whole point of C unions is that they're NOT type safe. A type safe
>
>> >>> union
>> >>>>>> is a contradiction.
>> >>>>>
>> >>>>> In case you haven't noticed yet we are talking C++ here, not C. A major
>
>> >>>>> strength of C++ is to build higher level abstractions, in particular
>> >>>>> typesafe and zero overhead abstractions over low-level unsafe
>primitives
>> >>>>> like C unions.
>> >>>>
>> >>>> The whole point of a union is not to save memory, its to write as one
>type
>> >>>> and read as another ,
>> >>>
>> >>> You wish. However, this is undefined behavior by the standard.
>> >>
>> >> Oh dear, someone better tell the authors of the standard unix networking
>> >> libraries then. Clearly they have no clue, I mean look at this horror from
>
>> >> net/if.h:
>> >
>> >There is no problem with unions when they are used correctly. This means
>> >one can only read the union member which was written last. I am sure
>>
>> Complete rubbish. The point of a union is to write as one thing and read as
>> another otherwise there is NO point in using a union since saving a few bytes
>
>> of memory is utterly irrelevant in the 21st century unless doing PIC or other
>
>> embedded programming.
>
>So the example you brought was meant to be used like that? Let me quote:
Translation: "Oh, your 2nd example blew my argument out of the water, let me
quickly backpedal a bit and try and catch you out with the 1st one"
>
>"union {
> struct sockaddr ifru_addr;
> struct sockaddr ifru_dstaddr;
> struct sockaddr ifru_broadaddr;
> short ifru_flags;
> int ifru_metric;
> int ifru_mtu;
> int ifru_phys;
> int ifru_media;
> int ifru_intval;
> caddr_t ifru_data;
>
>etc etc etc."
>
>Show me where they write into ifru_data and read from fru_broadaddr. :D
You wouldn't , its a pointer not an array. But you would read from the addr
structures interchangably.
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 am actually happy that people like you have started to post topical
>nonsense in this group. Otherwise it was off topic philosophy and
>boring pickering about coding style. Nothing entertaining.
You're welcome.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-30 15:17 +0200 |
| Message-ID | <quctdn$dck$1@dont-email.me> |
| In reply to | #70814 |
On 30.12.2019 15: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);
> }
This agrees with what I wrote ca 6 messages up-thread: "It's true that
some C++ implementations support type punning via unions as an
extension, but by the letter of standard this is still UB and relying on
this will make the code unportable."
Your example presents a function defined by the C or C++ implementation.
It even has the reserved name "__inline_signbitf" which stresses this fact.
An implementation can define and use behavior which is UB by the
standard. This code is still non-portable. However, as it is part of the
implementation, there is no need for it to be portable.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-30 14:22 +0100 |
| Message-ID | <quctm7$5g5$1@news.albasani.net> |
| In reply to | #70814 |
> 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);
> }
>
In C++ you could do: (int)((unsigned &)x >> 31)
[toc] | [prev] | [next] | [standalone]
Page 4 of 16 — ← Prev page 1 2 3 [4] 5 6 … 16 Next page →
Back to top | Article view | comp.lang.c++
csiph-web