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 3 of 16 — ← Prev page 1 2 [3] 4 5 … 16 Next page →
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-20 10:36 -0800 |
| Message-ID | <d48adc41-fd44-4879-b313-62edffc881e4@googlegroups.com> |
| In reply to | #70592 |
On Friday, 20 December 2019 18:28:29 UTC+2, bol...@nowhere.co.uk wrote: > On Fri, 20 Dec 2019 04:35:37 -0800 (PST) > =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: > >On Friday, 20 December 2019 11:25:53 UTC+2, bol...@nowhere.co.uk wrote: > >> On Thu, 19 Dec 2019 20:26:55 +0000 > >> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote: > >> >On 19/12/2019 08:42, boltar@nowhere.co.uk wrote: > >> >> On Wed, 18 Dec 2019 19:56:04 +0000 > >> >> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote: > >> >>> On 18/12/2019 19:23, Daniel wrote: > >> >>>> On Wednesday, December 18, 2019 at 2:12:03 PM UTC-5, Mr Flibble wrote: > >> >>>>> On 18/12/2019 16:26, boltar@nowhere.co.uk wrote: > >> >>>>>> > >> >>>>>> And you think creating an instance of optional for a function return > >just > >> > > >> >>>>> to signify a valid return value and then having to call a method to get > > > >> >the > >> >>>>> actual contained instance is efficient? > >> >>>>> > >> >>>>> That isn't using optionals properly > >> >>>>> > >> >>>> You wouldn't use optional for a function return? > >> >>> > >> >>> Ah, I misread what "boltar" said; obviously using them for function > >return > >> >is > >> >>> fine and calling a method to get the contained value is not an issue like > > > >> >>> "boltar" suggests. > >> >> > >> >> I never said it was an issue, I said it was pointless and inefficient. > >> > > >> >"pointless" : subjective! > >> > >> If something adds nothing except complexity its pointless. > >> > >> >"inefficient: compared to what? > >> > >> Compared to not using it. > > > >But how you "do not use" it?: > > How did you manage to write code before? Its just yet more noise. Lack of answer noted. :D Pathetic snip of shameful strategies that you likely use also noted. I answer later in post. > >5) You use certain "magical" values of your objects to encode > >that it is missing? > >So LONG_MIN means long is missing and INT_MIN that int is > >missing and so on? How to make difference between missing > >and known to be empty sd::vector? Again annoyingly error-prone > >approach. > > Or you could throw an exception if there's an error and you don't want to > return that as a special value or instance flag. > > Or pass in an error parameter. The case of using optional is when lack of value is *not* *an* *error*. Exceptions just waste resources and how you store it instead of value? Can't be you read nothing of what you snipped in humiliation. > >That tends to clearly make it even worse, more confusing and > >likely less efficient. Your own code is like bear trap against > >yourself and your teammates. > > How did we manage before 2017. Its a mystery. Huh? Second time same question? :D Fishing for ideas since you snipped all the obviously embarrassing and inferior to optional strategies that you use? :D But masters are here for to teach. And I haven't hidden it. Lot of the code-bases are still in usage. Tagged unions or variants from various libraries until when I read about Barton-Nackman's fallible<T> and about 2005 I started to use mostly Boost.Optionals/Variants since these were well made and behaved nicely in tests. In fact I have migrated to std::variant/optional only in few code-bases. Why to bother when things already work? > >Lot cheaper and cleaner is to use missing state of types that > >already naturally have it (like pointers and floating points) > >and for anything else that may be unknown or missing to use > >std::optional. > > Yeah, lets just create pointless object instances all over the place just > to indicate valid returns. Very efficient. I think you'd like Java. These beat all the embarrassing strategies that you snipped in performance ... and you did fail to tell what is your alternative "superior" method ... so sorry ... foaming mouth is not argument. :D
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.co.uk |
|---|---|
| Date | 2019-12-21 16:33 +0000 |
| Message-ID | <qtlhgf$gij$1@gioia.aioe.org> |
| In reply to | #70593 |
On Fri, 20 Dec 2019 10:36:14 -0800 (PST) =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: >On Friday, 20 December 2019 18:28:29 UTC+2, bol...@nowhere.co.uk wrote: >> >But how you "do not use" it?: >> >> How did you manage to write code before? Its just yet more noise. > >Lack of answer noted. :D Pathetic snip of shameful strategies that >you likely use also noted. I answer later in post. It was a question to make you think. Clearly either you can't or you have the memory of a goldfish and can't remember how you programmed yesterday, never mind before 2017. >> Or you could throw an exception if there's an error and you don't want to >> return that as a special value or instance flag. >> >> Or pass in an error parameter. > >The case of using optional is when lack of value is *not* *an* >*error*. Exceptions just waste resources and how you store it Exceptions only use resources if thrown, optional uses resources every time its used. And if you want lack-of-value to be a valid return type then write your code in PL/SQL or tSql. This is C++, it deals in boolean logic, not "I don't know". >> How did we manage before 2017. Its a mystery. > >Huh? Second time same question? :D Fishing for ideas since you A simple question you still can't answer. >snipped all the obviously embarrassing and inferior to optional >strategies that you use? :D But masters are here for to teach. Teach what? Not English grammar thats for sure. And all I see is a load of indignation and no arguments for your case. >in usage. Tagged unions or variants from various libraries until >when I read about Barton-Nackman's fallible<T> and about 2005 I "Look at me - I read a paper by someone hardly anyone one has heard of 14 years ago, I must be a l33t coder 4sure!" >> Yeah, lets just create pointless object instances all over the place just >> to indicate valid returns. Very efficient. I think you'd like Java. > >These beat all the embarrassing strategies that you snipped in The embarrasing strategies that have been used perfectly well for 20+ years? Did you just start coding yesterday? >performance ... and you did fail to tell what is your alternative >"superior" method ... so sorry ... foaming mouth is not argument. :D Hilarious, you should do stand up comedy. I gave the options, if you can't understand them thats your problem, not mine.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-21 09:11 -0800 |
| Message-ID | <0bdee356-d78c-4233-bd8e-81fe17f243f2@googlegroups.com> |
| In reply to | #70598 |
On Saturday, 21 December 2019 18:33:30 UTC+2, bol...@nowhere.co.uk wrote: > On Fri, 20 Dec 2019 10:36:14 -0800 (PST) > =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: > >On Friday, 20 December 2019 18:28:29 UTC+2, bol...@nowhere.co.uk wrote: > >> >But how you "do not use" it?: > >> > >> How did you manage to write code before? Its just yet more noise. > > > >Lack of answer noted. :D Pathetic snip of shameful strategies that > >you likely use also noted. I answer later in post. > > It was a question to make you think. Clearly either you can't or you have the > memory of a goldfish and can't remember how you programmed yesterday, never > mind before 2017. I started to program biotech applications in eighties. There are long lasting experiments often lasting for days but equipment was often experimental and hiccuping, probes could get contaminated etc. It was common that at least some measurements were missing for one or other time point. Should they throw away the whole experiment data? No, experiments were expensive and there was plenty of information. Should they somehow fake data for measurements that failed? No, science can't be made from fake data. But lack of data is *normal* state of affairs in world we live in. So I used tagged unions to store such points already in C in eighties before I switched to C++. > > >> Or you could throw an exception if there's an error and you don't want to > >> return that as a special value or instance flag. > >> > >> Or pass in an error parameter. > > > >The case of using optional is when lack of value is *not* *an* > >*error*. Exceptions just waste resources and how you store it > > Exceptions only use resources if thrown, optional uses resources every time > its used. And if you want lack-of-value to be a valid return type then write > your code in PL/SQL or tSql. This is C++, it deals in boolean logic, not > "I don't know". Nonsense, bool was added to C++ by C++98, I used C++ *long* before that. <https://en.cppreference.com/w/cpp/language/history> I don't know is default answer to every question. Knowledge is rarity. > >> How did we manage before 2017. Its a mystery. > > > >Huh? Second time same question? :D Fishing for ideas since you > > A simple question you still can't answer. > > >snipped all the obviously embarrassing and inferior to optional > >strategies that you use? :D But masters are here for to teach. > > Teach what? Not English grammar thats for sure. And all I see is a load of > indignation and no arguments for your case. If you can't comprehend me then I don't really care, go discuss stuff with fir. > >in usage. Tagged unions or variants from various libraries until > >when I read about Barton-Nackman's fallible<T> and about 2005 I > > "Look at me - I read a paper by someone hardly anyone one has heard > of 14 years ago, I must be a l33t coder 4sure!" Only utter moron denies contributions of John J. Barton and Lee R. Nackman to our industry. Pathetic snip of answer noted again. :D > > >> Yeah, lets just create pointless object instances all over the place just > >> to indicate valid returns. Very efficient. I think you'd like Java. > > > >These beat all the embarrassing strategies that you snipped in > > The embarrasing strategies that have been used perfectly well for 20+ years? > Did you just start coding yesterday? I said I have frowned upon that inefficient crap from eighties. Optional and Variant are just well-made tagged unions. > > >performance ... and you did fail to tell what is your alternative > >"superior" method ... so sorry ... foaming mouth is not argument. :D > > Hilarious, you should do stand up comedy. > > I gave the options, if you can't understand them thats your problem, not mine. You have only said that you throw exceptions to perfectly normal case of missing data. Your style: Find closest human in room. No humans in room found exception thrown. Program crashed with uncaught exception. Wtf you can program like that? Clown. :D
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.co.uk |
|---|---|
| Date | 2019-12-21 17:22 +0000 |
| Message-ID | <qtlkbs$trs$1@gioia.aioe.org> |
| In reply to | #70600 |
On Sat, 21 Dec 2019 09:11:29 -0800 (PST) =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: >On Saturday, 21 December 2019 18:33:30 UTC+2, bol...@nowhere.co.uk wrote: >> On Fri, 20 Dec 2019 10:36:14 -0800 (PST) >> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: >> >On Friday, 20 December 2019 18:28:29 UTC+2, bol...@nowhere.co.uk wrote: >> >> >But how you "do not use" it?: >> >> >> >> How did you manage to write code before? Its just yet more noise. >> > >> >Lack of answer noted. :D Pathetic snip of shameful strategies that >> >you likely use also noted. I answer later in post. >> >> It was a question to make you think. Clearly either you can't or you have the > >> memory of a goldfish and can't remember how you programmed yesterday, never >> mind before 2017. > >I started to program biotech applications in eighties. There are long >lasting experiments often lasting for days but equipment was often >experimental and hiccuping, probes could get contaminated etc. It was >common that at least some measurements were missing for one >or other time point. Should they throw away the whole experiment data? >No, experiments were expensive and there was plenty of information. >Should they somehow fake data for measurements that failed? No, >science can't be made from fake data. But lack of data is *normal* state >of affairs in world we live in. Yes, lack of data is normal, but you don't include it in the program data as "unknown". It simply isn't used to calculate the results which I presume would be some sort of statistical error bar calculation. >> Exceptions only use resources if thrown, optional uses resources every time >> its used. And if you want lack-of-value to be a valid return type then write > >> your code in PL/SQL or tSql. This is C++, it deals in boolean logic, not >> "I don't know". > >Nonsense, bool was added to C++ by C++98, I used C++ *long* before that. FFS, do you even know what boolean logic is? Clue: its how computers work and has nothing to do with the language being used. >> "Look at me - I read a paper by someone hardly anyone one has heard >> of 14 years ago, I must be a l33t coder 4sure!" > >Only utter moron denies contributions of John J. Barton and Lee R. Nackman >to our industry. Pathetic snip of answer noted again. :D Never even heard of them nor do I care. But given you don't even know what boolean logic is its obvious you're just a name dropper trying to look clever. >> The embarrasing strategies that have been used perfectly well for 20+ years? >> Did you just start coding yesterday? > >I said I have frowned upon that inefficient crap from eighties. That ineffcient crap is exactly what happens at the assembler level no matter what fancy high level constructs you use. There's no register value that means "I don't know". >Wtf you can program like that? Clown. :D Ad hominen, how predictable.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-21 10:18 -0800 |
| Message-ID | <9c976cda-edb5-4d55-bbac-5fa6433f29b4@googlegroups.com> |
| In reply to | #70601 |
On Saturday, 21 December 2019 19:22:15 UTC+2, bol...@nowhere.co.uk wrote: > On Sat, 21 Dec 2019 09:11:29 -0800 (PST) > =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: > >On Saturday, 21 December 2019 18:33:30 UTC+2, bol...@nowhere.co.uk wrote: > >> On Fri, 20 Dec 2019 10:36:14 -0800 (PST) > >> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: > >> >On Friday, 20 December 2019 18:28:29 UTC+2, bol...@nowhere.co.uk wrote: > >> >> >But how you "do not use" it?: > >> >> > >> >> How did you manage to write code before? Its just yet more noise. > >> > > >> >Lack of answer noted. :D Pathetic snip of shameful strategies that > >> >you likely use also noted. I answer later in post. > >> > >> It was a question to make you think. Clearly either you can't or you have the > > > >> memory of a goldfish and can't remember how you programmed yesterday, never > >> mind before 2017. > > > >I started to program biotech applications in eighties. There are long > >lasting experiments often lasting for days but equipment was often > >experimental and hiccuping, probes could get contaminated etc. It was > >common that at least some measurements were missing for one > >or other time point. Should they throw away the whole experiment data? > >No, experiments were expensive and there was plenty of information. > >Should they somehow fake data for measurements that failed? No, > >science can't be made from fake data. But lack of data is *normal* state > >of affairs in world we live in. > > Yes, lack of data is normal, but you don't include it in the program data > as "unknown". It simply isn't used to calculate the results which I presume > would be some sort of statistical error bar calculation. You just argue but avoid thinking what is really more efficient. Lets say we have 72 hour experiment with growing culture of some kind of insect cells. Lets say every minute something like temperature, weight, pressure, pH is measured at place and some little samples of culture and its exhaust gasses are taken for analyses done elsewhere and entered later. Every little thing of it may fail and every data-point can be therefore become lost and unknown forever. But actually vast majority of data points are known. So now we either have arrays of guaranteed 4320 (72*60) optionals (my suggestion) or we have arrays of up to 4320 (sometimes 4303 sometimes 4278 etc.) time and value pairs (your suggestion). What data takes less storage and is easier to process as well? My 40 years of experience has shown that optionals win by significant margin both in robustness and efficiency. And it does not matter that those were added to C++ library only 2017. > >> Exceptions only use resources if thrown, optional uses resources every time > >> its used. And if you want lack-of-value to be a valid return type then write > > > >> your code in PL/SQL or tSql. This is C++, it deals in boolean logic, not > >> "I don't know". > > > >Nonsense, bool was added to C++ by C++98, I used C++ *long* before that. > > FFS, do you even know what boolean logic is? Clue: its how computers work and > has nothing to do with the language being used. You argue with yourself here it is you who said that "This is C++, it deals in boolean logic, use tSql". :D I have used missing state regardless if I program in C, C++ or something else. It was supported from scratch in lot of languages. Objective C, Go, Swift etc. all have nil as value for "I don't know". So C++ had to add it too. > >> "Look at me - I read a paper by someone hardly anyone one has heard > >> of 14 years ago, I must be a l33t coder 4sure!" > > > >Only utter moron denies contributions of John J. Barton and Lee R. Nackman > >to our industry. Pathetic snip of answer noted again. :D > > Never even heard of them nor do I care. But given you don't even know what > boolean logic is its obvious you're just a name dropper trying to look clever. Nonsense. > >> The embarrasing strategies that have been used perfectly well for 20+ years? > >> Did you just start coding yesterday? > > > >I said I have frowned upon that inefficient crap from eighties. > > That ineffcient crap is exactly what happens at the assembler level no matter > what fancy high level constructs you use. There's no register value that means > "I don't know". There is nothing fancy in lack of data. It is normal. > >Wtf you can program like that? Clown. :D > > Ad hominen, how predictable. Find closest human in room. No humans in room found exception thrown. Program crashed with uncaught exception. :D
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2019-12-21 21:21 +0000 |
| Message-ID | <qtm2be$6pr$3@dont-email.me> |
| In reply to | #70603 |
On 21/12/2019 18:18, Öö Tiib wrote: > What data takes less storage and is easier to process as well? My 40 > years of experience has shown that optionals win by significant margin > both in robustness and efficiency. And it does not matter that those > were added to C++ library only 2017. I rather think this depends on the type of data you are processing. In your case you have data where particular values are missing from a set it's clearly sensible to store all the other data, and have some kind of flag to mark the missing data. If the data was being collected from a remote site, and the problem was loss of comms, then you'd have periods where there was no data from any of the sensors. In that case it's clearly sensible to record the start and end of the lost data period, and not record all the missing values. Equally if your sensor returns data with 50% reliability the cost of handling all the exceptions if one was thrown for each error would be very high. But if it lost one data point in a million the code of checking the validity of each one would be higher. Andy
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-21 14:30 -0800 |
| Message-ID | <f9186aa5-fab2-49f9-b092-7a9490a6f8ee@googlegroups.com> |
| In reply to | #70604 |
On Saturday, 21 December 2019 23:20:55 UTC+2, Vir Campestris wrote: > On 21/12/2019 18:18, Öö Tiib wrote: > > What data takes less storage and is easier to process as well? My 40 > > years of experience has shown that optionals win by significant margin > > both in robustness and efficiency. And it does not matter that those > > were added to C++ library only 2017. > > I rather think this depends on the type of data you are processing. > > In your case you have data where particular values are missing from a > set it's clearly sensible to store all the other data, and have some > kind of flag to mark the missing data. Sure, I tried to give convincing example of usage of optional. I am in no way saying that make everything optional. :D Make all stuff optional that may be normally missing (should not be treated as show stopper error when missing). > If the data was being collected from a remote site, and the problem was > loss of comms, then you'd have periods where there was no data from any > of the sensors. In that case it's clearly sensible to record the start > and end of the lost data period, and not record all the missing values. Yes. It depends what data is gathered and what processing is made. Sometimes such simple packing helps with storage. But when it helps then it does not apply only to missing values. If temperature is for hours 23.45°C in some vessel then that can be packed in same way. Depends how it is processed since unpacking takes storage too. ;) > Equally if your sensor returns data with 50% reliability the cost of > handling all the exceptions if one was thrown for each error would be > very high. But if it lost one data point in a million the code of > checking the validity of each one would be higher. My measuring has shown that somewhere around 1 fail : 5000 successes the exceptions and return value checking break even in current table-based exception handling in overall efficiency. But note that in real time processing the overall efficiency is less valuable. There tiny gain in cost of success loop does not matter but huge difference between success loop and fail loop hurts. Most often those performance considerations do not matter one way or other, then it matters what is more clear and robust. Explaining how to process my data as exported to Lotus 1-2-3 to biologists was simple since all values of same time point were on very same row. That was clear to them. Had I stored it differently then I had probably to convert it anyway to one with missing values here and there. Or how else you suggest to show it in spreadsheet?
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2019-12-22 21:36 +0000 |
| Message-ID | <qtonl6$djv$2@dont-email.me> |
| In reply to | #70605 |
On 21/12/2019 22:30, Öö Tiib wrote: > Explaining how to process my data as exported to Lotus 1-2-3 to > biologists was simple since all values of same time point were > on very same row. That was clear to them. I started off as a biologist. By the time we got to the programming for biologists bit of the course I was explaining things to the rest of the students... I know what you mean. Even though this was pre-spreadsheet! Andy
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-22 15:05 -0800 |
| Message-ID | <d5451ab0-2e2e-4584-8869-ba9f45c7a4c8@googlegroups.com> |
| In reply to | #70613 |
On Sunday, 22 December 2019 23:36:48 UTC+2, Vir Campestris wrote: > On 21/12/2019 22:30, Öö Tiib wrote: > > Explaining how to process my data as exported to Lotus 1-2-3 to > > biologists was simple since all values of same time point were > > on very same row. That was clear to them. > > I started off as a biologist. By the time we got to the programming for > biologists bit of the course I was explaining things to the rest of the > students... I know what you mean. Even though this was pre-spreadsheet! Before spreadsheets some biologists did not maybe understand how technological that science will rapidly turn. The biologists in eighties were already bright enough. They understood how data points may get lost during long experiment. It did not take days to explain to them that there is nothing "fancy" about it.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.co.uk |
|---|---|
| Date | 2019-12-22 17:03 +0000 |
| Message-ID | <qto7lf$elj$1@gioia.aioe.org> |
| In reply to | #70603 |
On Sat, 21 Dec 2019 10:18:19 -0800 (PST) =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: >So now we either have arrays of guaranteed 4320 (72*60) optionals (my >suggestion) or we have arrays of up to 4320 (sometimes 4303 sometimes >4278 etc.) time and value pairs (your suggestion). > >What data takes less storage and is easier to process as well? My 40 Pointers. If you have that many data points and presumably the size is unknown beforehand anyway then just have an array of pointers. NULL = no data. If you're storing an array of objects even if those objects are optionals then each time you resize that array the objects may well have to be copy constructed. What an inefficient mess. >> >> your code in PL/SQL or tSql. This is C++, it deals in boolean logic, not >> >> "I don't know". >> > >> >Nonsense, bool was added to C++ by C++98, I used C++ *long* before that. >> >> FFS, do you even know what boolean logic is? Clue: its how computers work and > >> has nothing to do with the language being used. > >You argue with yourself here it is you who said that "This is C++, it >deals in boolean logic, use tSql". Huh? Not only have you misquoted me but that reply makes no sense. >if I program in C, C++ or something else. It was supported from scratch >in lot of languages. Objective C, Go, Swift etc. all have nil as value for >"I don't know". So C++ had to add it too. No it didn't and it hasn't , its just added a class that anyone could write in 10 minutes themselves. The fact that most people never bothered shows how much use people felt that approach to be.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@i42.removethisbit.co.uk> |
|---|---|
| Date | 2019-12-22 17:46 +0000 |
| Message-ID | <o_NLF.96168$m4a.39844@fx03.dcg> |
| In reply to | #70611 |
On 22/12/2019 17:03, boltar@nowhere.co.uk wrote: > On Sat, 21 Dec 2019 10:18:19 -0800 (PST) > =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: >> So now we either have arrays of guaranteed 4320 (72*60) optionals (my >> suggestion) or we have arrays of up to 4320 (sometimes 4303 sometimes >> 4278 etc.) time and value pairs (your suggestion). >> >> What data takes less storage and is easier to process as well? My 40 > > Pointers. Pointers have to point to something, dear. Where do you propose to allocate the elements that the pointers point to? With optional the element is constructed in-place so can be CONTIGUOUS in a SINGLE container such as std::vector<std::optional<foo>>. You are in serious need of a cluebat. /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 M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-12-22 18:07 -0800 |
| Message-ID | <qtp7gd$v11$1@gioia.aioe.org> |
| In reply to | #70612 |
On 12/22/2019 9:46 AM, Mr Flibble wrote:
> On 22/12/2019 17:03, boltar@nowhere.co.uk wrote:
>> On Sat, 21 Dec 2019 10:18:19 -0800 (PST)
>> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>>> So now we either have arrays of guaranteed 4320 (72*60) optionals (my
>>> suggestion) or we have arrays of up to 4320 (sometimes 4303 sometimes
>>> 4278 etc.) time and value pairs (your suggestion).
>>>
>>> What data takes less storage and is easier to process as well? My 40
>>
>> Pointers.
>
> Pointers have to point to something, dear.
_____________________
#include <iostream>
int main() {
void* missle_launch = (void*)0xDEADBEEF;
std::cout << "missle_launch = " << missle_launch << "\n";
return 666;
}
_____________________
;^)
> Where do you propose to
> allocate the elements that the pointers point to? With optional the
> element is constructed in-place so can be CONTIGUOUS in a SINGLE
> container such as std::vector<std::optional<foo>>. You are in serious
> need of a cluebat.
>
> /Flibble
>
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.co.uk |
|---|---|
| Date | 2019-12-23 16:23 +0000 |
| Message-ID | <qtqpm5$333$1@gioia.aioe.org> |
| In reply to | #70612 |
On Sun, 22 Dec 2019 17:46:59 +0000 Mr Flibble <flibble@i42.removethisbit.co.uk> wrote: >On 22/12/2019 17:03, boltar@nowhere.co.uk wrote: >> On Sat, 21 Dec 2019 10:18:19 -0800 (PST) >> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: >>> So now we either have arrays of guaranteed 4320 (72*60) optionals (my >>> suggestion) or we have arrays of up to 4320 (sometimes 4303 sometimes >>> 4278 etc.) time and value pairs (your suggestion). >>> >>> What data takes less storage and is easier to process as well? My 40 >> >> Pointers. > >Pointers have to point to something, dear. Yes they do little rear gunner, congratulations, have a medal. >Where do you propose to >allocate the elements that the pointers point to? Sorry, is that a trick question or are you really one of those jackasses who has a problem using pointers full stop. >With optional the >element is constructed in-place so can be CONTIGUOUS in a SINGLE The only thing that will be contiguous is the optional instances memory location, not that which they contain. >container such as std::vector<std::optional<foo>>. You are in serious Imagine all those lovely copy constructors firing away the minute the array is resized, wonderfully efficient. >need of a cluebat. I doubt you'd even be able to find one.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@i42.removethisbit.co.uk> |
|---|---|
| Date | 2019-12-23 16:33 +0000 |
| Message-ID | <q%5MF.59447$7r1.31498@fx15.dcg> |
| In reply to | #70619 |
On 23/12/2019 16:23, boltar@nowhere.co.uk wrote: > On Sun, 22 Dec 2019 17:46:59 +0000 > Mr Flibble <flibble@i42.removethisbit.co.uk> wrote: >> On 22/12/2019 17:03, boltar@nowhere.co.uk wrote: >>> On Sat, 21 Dec 2019 10:18:19 -0800 (PST) >>> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: >>>> So now we either have arrays of guaranteed 4320 (72*60) optionals (my >>>> suggestion) or we have arrays of up to 4320 (sometimes 4303 sometimes >>>> 4278 etc.) time and value pairs (your suggestion). >>>> >>>> What data takes less storage and is easier to process as well? My 40 >>> >>> Pointers. >> >> Pointers have to point to something, dear. > > Yes they do little rear gunner, congratulations, have a medal. > >> Where do you propose to >> allocate the elements that the pointers point to? > > Sorry, is that a trick question or are you really one of those jackasses > who has a problem using pointers full stop. > >> With optional the >> element is constructed in-place so can be CONTIGUOUS in a SINGLE > > The only thing that will be contiguous is the optional instances memory > location, not that which they contain. This is your problem: you are critise things you don't understand: optional values are allocated within the optional itself using placement new on a correctly aligned char/byte array. This leads to performance benefits and is one of the reasons why we use optional: it is stack and CPU-cache friendly. Please, hit yourself over the head with cluebat if you can manage even that. /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.co.uk |
|---|---|
| Date | 2019-12-23 16:46 +0000 |
| Message-ID | <qtqr1v$9jj$1@gioia.aioe.org> |
| In reply to | #70621 |
On Mon, 23 Dec 2019 16:33:25 +0000 Mr Flibble <flibble@i42.removethisbit.co.uk> wrote: >On 23/12/2019 16:23, boltar@nowhere.co.uk wrote: >> On Sun, 22 Dec 2019 17:46:59 +0000 >> Mr Flibble <flibble@i42.removethisbit.co.uk> wrote: >>> On 22/12/2019 17:03, boltar@nowhere.co.uk wrote: >>>> On Sat, 21 Dec 2019 10:18:19 -0800 (PST) >>>> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: >>>>> So now we either have arrays of guaranteed 4320 (72*60) optionals (my >>>>> suggestion) or we have arrays of up to 4320 (sometimes 4303 sometimes >>>>> 4278 etc.) time and value pairs (your suggestion). >>>>> >>>>> What data takes less storage and is easier to process as well? My 40 >>>> >>>> Pointers. >>> >>> Pointers have to point to something, dear. >> >> Yes they do little rear gunner, congratulations, have a medal. >> >>> Where do you propose to >>> allocate the elements that the pointers point to? >> >> Sorry, is that a trick question or are you really one of those jackasses >> who has a problem using pointers full stop. >> >>> With optional the >>> element is constructed in-place so can be CONTIGUOUS in a SINGLE >> >> The only thing that will be contiguous is the optional instances memory >> location, not that which they contain. > >This is your problem: you are critise things you don't understand: >optional values are allocated within the optional itself using placement Are they? Really? Well thanks for the heads up there! >new on a correctly aligned char/byte array. This leads to performance Wow, it does word alignment allocation?? Thats voodoo I tell you! >benefits and is one of the reasons why we use optional: it is stack and >CPU-cache friendly. Congratulations on completely missing the point. Never mind.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-23 18:51 +0200 |
| Message-ID | <qtqra7$2go$1@dont-email.me> |
| In reply to | #70619 |
On 23.12.2019 18:23, boltar@nowhere.co.uk wrote: > On Sun, 22 Dec 2019 17:46:59 +0000 > Mr Flibble <flibble@i42.removethisbit.co.uk> wrote: >> With optional the >> element is constructed in-place so can be CONTIGUOUS in a SINGLE > > The only thing that will be contiguous is the optional instances memory > location, not that which they contain. It's hard to tell if you don't know what the word "contain" means in English or if you have troubles to understand why the contiguous memory access works better with current hardware. > >> container such as std::vector<std::optional<foo>>. You are in serious > > Imagine all those lovely copy constructors firing away the minute the array It seems you have never measured the performance of dynamic memory allocation call versus a small class copy constructor. > is resized, wonderfully efficient. Not to speak about that your example is not even using copy constructors in well-written C++. Move constructors were standardized about 8 years ago.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.co.uk |
|---|---|
| Date | 2019-12-23 17:02 +0000 |
| Message-ID | <qtqrvv$eir$1@gioia.aioe.org> |
| In reply to | #70623 |
On Mon, 23 Dec 2019 18:51:17 +0200 Paavo Helde <myfirstname@osa.pri.ee> wrote: >On 23.12.2019 18:23, boltar@nowhere.co.uk wrote: >> On Sun, 22 Dec 2019 17:46:59 +0000 >> Mr Flibble <flibble@i42.removethisbit.co.uk> wrote: >>> With optional the >>> element is constructed in-place so can be CONTIGUOUS in a SINGLE >> >> The only thing that will be contiguous is the optional instances memory >> location, not that which they contain. > >It's hard to tell if you don't know what the word "contain" means in >English or if you have troubles to understand why the contiguous memory >access works better with current hardware. Thanks, my English is fine, unlike yours. And as I've said , the only thing that will be in contiguous memory are the optional instances themselves, not the objects they in turn contain. >>> container such as std::vector<std::optional<foo>>. You are in serious >> >> Imagine all those lovely copy constructors firing away the minute the array > >It seems you have never measured the performance of dynamic memory >allocation call versus a small class copy constructor. So the memory used by the objects contained in optional doesn't get allocated? Is it done with magic? Perhaps the OS sacrifices a chicken or 2. > > is resized, wonderfully efficient. > >Not to speak about that your example is not even using copy constructors >in well-written C++. Move constructors were standardized about 8 years ago. Move constructors have other problems. Plus how often do you see them used?
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-23 19:17 +0200 |
| Message-ID | <qtqsqq$bph$1@dont-email.me> |
| In reply to | #70624 |
On 23.12.2019 19:02, boltar@nowhere.co.uk wrote: > On Mon, 23 Dec 2019 18:51:17 +0200 > Paavo Helde <myfirstname@osa.pri.ee> wrote: >> On 23.12.2019 18:23, boltar@nowhere.co.uk wrote: >>> On Sun, 22 Dec 2019 17:46:59 +0000 >>> Mr Flibble <flibble@i42.removethisbit.co.uk> wrote: >>>> With optional the >>>> element is constructed in-place so can be CONTIGUOUS in a SINGLE >>> >>> The only thing that will be contiguous is the optional instances memory >>> location, not that which they contain. >> >> It's hard to tell if you don't know what the word "contain" means in >> English or if you have troubles to understand why the contiguous memory >> access works better with current hardware. > > Thanks, my English is fine, unlike yours. And as I've said , the only thing > that will be in contiguous memory are the optional instances themselves, not > the objects they in turn contain. The objects don't need to be exactly adjacent in order to end up in the same cache line. > >>>> container such as std::vector<std::optional<foo>>. You are in serious >>> >>> Imagine all those lovely copy constructors firing away the minute the array >> >> It seems you have never measured the performance of dynamic memory >> allocation call versus a small class copy constructor. > > So the memory used by the objects contained in optional doesn't get allocated? > Is it done with magic? Perhaps the OS sacrifices a chicken or 2. The are allocated exactly the same way as your beloved pointer values are. Hint: this is not called dynamic allocation. > >>> is resized, wonderfully efficient. >> >> Not to speak about that your example is not even using copy constructors >> in well-written C++. Move constructors were standardized about 8 years ago. > > Move constructors have other problems. Plus how often do you see them used? All the time in the code where performance is important. Also, move constructors and assignments are generated automatically by the compiler for most classes and used automatically by containers like std::vector, so one might just not realize how often they get used.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-24 09:49 +0000 |
| Message-ID | <qtsmvl$m0l$1@gioia.aioe.org> |
| In reply to | #70625 |
On Mon, 23 Dec 2019 19:17:12 +0200 Paavo Helde <myfirstname@osa.pri.ee> wrote: >On 23.12.2019 19:02, boltar@nowhere.co.uk wrote: >> On Mon, 23 Dec 2019 18:51:17 +0200 >> Paavo Helde <myfirstname@osa.pri.ee> wrote: >>> On 23.12.2019 18:23, boltar@nowhere.co.uk wrote: >>>> On Sun, 22 Dec 2019 17:46:59 +0000 >>>> Mr Flibble <flibble@i42.removethisbit.co.uk> wrote: >>>>> With optional the >>>>> element is constructed in-place so can be CONTIGUOUS in a SINGLE >>>> >>>> The only thing that will be contiguous is the optional instances memory >>>> location, not that which they contain. >>> >>> It's hard to tell if you don't know what the word "contain" means in >>> English or if you have troubles to understand why the contiguous memory >>> access works better with current hardware. >> >> Thanks, my English is fine, unlike yours. And as I've said , the only thing >> that will be in contiguous memory are the optional instances themselves, not >> the objects they in turn contain. > >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.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-12-24 02:16 -0800 |
| Message-ID | <qtsohk$tjj$1@gioia.aioe.org> |
| In reply to | #70629 |
On 12/24/2019 1:49 AM, boltar@nowhere.org wrote:
> On Mon, 23 Dec 2019 19:17:12 +0200
> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> On 23.12.2019 19:02, boltar@nowhere.co.uk wrote:
>>> On Mon, 23 Dec 2019 18:51:17 +0200
>>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>>> On 23.12.2019 18:23, boltar@nowhere.co.uk wrote:
>>>>> On Sun, 22 Dec 2019 17:46:59 +0000
>>>>> Mr Flibble <flibble@i42.removethisbit.co.uk> wrote:
>>>>>> With optional the
>>>>>> element is constructed in-place so can be CONTIGUOUS in a SINGLE
>>>>>
>>>>> The only thing that will be contiguous is the optional instances memory
>>>>> location, not that which they contain.
>>>>
>>>> It's hard to tell if you don't know what the word "contain" means in
>>>> English or if you have troubles to understand why the contiguous memory
>>>> access works better with current hardware.
>>>
>>> Thanks, my English is fine, unlike yours. And as I've said , the only thing
>>> that will be in contiguous memory are the optional instances themselves, not
>>> the objects they in turn contain.
>>
>> 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.
>
>
Fwiw, I have seen people use two 32 bit unsigned integers in the same
64-byte cache line. These were operated on by multiple threads. This is
BAD! Something like:
_________________________
struct cache_line_buf
{
uint8_t buf[64];
};
struct user_data
{
uint32_t atomic_a;
uint32_t atomic_b;
};
union cache_line
{
user_data data;
cache_line_buf buf;
};
_________________________
More than one thread can concurrently work on cache_line.data.atomic_a
and b. Oh shi%! False sharing galore. Then I have seen horror shows
where the user data was something like:
_________________________
struct user_data
{
uint32_t atomic_a;
uint16_t foo;
uint8_t bar;
uint8_t baz;
};
_________________________
Writer threads would nail user_data.atomic_a, while other innocent
reader threads are just trying to read from foo, bar and baz... Wow!
This is bad. A false sharing festival of crap. Ouch.
[toc] | [prev] | [next] | [standalone]
Page 3 of 16 — ← Prev page 1 2 [3] 4 5 … 16 Next page →
Back to top | Article view | comp.lang.c++
csiph-web