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 12 of 16 — ← Prev page 1 … 10 11 [12] 13 14 … 16 Next page →
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-27 09:58 -0800 |
| Message-ID | <0c2e494d-4ec2-4e5b-bace-879616bcdc73@googlegroups.com> |
| In reply to | #70690 |
On Friday, 27 December 2019 19:17:19 UTC+2, bol...@nowhere.org wrote: > On Thu, 26 Dec 2019 18:30:02 +0000 > Mr Flibble <flibble@i42.removethisbit.co.uk> wrote: > > >Now will you please fuck off you deliberately obtuse idiot. > > Now why not go write yourself a program that, oh I don't know, loads in > biological data points as the OP was talking about in a fucking loop creating > data objects as it goes and try and store them on the stack without writing > your own allocator that uses alloca() or similar API stack functions. > > Good luck, get back to me when you're done. How chaotic and unplanned you expect scientists to be? In planning of their experiments they were capable to take into account even such constraints like maximum count of rows of csv files that Lotus 1-2-3 was capable to import. Scientists are rational people, unlike lot of wannabe programmers. In fact I remember requirements to help them and to warn about such things. So all arrays were definitely possible to allocate once if not to make with static compile-time known size.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-28 12:06 +0000 |
| Message-ID | <qu7ggq$rqb$1@gioia.aioe.org> |
| In reply to | #70693 |
On Fri, 27 Dec 2019 09:58:46 -0800 (PST) =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: >On Friday, 27 December 2019 19:17:19 UTC+2, bol...@nowhere.org wrote: >> On Thu, 26 Dec 2019 18:30:02 +0000 >> Mr Flibble <flibble@i42.removethisbit.co.uk> wrote: >> >> >Now will you please fuck off you deliberately obtuse idiot. >> >> Now why not go write yourself a program that, oh I don't know, loads in >> biological data points as the OP was talking about in a fucking loop >creating >> data objects as it goes and try and store them on the stack without writing >> your own allocator that uses alloca() or similar API stack functions. >> >> Good luck, get back to me when you're done. > >How chaotic and unplanned you expect scientists to be? In planning >of their experiments they were capable to take into account even >such constraints like maximum count of rows of csv files that >Lotus 1-2-3 was capable to import. Scientists are rational people, >unlike lot of wannabe programmers. In fact I remember requirements >to help them and to warn about such things. So all arrays were >definitely possible to allocate once if not to make with static >compile-time known size. Oh right, so now you want fixed sized arrays beforehand. Good idea, in fact in that case why bother with containers or C++ at all, lets just use a good old fashioned C style automatic array! That'll work for all situations I have no doubt.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-28 08:39 -0800 |
| Message-ID | <38c3c58e-637c-4254-a0a8-a567a075612d@googlegroups.com> |
| In reply to | #70733 |
On Saturday, 28 December 2019 14:06:58 UTC+2, bol...@nowhere.org wrote: > On Fri, 27 Dec 2019 09:58:46 -0800 (PST) > =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: > >On Friday, 27 December 2019 19:17:19 UTC+2, bol...@nowhere.org wrote: > >> On Thu, 26 Dec 2019 18:30:02 +0000 > >> Mr Flibble <flibble@i42.removethisbit.co.uk> wrote: > >> > >> >Now will you please fuck off you deliberately obtuse idiot. > >> > >> Now why not go write yourself a program that, oh I don't know, loads in > >> biological data points as the OP was talking about in a fucking loop > >creating > >> data objects as it goes and try and store them on the stack without writing > >> your own allocator that uses alloca() or similar API stack functions. > >> > >> Good luck, get back to me when you're done. > > > >How chaotic and unplanned you expect scientists to be? In planning > >of their experiments they were capable to take into account even > >such constraints like maximum count of rows of csv files that > >Lotus 1-2-3 was capable to import. Scientists are rational people, > >unlike lot of wannabe programmers. In fact I remember requirements > >to help them and to warn about such things. So all arrays were > >definitely possible to allocate once if not to make with static > >compile-time known size. > > Oh right, so now you want fixed sized arrays beforehand. Good idea, in fact > in that case why bother with containers or C++ at all, lets just use a good > old fashioned C style automatic array! That'll work for all situations I have > no doubt. That does not follow. You asked question "how" and I answered. Why you constantly build strange straw-man arguments, claim these were made by others and then ludicrously moan and groan about it? Are you demented or is it just norm in your alien to me culture? What is your issue with std::array, boost::container::static_vector, std::pair, std::tuple, std::optional and so on? There was no point to use fixed size raw arrays before C++17 besides string literals. After C++17 it is likely that even string literals are best to use as std::string_view. Such are safer than raw array but generated code is as efficient. Such are of literal type if contained elements are of literal type and so can be used as constant expressions and arguments and return values of constexpr functions. Raw array is so dead in C++ but not because of your std:vector of pointers.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-28 16:57 +0000 |
| Message-ID | <qu81ho$19e7$1@gioia.aioe.org> |
| In reply to | #70738 |
On Sat, 28 Dec 2019 08:39:37 -0800 (PST) =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: >On Saturday, 28 December 2019 14:06:58 UTC+2, bol...@nowhere.org wrote: >> On Fri, 27 Dec 2019 09:58:46 -0800 (PST) >> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: >> >On Friday, 27 December 2019 19:17:19 UTC+2, bol...@nowhere.org wrote: >> >> On Thu, 26 Dec 2019 18:30:02 +0000 >> >> Mr Flibble <flibble@i42.removethisbit.co.uk> wrote: >> >> >> >> >Now will you please fuck off you deliberately obtuse idiot. >> >> >> >> Now why not go write yourself a program that, oh I don't know, loads in >> >> biological data points as the OP was talking about in a fucking loop >> >creating >> >> data objects as it goes and try and store them on the stack without >writing >> >> your own allocator that uses alloca() or similar API stack functions. >> >> >> >> Good luck, get back to me when you're done. >> > >> >How chaotic and unplanned you expect scientists to be? In planning >> >of their experiments they were capable to take into account even >> >such constraints like maximum count of rows of csv files that >> >Lotus 1-2-3 was capable to import. Scientists are rational people, >> >unlike lot of wannabe programmers. In fact I remember requirements >> >to help them and to warn about such things. So all arrays were >> >definitely possible to allocate once if not to make with static >> >compile-time known size. >> >> Oh right, so now you want fixed sized arrays beforehand. Good idea, in fact >> in that case why bother with containers or C++ at all, lets just use a good >> old fashioned C style automatic array! That'll work for all situations I have > >> no doubt. > >That does not follow. You asked question "how" and I answered. Why you I never asked how. My original question was "why". What exactly is the point of optional? I've yet to see a good argument for it. >others and then ludicrously moan and groan about it? Are you demented or >is it just norm in your alien to me culture? What? >What is your issue with std::array, boost::container::static_vector, >std::pair, std::tuple, std::optional and so on? Never used static_vector as I've managed to avoid the Boost bloatware so far but I have no problem with any of them except optional. >string literals. After C++17 it is likely that even string literals >are best to use as std::string_view. I'll stick to const char * until I see a good reason not to use it particularly as its stored in the program text, not the stack or heap. >values of constexpr functions. Raw array is so dead in C++ but not >because of your std:vector of pointers. Why is raw array dead? If I needed high performance, was just storing plain old data types and don't want the overhead of a container class no matter how minimal then I'd still use them.
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2020-01-02 23:18 -0500 |
| Message-ID | <2gzPF.62809$lT2.9318@fx28.iad> |
| In reply to | #70739 |
boltar@nowhere.org wrote: > On Sat, 28 Dec 2019 08:39:37 -0800 (PST) > =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: >> On Saturday, 28 December 2019 14:06:58 UTC+2, bol...@nowhere.org wrote: >>> On Fri, 27 Dec 2019 09:58:46 -0800 (PST) >>> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: >>>> On Friday, 27 December 2019 19:17:19 UTC+2, bol...@nowhere.org wrote: >>>>> On Thu, 26 Dec 2019 18:30:02 +0000 >>>>> Mr Flibble <flibble@i42.removethisbit.co.uk> wrote: >>>>> >>>>>> Now will you please fuck off you deliberately obtuse idiot. >>>>> >>>>> Now why not go write yourself a program that, oh I don't know, loads in >>>>> biological data points as the OP was talking about in a fucking loop >>>> creating >>>>> data objects as it goes and try and store them on the stack without >> writing >>>>> your own allocator that uses alloca() or similar API stack functions. >>>>> >>>>> Good luck, get back to me when you're done. >>>> >>>> How chaotic and unplanned you expect scientists to be? In planning >>>> of their experiments they were capable to take into account even >>>> such constraints like maximum count of rows of csv files that >>>> Lotus 1-2-3 was capable to import. Scientists are rational people, >>>> unlike lot of wannabe programmers. In fact I remember requirements >>>> to help them and to warn about such things. So all arrays were >>>> definitely possible to allocate once if not to make with static >>>> compile-time known size. >>> >>> Oh right, so now you want fixed sized arrays beforehand. Good idea, in fact >>> in that case why bother with containers or C++ at all, lets just use a good >>> old fashioned C style automatic array! That'll work for all situations I have >> >>> no doubt. >> >> That does not follow. You asked question "how" and I answered. Why you > > I never asked how. My original question was "why". What exactly is the point > of optional? I've yet to see a good argument for it. > I often use optionals to avoid initializing big object twice while upserting values to unordered maps of big objects using operator= (with ordered map, you can use lower_bound and a hint for same but it's wordier). (those that can use C++ 17 can use insert_or_assign as a better although also slightly wordier alternative to operator=). Many people use optionals to implement in C++ same algorithms and data structures as those done with Haskell's Maybe and Scala's Option -- which is probably the optional's design goal (just guessing, did not check). See e.g. https://www.fluentcpp.com/2019/07/19/expressiveness-nullable-types-and-composition-part-2/ >> others and then ludicrously moan and groan about it? Are you demented or >> is it just norm in your alien to me culture? > > What? > >> What is your issue with std::array, boost::container::static_vector, >> std::pair, std::tuple, std::optional and so on? > > Never used static_vector as I've managed to avoid the Boost bloatware so far > but I have no problem with any of them except optional. > >> string literals. After C++17 it is likely that even string literals >> are best to use as std::string_view. > > I'll stick to const char * until I see a good reason not to use it particularly > as its stored in the program text, not the stack or heap. > >> values of constexpr functions. Raw array is so dead in C++ but not >> because of your std:vector of pointers. > > Why is raw array dead? If I needed high performance, was just storing plain old > data types and don't want the overhead of a container class no matter how > minimal then I'd still use them. > HTH -Pavel
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2019-12-26 10:54 -0800 |
| Message-ID | <87woairk7b.fsf@nosuchdomain.example.com> |
| In reply to | #70663 |
Paavo Helde <myfirstname@osa.pri.ee> writes:
> 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.
[...]
> 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.
[...]
Your program only demonstrates that the T object is allocated
within the optional<T> object *for the implementation you used*.
(Defining an optional<T> type with a large parameter type T and
printing its size would be a simpler way to demonstrate that.)
I can easily imagine that a different implementation might store
the T object outside the optional<T> object, saving space when it's
not present.
What *does* prove that the T object is stored within the optional<T>
object is that the standard says it must be. C++17 23.6.3
[optional.optional] paragraph 1:
Any instance of optional<T> at any given time either contains
a value or does not contain a value. When an instance of
optional<T> *contains a value*, it means that an object of
type T, referred to as the optional object’s contained
value, is allocated within the storage of the optional
object. Implementations are not permitted to use additional
storage, such as dynamic memory, to allocate its contained value.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
[Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-26 22:50 +0200 |
| Message-ID | <qu36dv$b2s$1@dont-email.me> |
| In reply to | #70671 |
On 26.12.2019 20:54, Keith Thompson wrote: > Paavo Helde <myfirstname@osa.pri.ee> writes: >> 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. > > [...] > > Your program only demonstrates that the T object is allocated > within the optional<T> object *for the implementation you used*. > [...] > What *does* prove that the T object is stored within the optional<T> > object is that the standard says it must be. C++17 23.6.3 > [optional.optional] paragraph 1: You are right, but as it appears "boltar" is not easily swayed by mere words, I was trying something more concrete. Probably in vain...
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2019-12-26 10:38 -0800 |
| Message-ID | <feacfe8d-c6fa-4f85-8e77-9beca8c1ce98@googlegroups.com> |
| In reply to | #70660 |
On Thursday, December 26, 2019 at 4:46:35 AM UTC-5, bol...@nowhere.org wrote:
> On Wed, 25 Dec 2019 00:30:46 +0200
> Paavo Helde <myfirstname@osa.pri.ee> wrote:
> >
> >"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.
>
> 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.
A typical implementation of optional<T> uses data storage something like
union {
char dummy;
std::remove_const_t<T> value;
};
bool has_value;
and uses placement new to initialize value if defined. There's no dynamic
allocation happening here, for example,
std::optional<std::string> o1{}; // does not contain a value
std::optional<std::string> o2 = "Hello"; // contains a small string value
Best regards,
Daniel
[toc] | [prev] | [next] | [standalone]
| From | woodbrian77@gmail.com |
|---|---|
| Date | 2019-12-24 17:52 -0800 |
| Message-ID | <ffcec8d1-857f-4e62-9a94-40cd8031cbe7@googlegroups.com> |
| In reply to | #70600 |
On Saturday, December 21, 2019 at 11:11:38 AM UTC-6, Öö Tiib 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. > 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. I was reading here https://www.reddit.com/r/cpp/comments/ef5gdc/managarm_at_the_end_of_2019/ The following: I love the philosophy of "async ONLY". One of my biggest complaints is how frequently processes in Linux get stuck because of waiting on disk IO. Nothing makes me madder than being unable to terminate a process for hours while a filesystem twiddles it's thumbs. -------------------------------------------------------------------- That's news to me about Linux processes. Can anyone add to that? Is killing the process not an option? Is this a Linux problem that isn't getting fixed so users have to work around it? Does FreeBSD have similar problems? My middle tier does synchronous reads and writes to the file system. If I were to work on making one of those async, do you think it would be easier to start with the writes rather than the reads? Thank you in advance. Brian Ebenezer Enterprises - In G-d we trust. https://github.com/Ebenezer-group/onwards
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-24 23:53 -0800 |
| Message-ID | <ff8d7c0e-241f-4e01-b336-548bf84f87c0@googlegroups.com> |
| In reply to | #70640 |
On Wednesday, 25 December 2019 03:52:35 UTC+2, woodb...@gmail.com wrote:
> On Saturday, December 21, 2019 at 11:11:38 AM UTC-6, Öö Tiib 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.
> > 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.
>
> I was reading here
> https://www.reddit.com/r/cpp/comments/ef5gdc/managarm_at_the_end_of_2019/
>
> The following:
> I love the philosophy of "async ONLY".
>
> One of my biggest complaints is how frequently processes in
> Linux get stuck because of waiting on disk IO. Nothing makes
> me madder than being unable to terminate a process for hours
> while a filesystem twiddles it's thumbs.
>
> --------------------------------------------------------------------
>
> That's news to me about Linux processes. Can anyone add to
> that? Is killing the process not an option?
As I understand it the process is in "D" state that means
"uninterruptible sleep" that is usually because waiting for I/O.
> Is this a Linux
> problem that isn't getting fixed so users have to work
> around it? Does FreeBSD have similar problems?
I do not know about FreeBSD. When unsure what processes are stuck
behind I/O one can utter on Linux something like:
watch "(ps -eo stat,pid,comm|awk '(NR==1)||(\$1~/D/){print}')"
That will give information about processes in "D" state.
> My middle tier does synchronous reads and writes to the file
> system. If I were to work on making one of those async, do
> you think it would be easier to start with the writes rather
> than the reads? Thank you in advance.
There are no silver bullets. Few kilobyte files are likely
best to read and write "atomically" as whole file. With bigger
files we need to pick asynchronous or synchronous. Trying to mix
those with same file will add complications, no gains. Choice
what is more optimal depends on how expensive processing is
done during I/O. Synchronous communication seems to be easier
for programmers to reason about so pick that as default.
[toc] | [prev] | [next] | [standalone]
| From | woodbrian77@gmail.com |
|---|---|
| Date | 2019-12-25 08:51 -0800 |
| Message-ID | <07c4428a-54b0-4cd2-9746-cd53576b3a19@googlegroups.com> |
| In reply to | #70641 |
On Wednesday, December 25, 2019 at 1:53:34 AM UTC-6, Öö Tiib wrote:
> On Wednesday, 25 December 2019 03:52:35 UTC+2, woodb...@gmail.com wrote:
> > I was reading here
> > https://www.reddit.com/r/cpp/comments/ef5gdc/managarm_at_the_end_of_2019/
> >
> > The following:
> > I love the philosophy of "async ONLY".
> >
> > One of my biggest complaints is how frequently processes in
> > Linux get stuck because of waiting on disk IO. Nothing makes
> > me madder than being unable to terminate a process for hours
> > while a filesystem twiddles it's thumbs.
> >
> > --------------------------------------------------------------------
> >
> > That's news to me about Linux processes. Can anyone add to
> > that? Is killing the process not an option?
>
> As I understand it the process is in "D" state that means
> "uninterruptible sleep" that is usually because waiting for I/O.
>
> > Is this a Linux
> > problem that isn't getting fixed so users have to work
> > around it? Does FreeBSD have similar problems?
>
> I do not know about FreeBSD. When unsure what processes are stuck
> behind I/O one can utter on Linux something like:
>
> watch "(ps -eo stat,pid,comm|awk '(NR==1)||(\$1~/D/){print}')"
>
> That will give information about processes in "D" state.
>
> > My middle tier does synchronous reads and writes to the file
> > system. If I were to work on making one of those async, do
> > you think it would be easier to start with the writes rather
> > than the reads? Thank you in advance.
>
> There are no silver bullets. Few kilobyte files are likely
> best to read and write "atomically" as whole file.
I interpret that to be the same as synchronous.
> With bigger
> files we need to pick asynchronous or synchronous. Trying to mix
> those with same file will add complications, no gains. Choice
> what is more optimal depends on how expensive processing is
> done during I/O. Synchronous communication seems to be easier
> for programmers to reason about so pick that as default.
Kind of agree and my files will likely be less than a megabyte
so will stick to synchronous file I/O for now.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-25 10:54 -0800 |
| Message-ID | <ff38f55a-fd58-4d8d-8492-fd1d64fe92fb@googlegroups.com> |
| In reply to | #70647 |
On Wednesday, 25 December 2019 18:51:56 UTC+2, woodb...@gmail.com wrote:
> On Wednesday, December 25, 2019 at 1:53:34 AM UTC-6, Öö Tiib wrote:
> > On Wednesday, 25 December 2019 03:52:35 UTC+2, woodb...@gmail.com wrote:
> > > I was reading here
> > > https://www.reddit.com/r/cpp/comments/ef5gdc/managarm_at_the_end_of_2019/
> > >
> > > The following:
> > > I love the philosophy of "async ONLY".
> > >
> > > One of my biggest complaints is how frequently processes in
> > > Linux get stuck because of waiting on disk IO. Nothing makes
> > > me madder than being unable to terminate a process for hours
> > > while a filesystem twiddles it's thumbs.
> > >
> > > --------------------------------------------------------------------
> > >
> > > That's news to me about Linux processes. Can anyone add to
> > > that? Is killing the process not an option?
> >
> > As I understand it the process is in "D" state that means
> > "uninterruptible sleep" that is usually because waiting for I/O.
> >
> > > Is this a Linux
> > > problem that isn't getting fixed so users have to work
> > > around it? Does FreeBSD have similar problems?
> >
> > I do not know about FreeBSD. When unsure what processes are stuck
> > behind I/O one can utter on Linux something like:
> >
> > watch "(ps -eo stat,pid,comm|awk '(NR==1)||(\$1~/D/){print}')"
> >
> > That will give information about processes in "D" state.
> >
> > > My middle tier does synchronous reads and writes to the file
> > > system. If I were to work on making one of those async, do
> > > you think it would be easier to start with the writes rather
> > > than the reads? Thank you in advance.
> >
> > There are no silver bullets. Few kilobyte files are likely
> > best to read and write "atomically" as whole file.
>
> I interpret that to be the same as synchronous.
>
> > With bigger
> > files we need to pick asynchronous or synchronous. Trying to mix
> > those with same file will add complications, no gains. Choice
> > what is more optimal depends on how expensive processing is
> > done during I/O. Synchronous communication seems to be easier
> > for programmers to reason about so pick that as default.
>
> Kind of agree and my files will likely be less than a megabyte
> so will stick to synchronous file I/O for now.
Also note that when our file handling involves random access
or even worse random access and sharing between processes (it
sometimes does) then it is very hard to do with usual serial
read/write but quite clean with memory mapping. With memory
mapping our file's size must be multiplies of memory page size
(typically 4096 bytes) and the code will be platform specific
and it can't be done on systems without virtual memory and
some other such constraints but otherwise it will work great. ;)
[toc] | [prev] | [next] | [standalone]
| From | woodbrian77@gmail.com |
|---|---|
| Date | 2019-12-21 08:42 -0800 |
| Message-ID | <ee81a8ba-bd6c-4707-a193-1141a64f2540@googlegroups.com> |
| In reply to | #70589 |
On Friday, December 20, 2019 at 6:35:48 AM UTC-6, Öö Tiib 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?: > > 1) data in your program can not have optional, missing, lazily loaded > properties. > That is uselessly naive to hope about most real world data. > Even if all data is really acquirable it may be expensive and pointless > to do it always. > > 2) properties whose value may be missing has to be dynamically > allocated so you can use nullptr as indication of it being missing. > Really? Every int that may be unknown has to be made dynamically > allocated? > > 3) such objects have to have internal "missing" state that is then > checked in all interface methods of those. Types outside of your > control like fundamentals or standard library types you need to > manually wrap by add that "missing" state. > Whole whopping wrapper class around int to add missing state > to it? > > 4) You have external bools or flags somewhere that indicate > if something is missing? > Annoyingly error prone and confusing. > > 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. > > 6) You use some kind of mix of above "tricks"? > 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. > > Any other ways? I doubt it. > 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. You seem to be high on std::optional. This file: https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc has this line: cmwRequest* req=nullptr; You don't like that? I haven't tried it recently, but I suspect making that an optional would puff up the size of my binary without any benefit. I think more highly of std::optional than std::any, but don't find a lot of uses for std::optional. Brian Ebenezer Enterprises http://webEbenezer.net
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-21 09:25 -0800 |
| Message-ID | <9520a79a-0f8f-4097-bb6f-a465c66b6a9d@googlegroups.com> |
| In reply to | #70599 |
On Saturday, 21 December 2019 18:42:55 UTC+2, woodb...@gmail.com wrote: > On Friday, December 20, 2019 at 6:35:48 AM UTC-6, Öö Tiib 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?: > > > > 1) data in your program can not have optional, missing, lazily loaded > > properties. > > That is uselessly naive to hope about most real world data. > > Even if all data is really acquirable it may be expensive and pointless > > to do it always. > > > > 2) properties whose value may be missing has to be dynamically > > allocated so you can use nullptr as indication of it being missing. > > Really? Every int that may be unknown has to be made dynamically > > allocated? > > > > 3) such objects have to have internal "missing" state that is then > > checked in all interface methods of those. Types outside of your > > control like fundamentals or standard library types you need to > > manually wrap by add that "missing" state. > > Whole whopping wrapper class around int to add missing state > > to it? > > > > 4) You have external bools or flags somewhere that indicate > > if something is missing? > > Annoyingly error prone and confusing. > > > > 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. > > > > 6) You use some kind of mix of above "tricks"? > > 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. > > > > Any other ways? I doubt it. > > 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. > > You seem to be high on std::optional. This file: > https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc > > has this line: > cmwRequest* req=nullptr; > > You don't like that? I haven't tried it recently, but I suspect > making that an optional would puff up the size of my binary > without any benefit. That clown boltroll just snips every answer of mine to leave impression that I did not give those. I wrote: "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." So if you already have pointers then use nullptr indeed as "missing" state. > I think more highly of std::optional than std::any, but don't > find a lot of uses for std::optional. I also don't find any usage for std::any. How should anyone trust interface that accepts anything? Did they test it?
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-18 11:28 -0800 |
| Message-ID | <4de88921-c6cf-4b58-a9d9-b2aff4d721ab@googlegroups.com> |
| In reply to | #70557 |
On Wednesday, 18 December 2019 18:26:54 UTC+2, bol...@nowhere.co.uk wrote: > On Tue, 17 Dec 2019 08:32:21 -0800 (PST) > =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: > >On Tuesday, 17 December 2019 11:37:49 UTC+2, bol...@nowhere.co.uk wrote: > >> Rubbish. Optional is just a lazy inefficient way of checking valid return > >> object values. Any decently designed class thats going to have many instances > > > >> thrown around should have a valid flag or some other marker showing whether > >it > >> can be used so optional not required. > > > >"Invalid"/"Incomplete"/"Half-received"/"Erred" states of objects are the common > > > >source of errors. You are rare fan of iostreams failbit-badbit garbage it > >seems? > > I never use iostreams unless I have no choice. They're just bloat inbetween > my code and the OS I/O system. > > My point is any class likely to be flung around a program as instances usually > has some kind of flag designating whether an instance is valid. Personally > however I prefer pointers. What is the point to fling that invalid stuff around? That is another typical performance drain, waste of storage and source of errors. Pass reference to good stuff if you have it and call overload without that parameter when you don't have it. > >> And if you're dealing with pointers just > >> return NULL. > > > >Per-object dynamic memory management is common source of inefficiency. > > 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? Mr Flibble was correct, it is clueless response. Optional is not good for that. Prefer exceptions as signals of failures. When failure is common (and it matters) use std::variant<Value, FailureDetails> as alternative to exceptions. Optional is good for *storing* values that may be missing (or acquired lazily when needed) without dynamic memory management and loss of locality. > >> Non POD types should never be unioned unless memory space is so critical > >that > >> there is no other option. In which case why are you using C++ in the first > >> place? > > > >Because C++ is often more efficient than alternatives and can union non-pod > >types in variant. If C++ can't do it then there are no chance to do better job > >with your Perl ... or what you program there. > > I don't use Perl. Doesn't matter. You expressed opinion that C++ is wrong tool when memory space is critical. So I just imagined that maybe some Perl programmer can say such nonsense. > > >> And a standard union is fine for PODs and in all sane use cases for > >> a union you HAVE to know what types you're dealing with as you're probably > >> dealing with very low level operations so leaving it to the compiler makes > >> no sense. > > > >PODs are useful only for dealing with those low level operations. Most > >embedded controllers have tens of kilobytes of RAM (since it just costs > >nothing) and so are often expected to be quite smart these days. > > No all of them. Some PICs have < 1K of RAM. > > Anyway, when someone shows me a sane use case of unionising non POD types > perhaps I'll see variant as something other than just more noise in the C++ > spec. Huh? PODs are really only useful for low level operations with data of precise memory layout. On rest of cases a class with constructors, destructors, private members, virtual member functions and/or non-POD data members is more handy. Don't you use classes? Union of classes can be great performance optimization.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> |
|---|---|
| Date | 2019-12-18 20:00 +0000 |
| Message-ID | <7zvKF.6656$9W3.3776@fx14.dcg> |
| In reply to | #70563 |
On 18/12/2019 19:28, Öö Tiib wrote: > On Wednesday, 18 December 2019 18:26:54 UTC+2, bol...@nowhere.co.uk wrote: >> On Tue, 17 Dec 2019 08:32:21 -0800 (PST) >> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: >>> On Tuesday, 17 December 2019 11:37:49 UTC+2, bol...@nowhere.co.uk wrote: >>>> Rubbish. Optional is just a lazy inefficient way of checking valid return >>>> object values. Any decently designed class thats going to have many instances >>> >>>> thrown around should have a valid flag or some other marker showing whether >>> it >>>> can be used so optional not required. >>> >>> "Invalid"/"Incomplete"/"Half-received"/"Erred" states of objects are the common >>> >>> source of errors. You are rare fan of iostreams failbit-badbit garbage it >>> seems? >> >> I never use iostreams unless I have no choice. They're just bloat inbetween >> my code and the OS I/O system. >> >> My point is any class likely to be flung around a program as instances usually >> has some kind of flag designating whether an instance is valid. Personally >> however I prefer pointers. > > What is the point to fling that invalid stuff around? That is another > typical performance drain, waste of storage and source of errors. > Pass reference to good stuff if you have it and call overload without > that parameter when you don't have it. > >>>> And if you're dealing with pointers just >>>> return NULL. >>> >>> Per-object dynamic memory management is common source of inefficiency. >> >> 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? > > Mr Flibble was correct, it is clueless response. Optional is not good > for that. Prefer exceptions as signals of failures. When failure is > common (and it matters) use std::variant<Value, FailureDetails> as > alternative to exceptions. Optional is good for *storing* values that > may be missing (or acquired lazily when needed) without dynamic memory > management and loss of locality. Yes, you shouldn't use empty optionals to indicate an error: use exceptions for that. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin “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," Byrne 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 | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-18 22:12 +0200 |
| Message-ID | <qte17b$p2g$1@dont-email.me> |
| In reply to | #70557 |
On 18.12.2019 18:26, boltar@nowhere.co.uk wrote: > Anyway, when someone shows me a sane use case of unionising non POD types > perhaps I'll see variant as something other than just more noise in the C++ > spec. Use cases for a non-POD type in an union are the same as using a non-POD type anywhere else, mostly RAII and encapsulation. An alternative (which was needed before C++11) would be to use POD types in the union and replicate the RAII and encapsulation in the class wrapping the union, but this would mean reinventing a lot of wheels and losing modularity. For example, if one of the union types is smart pointer, one would need to basically store a raw pointer inside the union and reimplement the smart pointer functionality inside the wrapper class. A union is just a technical tool for reducing memory usage. An obvious example is a polymorphic item type in a scripting language interpreter which could store either single integers or floating-point values, but at the same time strings (esp. useful with small string optimization), smartpointers to larger data objects, etc. It would make no sense to use a 10x larger class than necessary for the most heavily used data structure in the program. Another technical tool which can be used for reducing such memory usage is derivation. The Python interpreter (written in C) is basically using derivation, with every item allocated dynamically, featuring tedious manual refcounting and multi-stage vtables. This has its own benefits and drawbacks. Python model uses more memory, more dynamic allocations and more redirection than a union-based approach would have, but at the same time it is more readily extendable.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.co.uk |
|---|---|
| Date | 2019-12-19 08:47 +0000 |
| Message-ID | <qtfdfh$e1d$1@gioia.aioe.org> |
| In reply to | #70570 |
On Wed, 18 Dec 2019 22:12:26 +0200 Paavo Helde <myfirstname@osa.pri.ee> wrote: >On 18.12.2019 18:26, boltar@nowhere.co.uk wrote: >> Anyway, when someone shows me a sane use case of unionising non POD types >> perhaps I'll see variant as something other than just more noise in the C++ >> spec. > >Use cases for a non-POD type in an union are the same as using a non-POD >type anywhere else, mostly RAII and encapsulation. An alternative (which >was needed before C++11) would be to use POD types in the union and >replicate the RAII and encapsulation in the class wrapping the union, >but this would mean reinventing a lot of wheels and losing modularity. >For example, if one of the union types is smart pointer, one would need >to basically store a raw pointer inside the union and reimplement the >smart pointer functionality inside the wrapper class. > >A union is just a technical tool for reducing memory usage. An obvious >example is a polymorphic item type in a scripting language interpreter >which could store either single integers or floating-point values, but >at the same time strings (esp. useful with small string optimization), >smartpointers to larger data objects, etc. It would make no sense to use >a 10x larger class than necessary for the most heavily used data >structure in the program. I'm not seeing any kind of sane argument here. If you wish to store instances of variable sizes that can be accessed in a common way then just use base class pointers pointing to various levels of derived classes and use virtual functions as appropriate. As has been done for 2 decades. All I can see is a very poor and confusing - not to mention error prone - reinvention of the wheel. >Another technical tool which can be used for reducing such memory usage >is derivation. Exactly.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-30 14:03 +0100 |
| Message-ID | <qucsjt$6pb$1@news.albasani.net> |
| In reply to | #70537 |
> Rubbish. Optional is just a lazy inefficient way of checking valid return > object values. Any decently designed class thats going to have many instances > thrown around should have a valid flag or some other marker showing whether > it can be used so optional not required. ... std::optional is implemented with a single bool and an anonymous union that optionally contains the object. So it does exactly the same as if you add a flag to your class. And adding a flag to an existing class isn't always possible because you might not have designed the class on your own. And it might be often useless because the class might not always be used with optional instan- tiation. So std::optional<T> is the best way here. And it is very convenient to use because of its overloaded ->-operator. > Non POD types should never be unioned unless memory space is so critical > that there is no other option. Non-pod types usually have dependent resources which shall be allocated or not. So unioning perfectly makes sense to instantiate only one of them. You simply don't understand the implications of what you say. The scope of your thoughts is very short.
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2019-12-18 09:47 -0800 |
| Message-ID | <6739c637-2f90-4f04-96f3-1eb352c3dc3d@googlegroups.com> |
| In reply to | #70509 |
On Monday, December 16, 2019 at 1:21:40 PM UTC-5, Öö Tiib wrote: > Union is > rather good performance optimization in decent hands, variant is a easy > to use reliable union, and optional is a variant between value and > nothing. So "purist" who can wield such trivial tools typically > wins such a sorry "latitudinarians" who can't. optional has a pleasing interface, variant (in my opinion :)) less so. I experimented with providing a non-throwing alternative interface with optional, but value and nothing aren't usually the states that you want, rather value and error condition. Daniel
[toc] | [prev] | [next] | [standalone]
Page 12 of 16 — ← Prev page 1 … 10 11 [12] 13 14 … 16 Next page →
Back to top | Article view | comp.lang.c++
csiph-web