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 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2021-06-18 08:20 -0400 |
| Subject | Re: Why does vector::reserve() not grow exponentially ? |
| Message-ID | <cone.1624018846.543352.125030.1004@monster.email-scan.com> |
| In reply to | #80494 |
[Multipart message — attachments visible in raw view] — view raw
MrSpook_6a2az@yxcggolr9p.com writes: > On Thu, 17 Jun 2021 18:22:38 -0700 (PDT) > =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: > >On Friday, 18 June 2021 at 03:19:18 UTC+3, Sam wrote: > >> =C3=96=C3=B6 Tiib writes:=20 > >>=20 > >> > On Thursday, 17 June 2021 at 08:35:26 UTC+3, Juha Nieminen wrote:=20 > >> > > =C3=96=C3=B6 Tiib <oot...@hot.ee> wrote:=20 > >> > > > and so I'm stuck in C++14.=20 > >> > > My condolences.=20 > >> >=20 > >> > No condolescences are mine ... to those who have to use C++17 and so th= > >eir=20 > >> > code is formally full of undefined behaviors. > >> C++17 isn't that bad. std::variant alone is worth the price of the admiss= > >ion. > > > >I just continue using boost::variant and boost::optional. I have used those > >more than ten years. Some of my code uses boost asio, other boost intrusive > >and I have some boost graph usage too so it does not matter much that=20 > >optional and variant are in std now. > > I won't let that bloatware anywhere near any of my projects. Boost can go > die in a corner for all I care. That was mostly my assessment of boost about 15 years ago. It's arcane, convoluted mess. Some bits of its eventually made it into the C++ standard. variant/optional are rare exceptions, they're quite useful. But the rest of it is crap, including boost's poster child: shared_ptr. What a completely worthless pile of junk. Whoever thought of that must've just had a bad acid trip. That's the only explanation for requiring an extra allocation for every object, and making shared_ptr actually be two separate pointers (or having to access the referenced object via two hops, at implementation's choice); and lacking any semblance of const-correctness. The separate allocation does make it possible to use it with any class, that's it's only benefit. But that doesn't come anywhere close to making up for its many shortcoming and design flaws.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-18 15:38 +0200 |
| Message-ID | <sai7jo$7d0$1@dont-email.me> |
| In reply to | #80495 |
On 18/06/2021 14:20, Sam wrote: > MrSpook_6a2az@yxcggolr9p.com writes: > >> On Thu, 17 Jun 2021 18:22:38 -0700 (PDT) >> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: >> >On Friday, 18 June 2021 at 03:19:18 UTC+3, Sam wrote: >> >> =C3=96=C3=B6 Tiib writes:=20 >> >>=20 >> >> > On Thursday, 17 June 2021 at 08:35:26 UTC+3, Juha Nieminen wrote:=20 >> >> > > =C3=96=C3=B6 Tiib <oot...@hot.ee> wrote:=20 >> >> > > > and so I'm stuck in C++14.=20 >> >> > > My condolences.=20 >> >> >=20 >> >> > No condolescences are mine ... to those who have to use C++17 and >> so th= >> >eir=20 >> >> > code is formally full of undefined behaviors. >> >> C++17 isn't that bad. std::variant alone is worth the price of the >> admiss= >> >ion. >> > >> >I just continue using boost::variant and boost::optional. I have used >> those >> >more than ten years. Some of my code uses boost asio, other boost >> intrusive >> >and I have some boost graph usage too so it does not matter much that=20 >> >optional and variant are in std now. >> >> I won't let that bloatware anywhere near any of my projects. Boost can go >> die in a corner for all I care. > > That was mostly my assessment of boost about 15 years ago. It's arcane, > convoluted mess. Some bits of its eventually made it into the C++ > standard. variant/optional are rare exceptions, they're quite useful. > But the rest of it is crap, including boost's poster child: shared_ptr. > What a completely worthless pile of junk. Whoever thought of that > must've just had a bad acid trip. That's the only explanation for > requiring an extra allocation for every object, and making shared_ptr > actually be two separate pointers (or having to access the referenced > object via two hops, at implementation's choice); and lacking any > semblance of const-correctness. The separate allocation does make it > possible to use it with any class, that's it's only benefit. But that > doesn't come anywhere close to making up for its many shortcoming and > design flaws. > Boost tries to make new classes, functions and other features that people would find useful in C++ programming. It is not uncommon that the implementation is more than a little ugly with complex macros, and is often less efficient than you might imagine. But the libraries are nonetheless useful to people. The C++ committee use these for inspiration and prototyping. The look at a class such as boost's variant and optional, and see that people like it. The wonder how it could be added to the standard library, how it could be better for the user, how it could be made safer or more efficient. The wonder what language features would be needed in the core of C++ in order to get there. This is a major influence on how the language progresses - it gets features that real users are finding useful in boost. Oh, and for shared_ptr, there is no option but to have a certain level of indirection - you need a control block in addition to the object itself. But often you can get a single allocation for both using std::make_shared, which results in more efficient allocation (and deallocation) as well as better cache locality.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2021-06-18 18:01 -0400 |
| Subject | Re: Why does vector::reserve() not grow exponentially ? |
| Message-ID | <cone.1624053680.368300.126471.1004@monster.email-scan.com> |
| In reply to | #80497 |
[Multipart message — attachments visible in raw view] — view raw
David Brown writes: > Oh, and for shared_ptr, there is no option but to have a certain level > of indirection - you need a control block in addition to the object > itself. But often you can get a single allocation for both using > std::make_shared, which results in more efficient allocation (and > deallocation) as well as better cache locality. Since the end result of make_shared must be a 100% compatible, stock shared_ptr you still end up having to carry two pointers on your back instead of one, for no good reason. It's true that there is no other option, given the current design of shared_ptr. I fall into the object super-root fan club. It's true that this means that you can't just arbitrary shared_ptr-ify any class, but most formally inherit from an object root class; and a few other minor drawbacks. But I think this is a better design, and offers a number of major advantages, like cost-free smart pointer const-correctness. This is how Java does objects, and C++ can benefit from learning a few things from Java (including non-broken exception-correctness that's enforced at compile time, but I digress). Furthermore, we already had iterator and const_iterator. Why do we need to have shared_ptr<const Object> instead of const_shared_ptr<Object>? Furthermore, shared_ptr implementation tend to really suck at supporting const-correctness. Passing a shared_ptr<Object> to a function that promises, by contract, to not modify the object, hence its parameter is shared_ptr<const Object> – this requires a construction of a temporary, and a bunch of utterly pointless reference counting. This is completely unnecessary. shared_ptr<Object> should inherit from shared_ptr<const Object>, so const_correctness comes at zero const, instead of this overhead. Furthermore, dereferencing a null shared_ptr<Object> is still undefined behavior. This is stupid. shared_ptr should throw an exception instead. You say that checking for a null pointer in operator* and operator-> is pointless overhead? I agree. Which is why you should have both shared_ref and shared_ptr, with shared_ref enforcing, by contract, a non-null pointer (no default constructor, etc…), so its operator* and operator-> is guaranteed not to dereference a null pointer and does not impose any overhead. It now becomes obvious that shared_ptr is constructible from shared_ref, and shared_ref is constructible from shared_ptr (with a null pointer check, that throws an exception). Now you can enforce, at compile-time, a non-null smart pointer. The current shared_ptr is a mess, and is beyond repair.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-19 12:32 +0200 |
| Message-ID | <sakh4f$cqs$1@dont-email.me> |
| In reply to | #80505 |
On 19/06/2021 00:01, Sam wrote: > David Brown writes: > >> Oh, and for shared_ptr, there is no option but to have a certain level >> of indirection - you need a control block in addition to the object >> itself. But often you can get a single allocation for both using >> std::make_shared, which results in more efficient allocation (and >> deallocation) as well as better cache locality. > > Since the end result of make_shared must be a 100% compatible, stock > shared_ptr you still end up having to carry two pointers on your back > instead of one, for no good reason. There /is/ a good reason - you just gave it! Ask yourself about the cost of having a second pointer here (assuming a modern 64-bit multi-core processor - the kind you are likely to be using when you have shared pointers). When the pointers are widely separate, it means two potential cache misses or other memory costs (lines in another core's cache, etc.). When they are tightly together - as they are after "make_shared" - they will probably be fetched together by cache and memory readahead. This means you only have /one/ big memory cost you might have to pay. Each cache miss can be several hundred times the cost of a pointer access when there is a cache hit. Having a second pointer will be an immeasurably small effect in real use of shared pointers, as long as it is tied closely to the real data. It is certainly possible to make intrusive shared pointer systems (where the shared pointer control data is attached directly to the object), but that means working with a new kind of object, not compatible with your original one. If you are doing something where maximal efficiency justifies the effort, you would want to create such a specialised structure. But for many cases, share_ptr gives you a simple, reliable and efficient way of sharing data. > > It's true that there is no other option, given the current design of > shared_ptr. I fall into the object super-root fan club. It's true that > this means that you can't just arbitrary shared_ptr-ify any class, but > most formally inherit from an object root class; and a few other minor > drawbacks. But I think this is a better design, and offers a number of > major advantages, like cost-free smart pointer const-correctness. This > is how Java does objects, and C++ can benefit from learning a few things > from Java (including non-broken exception-correctness that's enforced at > compile time, but I digress). There is no one right answer that is always for all cases. But there is a huge difference between saying "I think /this/ way would be better for how I want to write my code" and "It's a completely worthless pile of junk."
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2021-06-19 09:12 -0400 |
| Subject | Re: Why does vector::reserve() not grow exponentially ? |
| Message-ID | <cone.1624108348.19413.143792.1004@monster.email-scan.com> |
| In reply to | #80509 |
[Multipart message — attachments visible in raw view] — view raw
David Brown writes: > There /is/ a good reason - you just gave it! > > Ask yourself about the cost of having a second pointer here (assuming a > modern 64-bit multi-core processor - the kind you are likely to be using > when you have shared pointers). When the pointers are widely separate, > it means two potential cache misses or other memory costs (lines in > another core's cache, etc.). When they are tightly together - as they > are after "make_shared" - they will probably be fetched together by > cache and memory readahead. This means you only have /one/ big memory > cost you might have to pay. You can't eliminate the fact that any kind of movement requires twice as much data to shuffle around. If your shared_ptr is constructed and spends its entire lifetime in one place, then I'll buy that argument. But that's rarely the use case. Smart pointers get copied, moved around, passed all over the place. And now that imposes twice as much penalty, because you have to move or copy two pointers intead of one.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-19 15:24 +0200 |
| Message-ID | <sakr70$kqv$1@dont-email.me> |
| In reply to | #80512 |
On 19/06/2021 15:12, Sam wrote: > David Brown writes: > >> There /is/ a good reason - you just gave it! >> >> Ask yourself about the cost of having a second pointer here (assuming a >> modern 64-bit multi-core processor - the kind you are likely to be using >> when you have shared pointers). When the pointers are widely separate, >> it means two potential cache misses or other memory costs (lines in >> another core's cache, etc.). When they are tightly together - as they >> are after "make_shared" - they will probably be fetched together by >> cache and memory readahead. This means you only have /one/ big memory >> cost you might have to pay. > > You can't eliminate the fact that any kind of movement requires twice as > much data to shuffle around. > > If your shared_ptr is constructed and spends its entire lifetime in one > place, then I'll buy that argument. But that's rarely the use case. Construction via make_shared is the normal case, not the rare case. > Smart pointers get copied, moved around, passed all over the place. > > And now that imposes twice as much penalty, because you have to move or > copy two pointers intead of one. > Each bit of code or data that is sharing a shared pointer needs to keep track of a pointer to the shared pointer control structure. This control structure is /not/ moved around or copied - the whole thing only works because every user of the shared pointer accesses the same control structure. It is the control structure that holds reference counters, pointers to destructors, pointers to the object itself, etc. It is designed precisely so that the bit that gets passed around or copied is just a single pointer.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2021-06-19 17:33 -0400 |
| Subject | Re: Why does vector::reserve() not grow exponentially ? |
| Message-ID | <cone.1624138382.288278.9301.1004@monster.email-scan.com> |
| In reply to | #80513 |
[Multipart message — attachments visible in raw view] — view raw
David Brown writes: > On 19/06/2021 15:12, Sam wrote: > > > If your shared_ptr is constructed and spends its entire lifetime in one > > place, then I'll buy that argument. But that's rarely the use case. > > Construction via make_shared is the normal case, not the rare case. You still end up with a shared_ptr consisting of two pointers. > > Smart pointers get copied, moved around, passed all over the place. > > > > And now that imposes twice as much penalty, because you have to move or > > copy two pointers intead of one. > > > > Each bit of code or data that is sharing a shared pointer needs to keep > track of a pointer to the shared pointer control structure. This > control structure is /not/ moved around or copied - the whole thing only > works because every user of the shared pointer accesses the same control > structure. The shared_ptr itself gets moved around. This happens every time you pass the shared_ptr to a function by value or move it somewhere. Now you have two copy two pointers instead of one.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-20 09:45 +0200 |
| Message-ID | <samrmj$uob$1@dont-email.me> |
| In reply to | #80517 |
On 19/06/2021 23:33, Sam wrote: > David Brown writes: > >> On 19/06/2021 15:12, Sam wrote: >> >> > If your shared_ptr is constructed and spends its entire lifetime in one >> > place, then I'll buy that argument. But that's rarely the use case. >> >> Construction via make_shared is the normal case, not the rare case. > > You still end up with a shared_ptr consisting of two pointers. > >> > Smart pointers get copied, moved around, passed all over the place. >> > >> > And now that imposes twice as much penalty, because you have to move or >> > copy two pointers intead of one. >> > >> >> Each bit of code or data that is sharing a shared pointer needs to keep >> track of a pointer to the shared pointer control structure. This >> control structure is /not/ moved around or copied - the whole thing only >> works because every user of the shared pointer accesses the same control >> structure. > > The shared_ptr itself gets moved around. This happens every time you > pass the shared_ptr to a function by value or move it somewhere. Now you > have two copy two pointers instead of one. > Please look at <https://en.cppreference.com/w/cpp/memory/shared_ptr> and read the implementation notes. It explains things a lot better than I have done.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-06-19 03:33 -0700 |
| Message-ID | <5cd9853d-ded0-4548-a169-7b2449aa9922n@googlegroups.com> |
| In reply to | #80505 |
On Saturday, 19 June 2021 at 01:01:38 UTC+3, Sam wrote: > David Brown writes: > > > Oh, and for shared_ptr, there is no option but to have a certain level > > of indirection - you need a control block in addition to the object > > itself. But often you can get a single allocation for both using > > std::make_shared, which results in more efficient allocation (and > > deallocation) as well as better cache locality. > Since the end result of make_shared must be a 100% compatible, stock > shared_ptr you still end up having to carry two pointers on your back > instead of one, for no good reason. > > It's true that there is no other option, given the current design of > shared_ptr. I fall into the object super-root fan club. It's true that this > means that you can't just arbitrary shared_ptr-ify any class, but most > formally inherit from an object root class; and a few other minor drawbacks. > But I think this is a better design, and offers a number of major > advantages, like cost-free smart pointer const-correctness. This is how Java > does objects, and C++ can benefit from learning a few things from Java > (including non-broken exception-correctness that's enforced at compile time, > but I digress). > > Furthermore, we already had iterator and const_iterator. Why do we need to > have shared_ptr<const Object> instead of const_shared_ptr<Object>? > Furthermore, shared_ptr implementation tend to really suck at supporting > const-correctness. Passing a shared_ptr<Object> to a function that promises, > by contract, to not modify the object, hence its parameter is > shared_ptr<const Object> – this requires a construction of a temporary, and > a bunch of utterly pointless reference counting. This is completely > unnecessary. > > shared_ptr<Object> should inherit from shared_ptr<const Object>, so > const_correctness comes at zero const, instead of this overhead. > Furthermore, dereferencing a null shared_ptr<Object> is still undefined > behavior. > > This is stupid. shared_ptr should throw an exception instead. You say that > checking for a null pointer in operator* and operator-> is pointless > overhead? I agree. Which is why you should have both shared_ref and > shared_ptr, with shared_ref enforcing, by contract, a non-null pointer (no > default constructor, etc…), so its operator* and operator-> is guaranteed > not to dereference a null pointer and does not impose any overhead. It now > becomes obvious that shared_ptr is constructible from shared_ref, and > shared_ref is constructible from shared_ptr (with a null pointer check, that > throws an exception). > > Now you can enforce, at compile-time, a non-null smart pointer. > > The current shared_ptr is a mess, and is beyond repair. Good analysis. I would happily add weak_ptr and shared_from_this to the painful mess. On one hand user of it feels inconvenient like MacGyver using Swiss Army Knife for all works and on other hand it is really efficient for nothing in particular. But ... lets try to be constructive. ;-) What can be better?
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2021-06-19 09:38 -0400 |
| Subject | Re: Why does vector::reserve() not grow exponentially ? |
| Message-ID | <cone.1624109906.184768.143792.1004@monster.email-scan.com> |
| In reply to | #80510 |
[Multipart message — attachments visible in raw view] — view raw
Öö Tiib writes: > > Good analysis. I would happily add weak_ptr and shared_from_this to the > painful mess. On one hand user of it feels inconvenient like MacGyver Yes, I forgot shared_from_this. Which goes away when you have an object super-root. Weak pointers are complicated, but its possible to confine their penalty to the actual construction of a weak pointer, recovery of a strong pointer from a weak one, and the destruction of the object (when its reference count goes to 0). Otherwise they are a non-factor. > using Swiss Army Knife for all works and on other hand it is really > efficient for nothing in particular. But ... lets try to be constructive. ;-) > What can be better? Your own. Roll your own. That's what I did, and I mostly described what I did here: https://www.libcxx.org/refobj.html
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-06-19 12:50 -0700 |
| Message-ID | <754a8ecc-d1d3-4532-b726-082ffc882080n@googlegroups.com> |
| In reply to | #80514 |
On Saturday, 19 June 2021 at 16:38:44 UTC+3, Sam wrote: > Öö Tiib writes: > > > > > Good analysis. I would happily add weak_ptr and shared_from_this to the > > painful mess. On one hand user of it feels inconvenient like MacGyver > Yes, I forgot shared_from_this. Which goes away when you have an object > super-root. Weak pointers are complicated, but its possible to confine their > penalty to the actual construction of a weak pointer, recovery of a strong > pointer from a weak one, and the destruction of the object (when its > reference count goes to 0). Otherwise they are a non-factor. > > using Swiss Army Knife for all works and on other hand it is really > > efficient for nothing in particular. But ... lets try to be constructive. ;-) > > What can be better? > Your own. Roll your own. That's what I did, and I mostly described what I > did here: https://www.libcxx.org/refobj.html Hmm. It is trouble. I want intrusive ref counting and I want weak references. When I try then it always ends with something like what make_shared does, the only advantage being that I can keep those combined objects in array. Do you have reference to some published hint how to make it?
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2021-06-19 17:46 -0400 |
| Subject | Re: Why does vector::reserve() not grow exponentially ? |
| Message-ID | <cone.1624139186.309105.9301.1004@monster.email-scan.com> |
| In reply to | #80515 |
[Multipart message — attachments visible in raw view] — view raw
Öö Tiib writes: > On Saturday, 19 June 2021 at 16:38:44 UTC+3, Sam wrote: > > > Your own. Roll your own. That's what I did, and I mostly described what I > > did here: https://www.libcxx.org/refobj.html > > Hmm. It is trouble. I want intrusive ref counting and I want weak references. > When I try then it always ends with something like what make_shared does, > the only advantage being that I can keep those combined objects in array. > Do you have reference to some published hint how to make it? I don't have any white papers. The capsule summary is that the object super- root has an seconday, internal object attached to it the first time a weak pointer gets created. A weak pointer is effectively a regular strong reference-counting pointer to this object. Constructing another weak pointer just returns a reference to this object. So the weak pointer infrastructure itself is just reusing strong pointer infrastructure, to maintain itself. Then there's a big song-and-dance routine that happens whenever: 1) The reference count of the original object goes down to zero and the last remaining pointer wants to destroy it, and finds the weak metadata object that's attached to it. 2) When a weak pointer attempts to recover a reference to the strong object (the weak pointer's object maintains a raw pointer to the original object). The song-and-dance number involves some locking (the locking synchronizes the raw pointer), in order to work things out when there's a race condition with 1 and 2 happening at the same time (in different execution threads). The execution thread that ended up decrementing the original object's reference count to zero and sets its sight on destroying it will eventually reach one of two conclusions: A) Another execution thread recovered a strong reference to this object at the same time, so it's reference count is not zero any more. This execution thread quietly goes on on its own merry way without delete-ing the original object. B) "A" didn't happen, the object ends up getting delete-d as usual, nullifying its raw pointer from the weak medata object. The weak metadata object gets behind, any subsequent attempts to recover a strong reference from it will fail. And since the weak metadata object is itself a reference- counted object (strongly referenced by the individual weak pointers) when all those go away, the weak metadata object gets destroyed. And everyone lives happily ever after. Weak pointers only introduce a little bit of extra overhead when destroying an object with weak pointers, when they exist, and otherwise carry minimal costs.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-06-20 05:19 -0700 |
| Message-ID | <224be210-e476-44c8-89d0-76d39698d6edn@googlegroups.com> |
| In reply to | #80518 |
On Sunday, 20 June 2021 at 00:46:43 UTC+3, Sam wrote: > Öö Tiib writes: > > > On Saturday, 19 June 2021 at 16:38:44 UTC+3, Sam wrote: > > > > > Your own. Roll your own. That's what I did, and I mostly described what I > > > did here: https://www.libcxx.org/refobj.html > > > > Hmm. It is trouble. I want intrusive ref counting and I want weak references. > > When I try then it always ends with something like what make_shared does, > > the only advantage being that I can keep those combined objects in array. > > Do you have reference to some published hint how to make it? > I don't have any white papers. The capsule summary is that the object super- > root has an seconday, internal object attached to it the first time a weak > pointer gets created. A weak pointer is effectively a regular strong > reference-counting pointer to this object. Constructing another weak pointer > just returns a reference to this object. So the weak pointer infrastructure > itself is just reusing strong pointer infrastructure, to maintain itself. > > Then there's a big song-and-dance routine that happens whenever: > > 1) The reference count of the original object goes down to zero and the last > remaining pointer wants to destroy it, and finds the weak metadata object > that's attached to it. > > 2) When a weak pointer attempts to recover a reference to the strong object > (the weak pointer's object maintains a raw pointer to the original object). > > The song-and-dance number involves some locking (the locking synchronizes > the raw pointer), in order to work things out when there's a race condition > with 1 and 2 happening at the same time (in different execution threads). > > The execution thread that ended up decrementing the original object's > reference count to zero and sets its sight on destroying it will eventually > reach one of two conclusions: > > A) Another execution thread recovered a strong reference to this object at > the same time, so it's reference count is not zero any more. This execution > thread quietly goes on on its own merry way without delete-ing the original > object. > > B) "A" didn't happen, the object ends up getting delete-d as usual, > nullifying its raw pointer from the weak medata object. The weak metadata > object gets behind, any subsequent attempts to recover a strong reference > from it will fail. And since the weak metadata object is itself a reference- > counted object (strongly referenced by the individual weak pointers) when > all those go away, the weak metadata object gets destroyed. > > And everyone lives happily ever after. Weak pointers only introduce a little > bit of extra overhead when destroying an object with weak pointers, when > they exist, and otherwise carry minimal costs. Hmm ... very interesting. I use std::atomic load of strong count and then loop until count is zero or compare_exchange_(strong/weak) succeeds to increment it by one where you use locks. That can no way increment strong count when it is zero, but weak can fail on case the events 1) and 2) coincide. If compare_exchange_weak or compare_exchange_strong is better (or it does not matter) depends on platform.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-06-19 23:27 +0300 |
| Message-ID | <saljvp$uqq$1@dont-email.me> |
| In reply to | #80514 |
19.06.2021 16:38 Sam kirjutas: > Öö Tiib writes: > >> >> Good analysis. I would happily add weak_ptr and shared_from_this to the >> painful mess. On one hand user of it feels inconvenient like MacGyver > > Yes, I forgot shared_from_this. Which goes away when you have an object > super-root. shared_from_this is tricky because it can be easily invoked during the destruction or construction, but the result cannot be correct (as the most derived object does not exist). In C++11 they made it UB unfortunately, but in C++17 they came to their senses and are throwing an exception instead. Alas, this means yet some overhead.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2021-06-19 17:50 -0400 |
| Subject | Re: Why does vector::reserve() not grow exponentially ? |
| Message-ID | <cone.1624139416.102450.9301.1004@monster.email-scan.com> |
| In reply to | #80516 |
[Multipart message — attachments visible in raw view] — view raw
Paavo Helde writes: > 19.06.2021 16:38 Sam kirjutas: >> Öö Tiib writes: >> >>> >>> Good analysis. I would happily add weak_ptr and shared_from_this to the >>> painful mess. On one hand user of it feels inconvenient like MacGyver >> >> Yes, I forgot shared_from_this. Which goes away when you have an object >> super-root. > > shared_from_this is tricky because it can be easily invoked during the > destruction or construction, but the result cannot be correct (as the most > derived object does not exist). In C++11 they made it UB unfortunately, but > in C++17 they came to their senses and are throwing an exception instead. > Alas, this means yet some overhead. Yup. I worked out that issue independently in my implementaiton. I chose a compromise between UB and a thrown exception, and decided to abort() in this situation. Throwing an exception is too fugly, and, besides, I'm pretty sure that destructors are noexcept by default, these days. So, throwing an exception a destructor, at least, produces the same outcome.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-06-19 16:44 -0700 |
| Message-ID | <salvhe$1sk6$1@gioia.aioe.org> |
| In reply to | #80514 |
On 6/19/2021 6:38 AM, Sam wrote:
> Öö Tiib writes:
>
>>
>> Good analysis. I would happily add weak_ptr and shared_from_this to the
>> painful mess. On one hand user of it feels inconvenient like MacGyver
>
> Yes, I forgot shared_from_this. Which goes away when you have an object
> super-root. Weak pointers are complicated, but its possible to confine
> their penalty to the actual construction of a weak pointer, recovery of
> a strong pointer from a weak one, and the destruction of the object
> (when its reference count goes to 0). Otherwise they are a non-factor.
>
>> using Swiss Army Knife for all works and on other hand it is really
>> efficient for nothing in particular. But ... lets try to be
>> constructive. ;-)
>> What can be better?
>
> Your own. Roll your own. That's what I did, and I mostly described what
> I did here: https://www.libcxx.org/refobj.html
>
>
>
Iirc, I have some really old code on an external hd around here
somewhere that split apart access into two areas. It had a global_ptr
and a local_ptr. local_ptr had no atomic's, no membars, ect. It was
meant to be used locally. The global_ptr was strongly thread-safe and
lock-free. So, a thread could do something like:
static global_ptr<foo> g_foo = new foo();
void threads()
{
local_ptr<foo> l_foo = g_foo;
if (! l_foo) return;
l_foo->foobar();
local_ptr<foo> l2_foo = l_foo;
l_foo = nullptr;
l2_foo->barbaz();
func(l2_foo);
}
void rouge_threads()
{
local_ptr<foo> l_foo = g_foo.exchange(new foo());
if (! l_foo) return;
l_foo->bingo();
}
All of the accesses to l_foo and l2_foo did not use any atomics,
membars, ect. Afaict, back in the day, one of the best smart pointers
out there was atomic_ptr developed by Joe Seigh:
http://atomic-ptr-plus.sourceforge.net
He posted full code for atomic_ptr somewhere over on
comp.programming.threads. I have implemented it multiple times for fun.
Works like a charm. However, it required DWCAS.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-06-18 17:46 +0300 |
| Message-ID | <saibko$74o$1@dont-email.me> |
| In reply to | #80495 |
18.06.2021 15:20 Sam kirjutas: > MrSpook_6a2az@yxcggolr9p.com writes: >> I won't let that bloatware anywhere near any of my projects. Boost can go >> die in a corner for all I care. > > That was mostly my assessment of boost about 15 years ago. It's arcane, > convoluted mess. Some bits of its eventually made it into the C++ > standard. variant/optional are rare exceptions, they're quite useful. > But the rest of it is crap, including boost's poster child: shared_ptr. > What a completely worthless pile of junk. Whoever thought of that > must've just had a bad acid trip. That's the only explanation for > requiring an extra allocation for every object, and making shared_ptr > actually be two separate pointers (or having to access the referenced > object via two hops, at implementation's choice); and lacking any > semblance of const-correctness. The separate allocation does make it > possible to use it with any class, that's it's only benefit. But that > doesn't come anywhere close to making up for its many shortcoming and > design flaws. Ever heard of std::make_shared() and std::allocate_shared()? This answers most of your objections (alas, in expense of having undecipherable error messages if anything is amiss).
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2021-06-18 17:41 -0400 |
| Subject | Re: Why does vector::reserve() not grow exponentially ? |
| Message-ID | <cone.1624052478.543142.126471.1004@monster.email-scan.com> |
| In reply to | #80498 |
[Multipart message — attachments visible in raw view] — view raw
Paavo Helde writes: > 18.06.2021 15:20 Sam kirjutas: >> MrSpook_6a2az@yxcggolr9p.com writes: >>> I won't let that bloatware anywhere near any of my projects. Boost can go >>> die in a corner for all I care. >> >> That was mostly my assessment of boost about 15 years ago. It's arcane, >> convoluted mess. Some bits of its eventually made it into the C++ standard. >> variant/optional are rare exceptions, they're quite useful. But the rest of >> it is crap, including boost's poster child: shared_ptr. What a completely >> worthless pile of junk. Whoever thought of that must've just had a bad acid >> trip. That's the only explanation for requiring an extra allocation for >> every object, and making shared_ptr actually be two separate pointers (or >> having to access the referenced object via two hops, at implementation's >> choice); and lacking any semblance of const-correctness. The separate >> allocation does make it possible to use it with any class, that's it's only >> benefit. But that doesn't come anywhere close to making up for its many >> shortcoming and design flaws. > > Ever heard of std::make_shared() and std::allocate_shared()? This answers > most of your objections (alas, in expense of having undecipherable error > messages if anything is amiss). Ummm… std::make_shared leaves most of shared_ptr's problems untouched. You still get the same fugly shared_ptr implementation, with two pointers instead of one. std::allocate_shared addresses some edge cases that are quite rare, but the end result is still a fugly shared_ptr. The problems with shared_ptr are fundamental, and are beyond the reach of fancy constructors and factories.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-06-19 11:21 +0300 |
| Message-ID | <sak9f6$cl5$1@dont-email.me> |
| In reply to | #80504 |
19.06.2021 00:41 Sam kirjutas: > > Ummm… std::make_shared leaves most of shared_ptr's problems untouched. > You still get the same fugly shared_ptr implementation, with two > pointers instead of one. std::allocate_shared addresses some edge cases > that are quite rare, but the end result is still a fugly shared_ptr. The > problems with shared_ptr are fundamental, and are beyond the reach of > fancy constructors and factories. I believe shared_ptr is fine for what it was meant - a generally usable thread-safe smart pointer suitable for general use. It's true that for more specialized use cases one still needs to use custom solutions. That's the same as for iostreams, or for strtod() for that matter. For me, the biggest drawback of std::shared_ptr is that it is multithread-safe. This means that it has to contain some thread synchronization, however lightweight it is. With modern hardware, I can have tens of threads running in full speed in parallel, if they each attempt to synchronize with each other, thousands of times per second, this is bound to have an impact. Compared with the expense of that, the amount of pointers (1 or 2), even the number of dynamic allocations (1 or 2) pale in comparison (the dynamic allocations happen much more rarely then refcount updates). So in our codebase there is a custom non-synchronized smart-pointer used for all the "data" classes (as opposed to "entity" classes). And you were right, it is based on intrusive refcounting in a super root class, just because all of the code is under our control anyway. As it it not thread-safe, it requires extra care needs to be taken that no such pointer is ever accessed from multiple threads at the same time. For passing data to another thread deep copies are needed, etc. The committee voted against of having a non-synchronized smartpointer class in the standard, in the fear this could easily cause subtle bugs which are hard to debug. And guess what? They were right! Over the years I have needed to fix several such bugs in my own code. I remember times when the bug just refused to express itself on my 4-core machine and I needed to find another 8-core machine and run the program for hours, to just trigger it. So if I would sit on the committee, I would also vote against having such thing in the standard. C++ is already hard to use and full of gotchas even without it. And to be honest, considering it now should be classified as a slowish "safe easily usable class", there is really nothing wrong in adding an extra pointer or an extra allocation for making it even more easily usable. TLDR; I agree with your criticism against std::shared_ptr, but on the other hand I believe its current design was and is the best one to standardize.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2021-06-19 09:08 -0400 |
| Subject | Re: Why does vector::reserve() not grow exponentially ? |
| Message-ID | <cone.1624108118.804038.143792.1004@monster.email-scan.com> |
| In reply to | #80507 |
[Multipart message — attachments visible in raw view] — view raw
Paavo Helde writes: > For me, the biggest drawback of std::shared_ptr is that it is multithread- > safe. This means that it has to contain some thread synchronization, however The thread synchronization should be nothing beyond keeping the reference counter as a std::atomic object. Nothing more should be needed, for 99% of the use cases. Some kind of locking is needed to support weak references, that's the only situation where actual locking is needed. But, for garden-variety smart pointers, an atomic counter is all that's needed whose overhead is quite negligible. > Compared with the expense of that, the amount of pointers (1 or 2), even the > number of dynamic allocations (1 or 2) pale in comparison (the dynamic > allocations happen much more rarely then refcount updates). Well the amount of pointers becomes a factor here not merely because of the smart pointer itself, but because of shared_ptr dumb design, of using two pointers instead of one. > So in our codebase there is a custom non-synchronized smart-pointer used for > all the "data" classes (as opposed to "entity" classes). And you were right, > it is based on intrusive refcounting in a super root class, just because all > of the code is under our control anyway. And if you make it atomic, you'll get thread safety. If you actually go ahead and try to measure the additional overhead, I'd be surprised if you'd be able to actually measure anything.
[toc] | [prev] | [next] | [standalone]
Page 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
Back to top | Article view | comp.lang.c++
csiph-web