Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #80243 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2021-06-10 12:18 +0200 |
| Last post | 2021-06-11 17:06 +0200 |
| Articles | 20 on this page of 252 — 51 participants |
Back to article view | Back to comp.lang.c++
Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-10 12:18 +0200
Re: Why does vector::reserve() not grow exponentially ? Bo Persson <bo@bo-persson.se> - 2021-06-10 13:21 +0200
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-10 14:37 +0300
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-10 15:44 +0200
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-10 16:39 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-10 16:47 +0200
Re: Why does vector::reserve() not grow exponentially ? Bo Persson <bo@bo-persson.se> - 2021-06-10 22:00 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-10 22:09 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-11 06:57 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-11 13:16 +0200
Re: Why does vector::reserve() not grow exponentially ? Bo Persson <bo@bo-persson.se> - 2021-06-11 13:27 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-11 13:53 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-11 19:12 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 04:09 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-12 08:50 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 15:43 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-12 18:59 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-13 07:31 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-13 08:09 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-13 14:12 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-13 09:50 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-13 16:05 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-13 11:23 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-13 18:56 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-13 13:37 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-14 05:16 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-14 07:00 -0400
Re: Why does vector::reserve() not grow exponentially MrSpook_t0Y6kgpd5@3dryi7no.gov - 2021-06-13 08:39 +0000
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-11 19:11 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 04:10 +0200
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-11 22:18 -0700
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 08:18 +0200
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-12 01:43 -0700
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 11:00 +0200
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-12 02:04 -0700
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 11:15 +0200
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-12 02:24 -0700
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 11:30 +0200
Re: Why does vector::reserve() not grow exponentially ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-06-12 12:59 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 13:27 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 13:19 +0200
Re: Why does vector::reserve() not grow exponentially ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-06-12 13:30 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 13:39 +0200
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-12 14:04 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 15:30 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-12 08:53 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 15:31 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-12 18:43 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-13 07:31 +0200
Re: Why does vector::reserve() not grow exponentially ? Richard Damon <Richard@Damon-Family.org> - 2021-06-13 07:48 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-13 14:03 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-13 14:12 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-13 11:21 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-13 18:55 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-13 13:38 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-14 05:18 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-14 07:00 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-14 13:08 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-14 18:35 -0400
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-14 22:49 -0700
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-15 08:11 -0400
Re: Why does vector::reserve() not grow exponentially MrSpook_ka1o_g@otuej9sdvqn8a4.gov.uk - 2021-06-15 12:54 +0000
Re: Why does vector::reserve() not grow exponentially "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-15 13:09 -0700
Re: Why does vector::reserve() not grow exponentially MrSpook_b1My5@751smt.edu - 2021-06-16 08:44 +0000
Re: Why does vector::reserve() not grow exponentially Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-16 13:11 +0300
Re: Why does vector::reserve() not grow exponentially MrSpook_p6g@ktmy0vg8lj7jxt.biz - 2021-06-16 10:21 +0000
Re: Why does vector::reserve() not grow exponentially Sam <sam@email-scan.com> - 2021-06-16 06:41 -0400
Re: Why does vector::reserve() not grow exponentially MrSpook_F2ryro5_b@ugk_rvxkkm.gov - 2021-06-16 11:11 +0000
Re: Why does vector::reserve() not grow exponentially Sam <sam@email-scan.com> - 2021-06-16 08:25 -0400
Re: Why does vector::reserve() not grow exponentially Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-16 16:10 +0300
Re: Why does vector::reserve() not grow exponentially David Brown <david.brown@hesbynett.no> - 2021-06-16 15:59 +0200
Re: Why does vector::reserve() not grow exponentially MrSpook_ucGx3e4l@x8gqtuqjwl9z3g.com - 2021-06-16 13:47 +0000
Re: Why does vector::reserve() not grow exponentially scott@slp53.sl.home (Scott Lurndal) - 2021-06-16 15:09 +0000
Re: Why does vector::reserve() not grow exponentially Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-16 17:50 +0200
Re: Why does vector::reserve() not grow exponentially MrSpook_hjesjs@8pot25r5sg1xe.info - 2021-06-16 15:45 +0000
Re: Why does vector::reserve() not grow exponentially Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-16 21:08 +0300
Re: Why does vector::reserve() not grow exponentially scott@slp53.sl.home (Scott Lurndal) - 2021-06-16 19:06 +0000
Re: Why does vector::reserve() not grow exponentially Juha Nieminen <nospam@thanks.invalid> - 2021-06-16 13:09 +0000
Re: Why does vector::reserve() not grow exponentially ? Manfred <noname@add.invalid> - 2021-06-15 20:30 +0200
Re: Why does vector::reserve() not grow exponentially ? Juha Nieminen <nospam@thanks.invalid> - 2021-06-16 04:33 +0000
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-16 10:35 +0200
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-16 11:18 +0200
Re: Why does vector::reserve() not grow exponentially ? MrSpook_u_kch7_3@abbbp5z5c0iw8rwgxg4.gov - 2021-06-16 09:34 +0000
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-16 11:53 +0200
Re: Why does vector::reserve() not grow exponentially ? MrSpook_ge@ldwlviy1f9uwd19thc.gov - 2021-06-16 10:19 +0000
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-16 13:09 +0200
Re: Why does vector::reserve() not grow exponentially ? MrSpook_3_fdyox@sg5nvjmv741xbigdp6.info - 2021-06-16 09:04 +0000
Re: Why does vector::reserve() not grow exponentially ? Juha Nieminen <nospam@thanks.invalid> - 2021-06-16 09:20 +0000
Re: Why does vector::reserve() not grow exponentially ? Tim Woodall <news001@woodall.me.uk> - 2021-06-16 09:49 +0000
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-16 13:14 +0200
Re: Why does vector::reserve() not grow exponentially ? MrSpook_G1Sw6pdcqz@5a69.edu - 2021-06-16 11:25 +0000
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-16 14:43 +0200
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-16 14:44 +0200
Re: Why does vector::reserve() not grow exponentially ? MrSpook_g3w@2ur2yrijxtw7d3jt394yu9dp.org - 2021-06-16 13:48 +0000
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-16 16:07 +0200
Re: Why does vector::reserve() not grow exponentially ? MrSpook_74D@ov88_wt8h.co.uk - 2021-06-16 13:54 +0000
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-16 19:55 +0200
Re: Why does vector::reserve() not grow exponentially ? Juha Nieminen <nospam@thanks.invalid> - 2021-06-16 13:14 +0000
Re: Why does vector::reserve() not grow exponentially ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-16 10:38 -0400
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-16 19:58 +0200
Re: Why does vector::reserve() not grow exponentially ? "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-06-17 13:45 -0700
Re: Why does vector::reserve() not grow exponentially ? Real Troll <real.troll@trolls.com> - 2021-06-17 21:15 +0000
Re: Why does vector::reserve() not grow exponentially ? Manfred <noname@add.invalid> - 2021-06-18 15:23 +0200
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-18 08:56 +0200
Re: Why does vector::reserve() not grow exponentially ? "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-06-18 08:06 -0700
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-18 17:41 +0200
Re: Why does vector::reserve() not grow exponentially ? "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-06-18 14:31 -0700
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-19 02:53 -0700
Re: Why does vector::reserve() not grow exponentially ? Ian Collins <ian-news@hotmail.com> - 2021-06-19 11:10 +1200
Re: Why does vector::reserve() not grow exponentially ? MrSpook_gavL@es9w71p.tv - 2021-06-18 15:53 +0000
Re: Why does vector::reserve() not grow exponentially ? scott@slp53.sl.home (Scott Lurndal) - 2021-06-18 16:06 +0000
Re: Why does vector::reserve() not grow exponentially ? MrSpook_Zp_@opm5ve6jyhq.ac.uk - 2021-06-18 09:22 +0000
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-16 04:55 -0700
Re: Why does vector::reserve() not grow exponentially ? Juha Nieminen <nospam@thanks.invalid> - 2021-06-16 13:16 +0000
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-16 11:03 -0700
Re: Why does vector::reserve() not grow exponentially ? Juha Nieminen <nospam@thanks.invalid> - 2021-06-17 05:35 +0000
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-17 16:51 -0700
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-17 20:19 -0400
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-17 18:22 -0700
Re: Why does vector::reserve() not grow exponentially ? MrSpook_6a2az@yxcggolr9p.com - 2021-06-18 09:24 +0000
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-18 08:20 -0400
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-18 15:38 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-18 18:01 -0400
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-19 12:32 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-19 09:12 -0400
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-19 15:24 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-19 17:33 -0400
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-20 09:45 +0200
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-19 03:33 -0700
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-19 09:38 -0400
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-19 12:50 -0700
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-19 17:46 -0400
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-20 05:19 -0700
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-19 23:27 +0300
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-19 17:50 -0400
Re: Why does vector::reserve() not grow exponentially ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-19 16:44 -0700
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-18 17:46 +0300
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-18 17:41 -0400
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-19 11:21 +0300
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-19 09:08 -0400
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-20 21:09 +0300
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-20 11:59 -0700
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-20 22:02 +0300
Re: Why does vector::reserve() not grow exponentially ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-20 14:56 -0700
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-21 09:22 +0300
Re: Why does vector::reserve() not grow exponentially ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-21 16:46 -0700
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-22 10:56 +0300
Re: Why does vector::reserve() not grow exponentially ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-22 12:49 -0700
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-23 01:36 +0300
Re: Why does vector::reserve() not grow exponentially ? scott@slp53.sl.home (Scott Lurndal) - 2021-06-23 14:32 +0000
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-23 16:55 +0200
Re: Why does vector::reserve() not grow exponentially ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-24 16:13 -0700
Re: Why does vector::reserve() not grow exponentially ? scott@slp53.sl.home (Scott Lurndal) - 2021-06-25 14:34 +0000
Re: Why does vector::reserve() not grow exponentially ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-25 12:16 -0700
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-22 15:36 -0700
Re: Why does vector::reserve() not grow exponentially ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-24 16:09 -0700
Re: Why does vector::reserve() not grow exponentially ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-21 17:12 -0700
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-20 19:03 -0400
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-21 09:52 +0300
Re: Why does vector::reserve() not grow exponentially ? red floyd <no.spam.here@its.invalid> - 2021-06-18 00:18 -0700
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-18 02:06 -0700
Re: Why does vector::reserve() not grow exponentially ? Juha Nieminen <nospam@thanks.invalid> - 2021-06-21 12:43 +0000
Re: Why does vector::reserve() not grow exponentially ? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-06-21 22:48 +0100
Re: Why does vector::reserve() not grow exponentially ? Juha Nieminen <nospam@thanks.invalid> - 2021-06-22 05:30 +0000
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-21 23:12 -0700
Re: Why does vector::reserve() not grow exponentially ? MrSpook_D_a3U17y@j_az.net - 2021-06-22 07:14 +0000
Re: Why does vector::reserve() not grow exponentially ? Manfred <noname@add.invalid> - 2021-06-22 13:49 +0200
Re: Why does vector::reserve() not grow exponentially ? Juha Nieminen <nospam@thanks.invalid> - 2021-06-22 08:03 +0000
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-22 01:28 -0700
Re: Why does vector::reserve() not grow exponentially ? Juha Nieminen <nospam@thanks.invalid> - 2021-06-23 06:19 +0000
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-23 04:18 -0700
Re: Why does vector::reserve() not grow exponentially ? Juha Nieminen <nospam@thanks.invalid> - 2021-06-21 12:39 +0000
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-15 08:01 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-15 08:12 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-15 15:34 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-15 17:37 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-16 02:17 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-15 21:11 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-16 07:09 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-16 06:37 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-16 13:01 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-16 08:16 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-16 15:35 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-16 17:40 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-16 13:40 +0200
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-16 18:10 +0300
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-16 14:37 +0300
Re: Why does vector::reserve() not grow exponentially ? scott@slp53.sl.home (Scott Lurndal) - 2021-06-16 15:04 +0000
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-16 17:37 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-16 17:40 -0400
Re: Why does vector::reserve() not grow exponentially ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-16 16:25 -0700
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-16 23:17 -0400
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-17 09:22 +0200
Re: Why does vector::reserve() not grow exponentially ? MrSpook_e0mt@hszpo62mi.com - 2021-06-17 08:31 +0000
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-17 07:11 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-17 09:24 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-17 16:43 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-13 08:11 -0400
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-13 08:10 -0400
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-12 14:01 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 15:34 +0200
Re: Why does vector::reserve() not grow exponentially ? Ian Collins <ian-news@hotmail.com> - 2021-06-13 13:01 +1200
Re: Why does vector::reserve() not grow exponentially ? Öö Tiib <ootiib@hot.ee> - 2021-06-13 07:39 -0700
Re: Why does vector::reserve() not grow exponentially ? Bo Persson <bo@bo-persson.se> - 2021-06-12 10:51 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 11:03 +0200
Re: Why does vector::reserve() not grow exponentially ? Bo Persson <bo@bo-persson.se> - 2021-06-12 13:07 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 13:22 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-12 08:52 -0400
Re: Why does vector::reserve() not grow exponentially ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-10 16:51 -0700
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-11 09:52 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-11 13:17 +0200
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-11 13:45 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-11 13:54 +0200
Re: Why does vector::reserve() not grow exponentially ? David Brown <david.brown@hesbynett.no> - 2021-06-11 15:58 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-11 16:35 +0200
Re: Why does vector::reserve() not grow exponentially ? Manfred <noname@add.invalid> - 2021-06-11 17:11 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-11 17:12 +0200
Re: Why does vector::reserve() not grow exponentially ? Christian Gollwitzer <auriocus@gmx.de> - 2021-06-11 21:15 +0200
Re: Why does vector::reserve() not grow exponentially ? Bo Persson <bo@bo-persson.se> - 2021-06-11 21:58 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-12 04:11 +0200
Re: Why does vector::reserve() not grow exponentially ? Sam <sam@email-scan.com> - 2021-06-11 06:55 -0400
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-11 13:19 +0200
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-10 16:51 +0200
Re: Why does vector::reserve() not grow exponentially ? MrSpook_sw@08_cl170xu11o4f8xcg45.co.uk - 2021-06-10 15:25 +0000
Re: Why does vector::reserve() not grow exponentially ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-10 18:18 +0200
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-10 22:40 +0300
Re: Why does vector::reserve() not grow exponentially ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-06-10 22:35 +0200
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-11 09:23 +0300
Re: Why does vector::reserve() not grow exponentially ? Bo Persson <bo@bo-persson.se> - 2021-06-11 12:02 +0200
Re: Why does vector::reserve() not grow exponentially ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-11 03:05 -0700
Re: Why does vector::reserve() not grow exponentially ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-11 03:22 -0700
Re: Why does vector::reserve() not grow exponentially ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-06-11 12:25 +0200
Re: Why does vector::reserve() not grow exponentially ? MrSpook_4421gcxq@fceufv2.ac.uk - 2021-06-11 11:39 +0000
Re: Why does vector::reserve() not grow exponentially ? MrSpook_3wcC2u9@cns8.net - 2021-06-11 10:18 +0000
Re: Why does vector::reserve() not grow exponentially ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-11 03:27 -0700
Re: Why does vector::reserve() not grow exponentially ? MrSpook_4bkzrb03@tu45utvus6nuc.tv - 2021-06-11 10:17 +0000
Re: Why does vector::reserve() not grow exponentially ? Manfred <noname@add.invalid> - 2021-06-11 13:22 +0200
Re: Why does vector::reserve() not grow exponentially ? MrSpook_0nG@p900whw6_n8r7ovwuul.ac.uk - 2021-06-11 11:34 +0000
Re: Why does vector::reserve() not grow exponentially ? Manfred <noname@add.invalid> - 2021-06-11 14:14 +0200
Re: Why does vector::reserve() not grow exponentially ? MrSpook_p_5Ko4g@21yhpi_n4fck_wfz.org - 2021-06-11 12:50 +0000
Re: Why does vector::reserve() not grow exponentially ? MrSpook_0sk4i3p@b1km5k73i1.edu - 2021-06-11 09:24 +0000
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-11 14:18 +0300
Re: Why does vector::reserve() not grow exponentially ? Bo Persson <bo@bo-persson.se> - 2021-06-11 11:59 +0200
Re: Why does vector::reserve() not grow exponentially ? MrSpook_jyc2xeWf9@aw55u6.gov - 2021-06-11 10:17 +0000
Re: Why does vector::reserve() not grow exponentially ? MrSpook_3dnim@5ooodqy.co.uk - 2021-06-11 09:19 +0000
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-11 14:26 +0300
Re: Why does vector::reserve() not grow exponentially ? MrSpook_35@s879vvmwpgee7rpqv.net - 2021-06-11 11:38 +0000
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-11 15:14 +0300
Re: Why does vector::reserve() not grow exponentially ? MrSpook_uQjuVe@5szcyauh_pjzi228wvwn.info - 2021-06-11 12:52 +0000
Re: Why does vector::reserve() not grow exponentially ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-11 16:37 +0300
Re: Why does vector::reserve() not grow exponentially ? MrSpook_9fpRQm@i1z834r.net - 2021-06-11 14:58 +0000
Re: Why does vector::reserve() not grow exponentially ? Manfred <noname@add.invalid> - 2021-06-11 17:06 +0200
Page 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2021-06-15 08:11 -0400 |
| Subject | Re: Why does vector::reserve() not grow exponentially ? |
| Message-ID | <cone.1623759103.231569.44819.1004@monster.email-scan.com> |
| In reply to | #80413 |
[Multipart message — attachments visible in raw view] — view raw
Öö Tiib writes: > IMHO starting from C++17 the language was sabotaged through > standardization. It is overly complicated. Stroustrup and Sutter > try hard to collect advice how to use C++. I would move the point of no return to C++20, and I would describe it as hijacked rather than sabotaged. "if constexpr" was somewhat discombobulating but I can see some merit to it. It does simplify some things that would, otherwise would require a novel to implement. On the other hand, co-routines are a solution in search of a problem. Their only reason for existence is because Microsoft Windows sucks shit with real multi-threaded code, but it can implement that fake-threading model reasonably well. It is no accident that co-routines were authored by Microsoft, and they successfully hijacked the standardization process to cram it in. And, of course, Visual C++ was pretty prompt in implementing it.
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_ka1o_g@otuej9sdvqn8a4.gov.uk |
|---|---|
| Date | 2021-06-15 12:54 +0000 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <saa7ti$mfe$1@gioia.aioe.org> |
| In reply to | #80417 |
On Tue, 15 Jun 2021 08:11:43 -0400 Sam <sam@email-scan.com> wrote: >I would move the point of no return to C++20, and I would describe it as =20 >hijacked rather than sabotaged. "if constexpr" was somewhat discombobulat= >ing =20 >but I can see some merit to it. It does simplify some things that would, =20 >otherwise would require a novel to implement. > >On the other hand, co-routines are a solution in search of a problem. The= IMO a lot of new C++ since 98 is a solution in search of a problem. The big wins from 2011 onwards for me are: auto for(<type> <var>: <container>) C++ threads (for simple threading) lambdas std::function std::shared_ptr initialiser lists variadic templates The rest is just noise and probably there to tick boxes because 0.01% of devs might use them. As for co-routines I can't think of any sane use case for them either that can't be solved much more neatly using a normal function/method and class member or static/global variables. >ir =20 >only reason for existence is because Microsoft Windows sucks shit with re= >al =20 >multi-threaded code, but it can implement that fake-threading model =20 Sucks shit with multiprocess too. IIRC however co-routines are one of the few C++ language facilities that cannot be simulated in C, you'd have to use assember too to munge the stack correctly.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-06-15 13:09 -0700 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <sab1dl$k66$1@dont-email.me> |
| In reply to | #80418 |
On 6/15/2021 5:54 AM, MrSpook_ka1o_g@otuej9sdvqn8a4.gov.uk wrote: > On Tue, 15 Jun 2021 08:11:43 -0400 > Sam <sam@email-scan.com> wrote: >> I would move the point of no return to C++20, and I would describe it as =20 >> hijacked rather than sabotaged. "if constexpr" was somewhat discombobulat= >> ing =20 >> but I can see some merit to it. It does simplify some things that would, =20 >> otherwise would require a novel to implement. >> >> On the other hand, co-routines are a solution in search of a problem. The= > > IMO a lot of new C++ since 98 is a solution in search of a problem. The big > wins from 2011 onwards for me are: > > auto > for(<type> <var>: <container>) > C++ threads (for simple threading) I would also add C++ atomics and memory barriers. > lambdas > std::function > std::shared_ptr > initialiser lists > variadic templates > > The rest is just noise and probably there to tick boxes because 0.01% of > devs might use them. > > As for co-routines I can't think of any sane use case for them either that > can't be solved much more neatly using a normal function/method and class > member or static/global variables. > >> ir =20 >> only reason for existence is because Microsoft Windows sucks shit with re= >> al =20 >> multi-threaded code, but it can implement that fake-threading model =20 > > Sucks shit with multiprocess too. > > IIRC however co-routines are one of the few C++ language facilities that > cannot be simulated in C, you'd have to use assember too to munge the stack > correctly. > >
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_b1My5@751smt.edu |
|---|---|
| Date | 2021-06-16 08:44 +0000 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <sacdlv$1cne$1@gioia.aioe.org> |
| In reply to | #80421 |
On Tue, 15 Jun 2021 13:09:23 -0700 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote: >On 6/15/2021 5:54 AM, MrSpook_ka1o_g@otuej9sdvqn8a4.gov.uk wrote: >> On Tue, 15 Jun 2021 08:11:43 -0400 >> Sam <sam@email-scan.com> wrote: >>> I would move the point of no return to C++20, and I would describe it as =20 > >>> hijacked rather than sabotaged. "if constexpr" was somewhat discombobulat= >>> ing =20 >>> but I can see some merit to it. It does simplify some things that would, =20 > >>> otherwise would require a novel to implement. >>> >>> On the other hand, co-routines are a solution in search of a problem. The= >> >> IMO a lot of new C++ since 98 is a solution in search of a problem. The big >> wins from 2011 onwards for me are: >> >> auto >> for(<type> <var>: <container>) >> C++ threads (for simple threading) > >I would also add C++ atomics and memory barriers. The problem with C++ atomics is that they're not always atomic. Eg when using +=, -= type operators, which makes them a bit pointless IMO. Better to just use a lock and be 100% sure.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-06-16 13:11 +0300 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <sacinq$cqa$1@dont-email.me> |
| In reply to | #80428 |
16.06.2021 11:44 MrSpook_b1My5@751smt.edu kirjutas: > > The problem with C++ atomics is that they're not always atomic. Eg when > using +=, -= type operators, which makes them a bit pointless IMO. Better to > just use a lock and be 100% sure. What makes you think so? These operations are guaranteed to be atomic: https://en.cppreference.com/w/cpp/atomic/atomic/operator_arith2
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_p6g@ktmy0vg8lj7jxt.biz |
|---|---|
| Date | 2021-06-16 10:21 +0000 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <sacjau$60l$1@gioia.aioe.org> |
| In reply to | #80435 |
On Wed, 16 Jun 2021 13:11:04 +0300 Paavo Helde <myfirstname@osa.pri.ee> wrote: >16.06.2021 11:44 MrSpook_b1My5@751smt.edu kirjutas: >> >> The problem with C++ atomics is that they're not always atomic. Eg when >> using +=, -= type operators, which makes them a bit pointless IMO. Better to >> just use a lock and be 100% sure. > >What makes you think so? These operations are guaranteed to be atomic: Well I've tried to use them in multithreaded code and I can assure you, at least on whatever version of gcc I was using at the time, they were not.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2021-06-16 06:41 -0400 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <cone.1623840061.948654.71297.1004@monster.email-scan.com> |
| In reply to | #80436 |
[Multipart message — attachments visible in raw view] — view raw
MrSpook_p6g@ktmy0vg8lj7jxt.biz writes: > On Wed, 16 Jun 2021 13:11:04 +0300 > Paavo Helde <myfirstname@osa.pri.ee> wrote: > >16.06.2021 11:44 MrSpook_b1My5@751smt.edu kirjutas: > >> > >> The problem with C++ atomics is that they're not always atomic. Eg when > >> using +=, -= type operators, which makes them a bit pointless IMO. Better > to > >> just use a lock and be 100% sure. > > > >What makes you think so? These operations are guaranteed to be atomic: > > Well I've tried to use them in multithreaded code and I can assure you, at > least on whatever version of gcc I was using at the time, they were not. There's a common misconception that using atomics is sufficient for thread- safety. That's not true. Using +=10 and +=17, for example, only guarantees at some point the end result will be 27 more than where it started, presuming that nothing else happens. However, it is unspecified when this joyous event occurs and is observable by a given execution thread. That requires sequencing.
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_F2ryro5_b@ugk_rvxkkm.gov |
|---|---|
| Date | 2021-06-16 11:11 +0000 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <sacm88$1kgi$1@gioia.aioe.org> |
| In reply to | #80438 |
On Wed, 16 Jun 2021 06:41:01 -0400 Sam <sam@email-scan.com> wrote: >> Well I've tried to use them in multithreaded code and I can assure you, at >> least on whatever version of gcc I was using at the time, they were not. > >There's a common misconception that using atomics is sufficient for thread- >safety. That's not true. Using +=10 and +=17, for example, only guarantees >at some point the end result will be 27 more than where it started, >presuming that nothing else happens. However, it is unspecified when this >joyous event occurs and is observable by a given execution thread. That >requires sequencing. Then whats the point of std::atomic? The only time people need atomic operations is precisely during multithreaded or parallel style programming. Even SysV semaphores can manage true atomicity between threads.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2021-06-16 08:25 -0400 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <cone.1623846318.874013.73895.1004@monster.email-scan.com> |
| In reply to | #80442 |
[Multipart message — attachments visible in raw view] — view raw
MrSpook_F2ryro5_b@ugk_rvxkkm.gov writes: > On Wed, 16 Jun 2021 06:41:01 -0400 > Sam <sam@email-scan.com> wrote: > >> Well I've tried to use them in multithreaded code and I can assure you, at > >> least on whatever version of gcc I was using at the time, they were not. > > > >There's a common misconception that using atomics is sufficient for thread- > >safety. That's not true. Using +=10 and +=17, for example, only guarantees > >at some point the end result will be 27 more than where it started, > >presuming that nothing else happens. However, it is unspecified when this > >joyous event occurs and is observable by a given execution thread. That > >requires sequencing. > > Then whats the point of std::atomic? The only time people need atomic > operations is precisely during multithreaded or parallel style programming. > Even SysV semaphores can manage true atomicity between threads. There are some situations where atomic variables are what the doctor ordered. The C++ library's std::shared_ptr is a perfect example. If its destructor decrements the shared reference count and becomes zero it logically means that no other instance of std::shared_ptr exists, so it's safe to destroy the referenced object. In all other cases, the actual non-0 result is irrelevant, and does not have to precisely 54tl4f6 the count of std::shared_ptrs of the same object that remain in scope. But if, at any given moment, all std::shared_ptrs are getting destroyed the atomic counter guarantees that exactly one execution thread's destructor will observe the final reference count of 0, and destroy the object. Who cares which execution thread does it, that's irrelevant. But as long as there is at least one hold-out somewhere it will never reach 0 in any execution thread. Also one could use atomic variables, manually, with memory barriers and reinvent the wheel called "sequencing", if there's some pressing need to do so and std::mutex doesn't fit the bill.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-06-16 16:10 +0300 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <sact94$mfo$1@dont-email.me> |
| In reply to | #80449 |
16.06.2021 15:25 Sam kirjutas: > Also one could use atomic variables, manually, with memory barriers and > reinvent the wheel called "sequencing", if there's some pressing need to > do so and std::mutex doesn't fit the bill. As far as I can see the atomics are by default using memory barriers. The default memory ordering is std::memory_order_seq_cst which means memory barriers and lots of other guarantees: https://en.cppreference.com/w/cpp/atomic/memory_order : "Atomic operations tagged memory_order_seq_cst not only order memory the same way as release/acquire ordering (everything that happened-before a store in one thread becomes a visible side effect in the thread that did a load), but also establish a single total modification order of all atomic operations that are so tagged." What you are describing seems more like std::memory_order_relaxed, which is not the default. What I have misunderstood?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-16 15:59 +0200 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <sad03q$beb$1@dont-email.me> |
| In reply to | #80449 |
On 16/06/2021 15:47, MrSpook_ucGx3e4l@x8gqtuqjwl9z3g.com wrote: > On Wed, 16 Jun 2021 08:25:18 -0400 > Sam <sam@email-scan.com> wrote: >>> Then whats the point of std::atomic? The only time people need atomic >>> operations is precisely during multithreaded or parallel style programming. >>> Even SysV semaphores can manage true atomicity between threads. >> >> There are some situations where atomic variables are what the doctor ordered. >> >> The C++ library's std::shared_ptr is a perfect example. If its destructor >> decrements the shared reference count and becomes zero it logically means >> that no other instance of std::shared_ptr exists, so it's safe to destroy > > Sure, but that only matters in a multi threaded program. And if atomic > isn't guaranteed to be thread safe then surely you'd be better off just > using mutex locks? > The atomics /are/ guaranteed to be thread safe. But they are not guaranteed to be synchronising (depending on the memory order given). The prime point of atomic increments and decrements is that you'll end up with the right number in the result, regardless of the order things are done. This makes relaxed atomics very efficient and lightweight compared to big locks.
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_ucGx3e4l@x8gqtuqjwl9z3g.com |
|---|---|
| Date | 2021-06-16 13:47 +0000 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <sacvdp$5kv$1@gioia.aioe.org> |
| In reply to | #80449 |
On Wed, 16 Jun 2021 08:25:18 -0400 Sam <sam@email-scan.com> wrote: >> Then whats the point of std::atomic? The only time people need atomic >> operations is precisely during multithreaded or parallel style programming. >> Even SysV semaphores can manage true atomicity between threads. > >There are some situations where atomic variables are what the doctor ordered. > >The C++ library's std::shared_ptr is a perfect example. If its destructor >decrements the shared reference count and becomes zero it logically means >that no other instance of std::shared_ptr exists, so it's safe to destroy Sure, but that only matters in a multi threaded program. And if atomic isn't guaranteed to be thread safe then surely you'd be better off just using mutex locks?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-06-16 15:09 +0000 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <avoyI.35750$J21.35086@fx40.iad> |
| In reply to | #80442 |
MrSpook_F2ryro5_b@ugk_rvxkkm.gov writes: >On Wed, 16 Jun 2021 06:41:01 -0400 >Sam <sam@email-scan.com> wrote: >>> Well I've tried to use them in multithreaded code and I can assure you, at >>> least on whatever version of gcc I was using at the time, they were not. >> >>There's a common misconception that using atomics is sufficient for thread- >>safety. That's not true. Using +=10 and +=17, for example, only guarantees >>at some point the end result will be 27 more than where it started, >>presuming that nothing else happens. However, it is unspecified when this >>joyous event occurs and is observable by a given execution thread. That >>requires sequencing. > >Then whats the point of std::atomic? The only time people need atomic >operations is precisely during multithreaded or parallel style programming. >Even SysV semaphores can manage true atomicity between threads. Incrementing a shared counter without first acquiring a lock is a perfect use for an atomic fetch_and_add (e.g. the ARM64 LDADD instruction or intel LOCK INC).
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-06-16 17:50 +0200 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <sad6jq$ru9$1@dont-email.me> |
| In reply to | #80465 |
> Incrementing a shared counter without first acquiring a lock is a perfect > use for an atomic fetch_and_add (e.g. the ARM64 LDADD instruction or intel > LOCK INC). No, fetch_and_add is LOCK XADD.
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_hjesjs@8pot25r5sg1xe.info |
|---|---|
| Date | 2021-06-16 15:45 +0000 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <sad6al$1oeb$1@gioia.aioe.org> |
| In reply to | #80465 |
On Wed, 16 Jun 2021 15:09:58 GMT scott@slp53.sl.home (Scott Lurndal) wrote: >MrSpook_F2ryro5_b@ugk_rvxkkm.gov writes: >>On Wed, 16 Jun 2021 06:41:01 -0400 >>Sam <sam@email-scan.com> wrote: >>>> Well I've tried to use them in multithreaded code and I can assure you, at >>>> least on whatever version of gcc I was using at the time, they were not. >>> >>>There's a common misconception that using atomics is sufficient for thread- >>>safety. That's not true. Using +=10 and +=17, for example, only guarantees >>>at some point the end result will be 27 more than where it started, >>>presuming that nothing else happens. However, it is unspecified when this >>>joyous event occurs and is observable by a given execution thread. That >>>requires sequencing. >> >>Then whats the point of std::atomic? The only time people need atomic >>operations is precisely during multithreaded or parallel style programming. >>Even SysV semaphores can manage true atomicity between threads. > >Incrementing a shared counter without first acquiring a lock is a perfect >use for an atomic fetch_and_add (e.g. the ARM64 LDADD instruction or intel >LOCK INC). I'm confused. Either std::atomic is thread safe or it isn't. Which is it?
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-06-16 21:08 +0300 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <sademb$oec$1@dont-email.me> |
| In reply to | #80468 |
16.06.2021 18:45 MrSpook_hjesjs@8pot25r5sg1xe.info kirjutas: > On Wed, 16 Jun 2021 15:09:58 GMT > scott@slp53.sl.home (Scott Lurndal) wrote: >> MrSpook_F2ryro5_b@ugk_rvxkkm.gov writes: >>> On Wed, 16 Jun 2021 06:41:01 -0400 >>> Sam <sam@email-scan.com> wrote: >>>>> Well I've tried to use them in multithreaded code and I can assure you, at >>>>> least on whatever version of gcc I was using at the time, they were not. >>>> >>>> There's a common misconception that using atomics is sufficient for thread- >>>> safety. That's not true. Using +=10 and +=17, for example, only guarantees >>>> at some point the end result will be 27 more than where it started, >>>> presuming that nothing else happens. However, it is unspecified when this >>>> joyous event occurs and is observable by a given execution thread. That >>>> requires sequencing. >>> >>> Then whats the point of std::atomic? The only time people need atomic >>> operations is precisely during multithreaded or parallel style programming. >>> Even SysV semaphores can manage true atomicity between threads. >> >> Incrementing a shared counter without first acquiring a lock is a perfect >> use for an atomic fetch_and_add (e.g. the ARM64 LDADD instruction or intel >> LOCK INC). > > I'm confused. Either std::atomic is thread safe or it isn't. Which is it? Of course it is thread-safe, that's what the name 'atomic' means. Alas, there are many definitions of "thread-safe", so one might easily get confused. In the case of atomics, "thread-safe" at least means the value of a particular atomic is well-defined and predictable when the atomic is accessed from multiple threads. Whether it means anything more depends on the used memory order and other details.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-06-16 19:06 +0000 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <1ZryI.573186$J_5.254872@fx46.iad> |
| In reply to | #80470 |
Paavo Helde <myfirstname@osa.pri.ee> writes:
>16.06.2021 18:45 MrSpook_hjesjs@8pot25r5sg1xe.info kirjutas:
>> On Wed, 16 Jun 2021 15:09:58 GMT
>> scott@slp53.sl.home (Scott Lurndal) wrote:
>>> MrSpook_F2ryro5_b@ugk_rvxkkm.gov writes:
>>>> On Wed, 16 Jun 2021 06:41:01 -0400
>>>> Sam <sam@email-scan.com> wrote:
>>>>>> Well I've tried to use them in multithreaded code and I can assure you, at
>>>>>> least on whatever version of gcc I was using at the time, they were not.
>>>>>
>>>>> There's a common misconception that using atomics is sufficient for thread-
>>>>> safety. That's not true. Using +=10 and +=17, for example, only guarantees
>>>>> at some point the end result will be 27 more than where it started,
>>>>> presuming that nothing else happens. However, it is unspecified when this
>>>>> joyous event occurs and is observable by a given execution thread. That
>>>>> requires sequencing.
>>>>
>>>> Then whats the point of std::atomic? The only time people need atomic
>>>> operations is precisely during multithreaded or parallel style programming.
>>>> Even SysV semaphores can manage true atomicity between threads.
>>>
>>> Incrementing a shared counter without first acquiring a lock is a perfect
>>> use for an atomic fetch_and_add (e.g. the ARM64 LDADD instruction or intel
>>> LOCK INC).
>>
>> I'm confused. Either std::atomic is thread safe or it isn't. Which is it?
>
>Of course it is thread-safe, that's what the name 'atomic' means. Alas,
>there are many definitions of "thread-safe", so one might easily get
>confused.
>
>In the case of atomics, "thread-safe" at least means the value of a
>particular atomic is well-defined and predictable when the atomic is
>accessed from multiple threads. Whether it means anything more depends
>on the used memory order and other details.
A good discussion of atomicity (from the ARM perspective) can be found
in B2.2 of the ARMv8 ARM (DDI0487)
B2.2 Atomicity in the Arm architecture
Atomicity is a feature of memory accesses, described as atomic
accesses. The Arm architecture description refers to
two types of atomicity, single-copy atomicity and multi-copy
atomicity. In the Armv8 architecture, the atomicity
requirements for memory accesses depend on the memory type,
and whether the access is explicit or implicit. For
more information, see:
· Requirements for single-copy atomicity.
· Properties of single-copy atomic accesses on page B2-130.
· Multi-copy atomicity on page B2-130.
· Requirements for multi-copy atomicity on page B2-130.
· Concurrent modification and execution of instructions on page B2-130.
For more information about the memory types, see Memory type overview on page B2-126.
Understanding atomicity at the application level requires understanding
the underlying hardware characteristics.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-06-16 13:09 +0000 |
| Subject | Re: Why does vector::reserve() not grow exponentially |
| Message-ID | <sact60$11gn$1@gioia.aioe.org> |
| In reply to | #80438 |
Sam <sam@email-scan.com> wrote:
> There's a common misconception that using atomics is sufficient for thread-
> safety. That's not true. Using +=10 and +=17, for example, only guarantees
> at some point the end result will be 27 more than where it started,
> presuming that nothing else happens. However, it is unspecified when this
> joyous event occurs and is observable by a given execution thread. That
> requires sequencing.
A variable being atomic guarantees that no thread will see a garbage value
for it. In other words, if one thread is changing the value of the atomic
variable and another thread is reading it at the same time, that second
thread is going to get either the old value or the new value, but it's
guaranteed that it will not get some third garbage value.
It also guarantees that two threads trying to assign something to the
atomic variable will not interfere with each other so that garbage ends
up in the variable. The final value will be one or the other (depending
on which thread was allowed to access it first and which one after that),
and while the variable may contain for a brief moment the value written
by the first thread before it gets the value written by the second thread,
at no point will it contain any garbage value that's neither (nor the
original).
Atomic variables (at least with std::atomic) are also what you would
call "volatile", in that any read and assignment will happen exactly
where the operation appears in the code and nowhere else. The compiler
will not optimize it away nor move it somewhere else (such as outside
a loop). It will read or assign it precisely where and how many times
you say.
Of course atomic variables can be misused. They are not locks, fences
or semaphores. For example using atomic variable for a spinlock is
most probably not going to work unless you use an atomic compare-and-swap
instruction or similar. Simply doing a
"if(atomic_var == true) { atomic_var = false; dosomething(); }"
will not stop two threads from incorrectly entering that critical
section at the same time. Atomic variables need to be used correctly.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-06-15 20:30 +0200 |
| Message-ID | <saarkv$gcc$1@gioia.aioe.org> |
| In reply to | #80413 |
On 6/15/2021 7:49 AM, Öö Tiib wrote: > IMHO starting from C++17 the language was sabotaged through > standardization. It is overly complicated. Stroustrup and Sutter > try hard to collect advice how to use C++. They do it ... for years ... see > <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines> > Lot of it is good advice but they also seem to be stuck in C++14 like > me. No u8 literals, "launder" or "if constexpr" in it. So now it is > perhaps best idea to not even read standard but take it narrower > and read what Stroustrup thinks C++ is. Wholeheartedly agree. BTW stressing the point on "std::launder" that IMO is a sick solution for a sick problem created by the committee - a problem that was simply non-existing in Stroustrup's C++. And he knows very well about the problem too, that C++ has become overly complicated as you say: "...C++17 did little to make our foundation more solid, regular, and complete. Instead, it added significant surface complexity and increased the number of features people need to learn. C++ could crumble under the weight of these – mostly not quite fully-baked – proposals." ... "We are on the path to something that could destroy C++. We must get off that path!" https://www.stroustrup.com/P0977-remember-the-vasa.pdf
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-06-16 04:33 +0000 |
| Message-ID | <sabuva$1ale$1@gioia.aioe.org> |
| In reply to | #80413 |
Öö Tiib <ootiib@hot.ee> wrote: > IMHO starting from C++17 the language was sabotaged through > standardization. It is overly complicated. Stroustrup and Sutter > try hard to collect advice how to use C++. They do it ... for years ... see > <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines> > Lot of it is good advice but they also seem to be stuck in C++14 like > me. No u8 literals, "launder" or "if constexpr" in it. So now it is > perhaps best idea to not even read standard but take it narrower > and read what Stroustrup thinks C++ is. I think you are painting too negative of a picture about the standardization process and new versions of the language. C++98 is complicated and rather quickly people discovered side-effects that could be used for interesting applications, but which were never originally designed for it. SFINAE would be the quintessential example. That small specification of the language, which was merely intended to make templates less likely to cause conflicts with each other, turned out to serendipitously allow for a limited form of compile-time introspection. But this... kludge, if you will, is quite complicated to understand, because the language was never designed with that in mind. Ask the average experienced C++ programmer to explain SFINAE, and he'll have no idea. Heck, ask the average experienced C++ programmer what std::enable_if is, and how it's used, and he'll have no idea. You might know it perfectly well, but let me assure you, the average C++ programmer doesn't. Not even the experienced one. And even if someone has some vague grasp of how it's used, ask him how and why it works, and chances are that he doesn't have a clue. It essentially works by magic. Likewise entire books were written about C++98 template metaprogramming. Something that was never originally designed for the language, but which arose serendipitously as a side-effect of how templates work. Yet, the average experienced C++ programmer, even to this day, has very limited knowledge and understanding of template metaprogramming. As, indeed, the "feature" is complicated and difficult to use, and results in very complicated-looking code. Thus, things like 'constexpr', 'consteval' and 'requires' were introduced to make all these much simpler and versatile. (For example C++98 template metaprogramming was extremely limited in what you could do, as it was limited to, essentially, basic integer arithmetic.) People love to complain about how such new features "make the language too complicated". They fail to see *why* these features were added: To actually make *using* the language simpler. To replace the ugly complicated hacks that were in common use in C++98 that were not only complicated to use, but also resulted in complicated source code that's hard to read and understand. People also love to complain that new features require programmers to have to learn more. Yet, the average C++ programmer doesn't even fully understand the entirety of C++98 either (see SFINAE, for example), yet they don't have much of a problem in writing C++ programs. It's not about knowing the entirety of the language. It's about having the tools to do what you need when you need them.
[toc] | [prev] | [next] | [standalone]
Page 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
Back to top | Article view | comp.lang.c++
csiph-web