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 6 of 13 — ← Prev page 1 … 4 5 [6] 7 8 … 13 Next page →
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2021-06-17 13:45 -0700 |
| Message-ID | <eaa38bc1-4bfd-4452-8822-249c27997a06n@googlegroups.com> |
| In reply to | #80427 |
On Wednesday, June 16, 2021 at 4:35:59 AM UTC-4, David Brown wrote: > > As soon as ... reflection and metaclasses make it to the > language, I'll be using them too. > "As soon as" probably means C++ 2026. And in the meantime, while other languages such as rust see the emergence of a rich library ecosystem, C++ remains comparatively impoverished because of the absence of standard types - no int128, no uint128, no float128, no big_decimal, no big_int, no unicode encoding validators or converters ... And consequently, no comprehensive CBOR or BSON or SQL libraries that map to standard types, no JSON or XML libraries that don't reimplement unicode encoding validation and conversion ... Daniel
[toc] | [prev] | [next] | [standalone]
| From | Real Troll <real.troll@trolls.com> |
|---|---|
| Date | 2021-06-17 21:15 +0000 |
| Message-ID | <sageff$16vo$1@gioia.aioe.org> |
| In reply to | #80485 |
On 17/06/2021 21:45, daniel...@gmail.com wrote: > "As soon as" probably means C++ 2026. > > C++ remains comparatively > impoverished because of the absence of standard types In fact C++ remains impoverished because of its bureaucratic process of approving anything to be part of the standard!. When C# had such a body, nothing was achieved and so Microsoft decided to go it alone and now it has become one of the best programming languages. It has a standard called ECMA-334 <https://www.ecma-international.org/publications-and-standards/standards/ecma-334/> but It is not as bureaucratic as ISO or some other standard bodies. I think even Suter and Bjarne Stroustrup have given up on the body currently in-charge of the C++ Standards. Its become a laughing stock of dedicated programmers around the world who have started writing their own standards based on what C++ does but also what other languages are doing.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-06-18 15:23 +0200 |
| Message-ID | <sai6nt$1s14$1@gioia.aioe.org> |
| In reply to | #80486 |
On 6/17/2021 11:15 PM, Real Troll wrote: > On 17/06/2021 21:45, daniel...@gmail.com wrote: >> "As soon as" probably means C++ 2026. >> >> C++ remains comparatively >> impoverished because of the absence of standard types > > In fact C++ remains impoverished because of its bureaucratic process of approving anything to be part of the standard!. Bureaucracy is a problem yes, but lack of consensus and incoherence is the real problem of the committee, IMO. In fact, in my opinion, they have approved too many questionable features, and created too much of a problem with consensus on the really important ones - the history of "concepts" is paradigmatic in that sense. The quality of the result is IMO less than optimal for this exact reason. > > When C# had such a body, nothing was achieved and so Microsoft decided to go it alone and now it has become one of the best programming languages. It has a standard called ECMA-334 As far as I understand C# is a Microsoft product, and its standardization was promoted by Microsoft in what seems to me a mere PR operation. > <https://www.ecma-international.org/publications-and-standards/standards/ecma-334/> but It is not as bureaucratic as ISO or some other standard bodies. I think even Suter and Bjarne Stroustrup have given up on the body currently in-charge of the C++ Standards. Its become a laughing stock of dedicated programmers around the world who have started writing their own standards based on what C++ does but also what other languages are doing. > I don't know about Sutter (whom I am not completely pleased with his results in the language), but I have got the same impression that Stroustrup is backing off after one of his latest interviews.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-18 08:56 +0200 |
| Message-ID | <sahg2j$8u7$1@dont-email.me> |
| In reply to | #80485 |
On 17/06/2021 22:45, daniel...@gmail.com wrote: > On Wednesday, June 16, 2021 at 4:35:59 AM UTC-4, David Brown wrote: >> >> As soon as ... reflection and metaclasses make it to the >> language, I'll be using them too. >> > "As soon as" probably means C++ 2026. > > And in the meantime, while other languages such as rust see the > emergence of a rich library ecosystem, C++ remains comparatively > impoverished because of the absence of standard types - no > int128, no uint128, no float128, no big_decimal, no big_int, > no unicode encoding validators or converters ... And consequently, > no comprehensive CBOR or BSON or SQL libraries that map to standard > types, no JSON or XML libraries that don't reimplement unicode > encoding validation and conversion ... > > Daniel > That all depends on your needs. At the moment, I for one have no need for anything like that in C++. When I want JSON stuff, or SQL, I use Python - it is much better for such high level things. Much of this could change once reflection and metaclasses are in place in C++. Currently, it is impossible (AFAIK) to make a "to_json" function that could take a wide variety of types and structures and generate a JSON object - you need to provide a schema of some kind for it. Metaclasses would let you do that automatically. Similarly, they could let you write a single description of the columns of a database table, and use that for queries as well as generating classes and functions to handle them. This is the kind of language feature that causes people to choose Python or PHP for such tasks. There would also probably be much to be gained by an "official" repository of C++ libraries, to provide some of the things that languages like Python can provide in their standard library, but which definitely should not be in the main C++ standard library.
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2021-06-18 08:06 -0700 |
| Message-ID | <2a51c063-a26a-445d-a75d-c41bf365de81n@googlegroups.com> |
| In reply to | #80490 |
On Friday, June 18, 2021 at 2:56:34 AM UTC-4, David Brown wrote: > On 17/06/2021 22:45, daniel...@gmail.com wrote: > >> > > And in the meantime, while other languages such as rust see the > > emergence of a rich library ecosystem, C++ remains comparatively > > impoverished because of the absence of standard types - no > > int128, no uint128, no float128, no big_decimal, no big_int, > > no unicode encoding validators or converters ... And consequently, > > no comprehensive CBOR or BSON or SQL libraries that map to standard > > types, no JSON or XML libraries that don't reimplement unicode > > encoding validation and conversion ... > > > That all depends on your needs. At the moment, I for one have no need > for anything like that in C++. It's not about your needs, it's about how the absence of fundamental types in the C++ standard library impedes the emergence of libraries. Writing a C++ library to process standard or de facto standard data formats such as JSON, XML, CBOR, BSON, SQL is much more work and the results are far less satisfactory than in other languages that have support for fundamental types such as int128, uint128, float128, big_int, big_decimal, bytes to some unicode encoding, some unicode encoding to bytes, validation of unicode encoding, etc. And almost all other modern languages have these things. It is not only a burden for library writers, it is also a burden for library users, who have to convert whatever the library uses for int128, uint128, float128, big_int, big_decimal etc. into what they use. > > Much of this could change once reflection and metaclasses are in place > in C++. Currently, it is impossible (AFAIK) to make a "to_json" > function that could take a wide variety of types and structures and > generate a JSON object - you need to provide a schema of some kind for > it. Hardly impossible, rather, it's quite common. Modern C++ JSON/CBOR/BSON etc. libraries tend to fall into two groups, ones that are focused primarily on performance (processing gigabytes of JSON per second), notably simdjson, and ones that support something like MyType val = from_json<MyType>(JSON input); to_json(val, JSON output); The latter group supports conversion between JSON text and user defined (not generated) types through user extensible traits. > Metaclasses would let you do that automatically. Similarly, they > could let you write a single description of the columns of a database > table, and use that for queries as well as generating classes and > functions to handle them. Yes, I follow the SG-7 compile-time reflection committee mailing list, am familiar with the The Syntax of Static Reflection proposal ( P2320R0), and have experimented with the clang compiler fork that implements the proposal. You may see it in C++ 2026. New libraries may start emerging a couple of years later that take advantage of this support. P2320R0 doesn't entirely address the issue of UDT/serialized format conversion, though. C++ will still need a way to tag information to a C++ entity, such as serialized names where these differ from member data names. Most languages that support reflection allow this through attributes. C++ currently only supports built-in attributes. Maybe we'll have something in C++ 2029? And metaclasses don't address this issue: a deficiency of fundamental standard types to map things to that most other languages have. > > There would also probably be much to be gained by an "official" > repository of C++ libraries, to provide some of the things that > languages like Python can provide in their standard library, but which > definitely should not be in the main C++ standard library. What things? Are you suggesting that int128, uint128, float128, big_decimal, big_int, and unicode encoding validators or converters should "definitely not be in the main C++ standard library"? Daniel
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-18 17:41 +0200 |
| Message-ID | <saierh$ucm$1@dont-email.me> |
| In reply to | #80499 |
On 18/06/2021 17:06, daniel...@gmail.com wrote:
> On Friday, June 18, 2021 at 2:56:34 AM UTC-4, David Brown wrote:
>> On 17/06/2021 22:45, daniel...@gmail.com wrote:
>>>>
>>> And in the meantime, while other languages such as rust see the
>>> emergence of a rich library ecosystem, C++ remains comparatively
>>> impoverished because of the absence of standard types - no
>>> int128, no uint128, no float128, no big_decimal, no big_int,
>>> no unicode encoding validators or converters ... And consequently,
>>> no comprehensive CBOR or BSON or SQL libraries that map to standard
>>> types, no JSON or XML libraries that don't reimplement unicode
>>> encoding validation and conversion ...
>>>
>> That all depends on your needs. At the moment, I for one have no need
>> for anything like that in C++.
>
> It's not about your needs, it's about how the absence of fundamental types
> in the C++ standard library impedes the emergence of libraries. Writing a
> C++ library to process standard or de facto standard data formats
> such as JSON, XML, CBOR, BSON, SQL is much more work and the results are
> far less satisfactory than in other languages that have support for
> fundamental types such as int128, uint128, float128, big_int, big_decimal,
> bytes to some unicode encoding, some unicode encoding to bytes,
> validation of unicode encoding, etc.
I haven't tried to implement such libraries in C++. But it is not those
types that are the sticking points. These can be made as classes if you
like. (Built-in types might be neater or more efficient, of course.)
To make a good JSON (or whatever) library, you want to be able to write:
struct data {
int x;
string s;
};
data d;
auto j = to_json(d);
and have the result {"x" : 123, "s" : "Hello, world!"}.
The key missing feature is a way for "to_json" to access the structure
details.
Languages which make JSON, etc., simple have the introspection needed.
(Many are dynamic languages, which helps here too.)
> And almost all other modern languages
> have these things. It is not only a burden for library writers, it is also a burden
> for library users, who have to convert whatever the library uses for int128,
> uint128, float128, big_int, big_decimal etc. into what they use.
>>
>> Much of this could change once reflection and metaclasses are in place
>> in C++. Currently, it is impossible (AFAIK) to make a "to_json"
>> function that could take a wide variety of types and structures and
>> generate a JSON object - you need to provide a schema of some kind for
>> it.
>
> Hardly impossible, rather, it's quite common. Modern C++ JSON/CBOR/BSON
> etc. libraries tend to fall into two groups, ones that are focused primarily on
> performance (processing gigabytes of JSON per second), notably simdjson,
> and ones that support something like
>
> MyType val = from_json<MyType>(JSON input);
> to_json(val, JSON output);
>
> The latter group supports conversion between JSON text and user defined
> (not generated) types through user extensible traits.
>
>> Metaclasses would let you do that automatically. Similarly, they
>> could let you write a single description of the columns of a database
>> table, and use that for queries as well as generating classes and
>> functions to handle them.
>
> Yes, I follow the SG-7 compile-time reflection committee mailing list, am
> familiar with the The Syntax of Static Reflection proposal ( P2320R0), and have
> experimented with the clang compiler fork that implements the proposal.
> You may see it in C++ 2026. New libraries may start emerging a couple of years
> later that take advantage of this support.
>
> P2320R0 doesn't entirely address the issue of UDT/serialized format conversion,
> though. C++ will still need a way to tag information to a C++ entity, such as
> serialized names where these differ from member data names. Most languages
> that support reflection allow this through attributes. C++ currently only
> supports built-in attributes. Maybe we'll have something in C++ 2029?
>
> And metaclasses don't address this issue: a deficiency of fundamental
> standard types to map things to that most other languages have.
>
I don't disagree that additional standard types here could be useful - I
just don't think those are the sticking points.
>>
>> There would also probably be much to be gained by an "official"
>> repository of C++ libraries, to provide some of the things that
>> languages like Python can provide in their standard library, but which
>> definitely should not be in the main C++ standard library.
>
> What things? Are you suggesting that int128, uint128, float128, big_decimal,
> big_int, and unicode encoding validators or converters should "definitely
> not be in the main C++ standard library"?
>
I certainly don't want them in the libraries /I/ use on small embedded
systems - there should perhaps be a clearer distinction of what parts of
the standard library are required for different types of targets rather
than the all-or-nothing permission of freestanding vs. hosted.
But no, I am thinking of the kinds of convenient libraries that are
common in the standard libraries for Python, PHP, and the like - https
support, SMTP, jpeg, zip, etc. If I want to write a Python program to
send a zip of some files by email, it is short and simple. Doing it in
C++ would be a major effort. However, such libraries don't belong in
C++ standard library (IMHO) - but an official repository of common
libraries would be useful. (Other modern languages have them.)
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2021-06-18 14:31 -0700 |
| Message-ID | <f6f823d2-9a02-4077-8642-449f4985b7e3n@googlegroups.com> |
| In reply to | #80500 |
On Friday, June 18, 2021 at 11:42:11 AM UTC-4, David Brown wrote:
> To make a good JSON (or whatever) library, you want to be able to write:
>
> struct data {
> int x;
> string s;
> };
>
> data d;
>
> auto j = to_json(d);
>
> and have the result {"x" : 123, "s" : "Hello, world!"}.
>
> The key missing feature is a way for "to_json" to access the structure
> details.
Most "modern" JSON libraries - e.g. nlohmann, jsoncons, Spotify JSON,
taojson, ThorsSerializer - support that through user defined traits
that describe what to do with types that the library doesn't know about.
Several of the above include convenience macros for generating the
traits, e.g. jsoncons suppports
JSONCONS_ALL_MEMBER_TRAITS(data, x, s)
data d{123, "Hello, world!"};
std::string s;
encode_json(d, s);
Result: {"s":"Hello,world!","x":123}
P2320R0 will allow libraries to implement that simple case without any
need for the user to declare traits. Compile time reflection and metaclasses,
however, won't be enough if e.g. member variable names and desired JSON names
differ, and the desired output is {"String" : "Hello, world!", "X" : 123}.
Other languages support that with attributes, e.g. a C# example
public class Videogame
{
[JsonProperty("name")]
public string Name { get; set; }
[JsonProperty("release_date")]
public DateTime ReleaseDate { get; set; }
}
But C++ currently only supports built in attributes. So until we have
user defined attributes, which is being talked about but looks to be a
long ways away, we'll still need traits to tag information to a C++
class for all but the simplest problems.
>
> Languages which make JSON, etc., simple have the introspection needed.
> (Many are dynamic languages, which helps here too.)
Not all, rust serde uses traits rather than reflection to support encode/decode.
> >
> I don't disagree that additional standard types here could be useful - I
> just don't think those are the sticking points.
>
It's factual that the availability of C++ github libraries that support standardized
data formats such as JSON, CBOR, BSON etc is way behind that of other languages.
It's noted that rust serde, which is far more capable than any comparable
library in C++, relies on traits rather than reflection for encode/decode,
but rust does supply all the basic fundamental types, and unicode validation
and conversion functions. rust also has user defined attributes and a better
macro language, which helps. But the most basic thing is to have types to map
into, types that are agreeable to both the library author and library user,
standard types.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-06-19 02:53 -0700 |
| Message-ID | <908841d3-2aff-4efd-9641-aed547f5dd01n@googlegroups.com> |
| In reply to | #80503 |
On Saturday, 19 June 2021 at 00:32:07 UTC+3, daniel...@gmail.com wrote: > On Friday, June 18, 2021 at 11:42:11 AM UTC-4, David Brown wrote: > > > > > Languages which make JSON, etc., simple have the introspection needed. > > (Many are dynamic languages, which helps here too.) > Not all, rust serde uses traits rather than reflection to support encode/decode. > > > > > I don't disagree that additional standard types here could be useful - I > > just don't think those are the sticking points. > > > It's factual that the availability of C++ github libraries that support standardized > data formats such as JSON, CBOR, BSON etc is way behind that of other languages. > It's noted that rust serde, which is far more capable than any comparable > library in C++, relies on traits rather than reflection for encode/decode, > but rust does supply all the basic fundamental types, and unicode validation > and conversion functions. rust also has user defined attributes and a better > macro language, which helps. But the most basic thing is to have types to map > into, types that are agreeable to both the library author and library user, > standard types. I've lately found that Flatbuffers is great. Other JSONs are bad in schema validation. All CBORs, BSONs and ASN.1s are slower as binary or unwieldy in embedded. Flatbuffers parses and generates json passably, generates code, has nice schema, has some support to RPC, is documented and tooled close to perfectly. I don't think that other languages have better support to something like Flatbuffers so I don't see how we are losing. The translation layer between C++ classes (like std::unordered_map, boost::intrusive::set or boost::base_collection) and those flat buffers is orthogonal to communication level. I *want* it to be separate and loosely coupled.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-06-19 11:10 +1200 |
| Message-ID | <ij4nenFmi1lU1@mid.individual.net> |
| In reply to | #80500 |
On 19/06/2021 03:41, David Brown wrote:
> On 18/06/2021 17:06, daniel...@gmail.com wrote:
>> On Friday, June 18, 2021 at 2:56:34 AM UTC-4, David Brown wrote:
>>> On 17/06/2021 22:45, daniel...@gmail.com wrote:
>>>>>
>>>> And in the meantime, while other languages such as rust see the
>>>> emergence of a rich library ecosystem, C++ remains comparatively
>>>> impoverished because of the absence of standard types - no
>>>> int128, no uint128, no float128, no big_decimal, no big_int,
>>>> no unicode encoding validators or converters ... And consequently,
>>>> no comprehensive CBOR or BSON or SQL libraries that map to standard
>>>> types, no JSON or XML libraries that don't reimplement unicode
>>>> encoding validation and conversion ...
>>>>
>>> That all depends on your needs. At the moment, I for one have no need
>>> for anything like that in C++.
>>
>> It's not about your needs, it's about how the absence of fundamental types
>> in the C++ standard library impedes the emergence of libraries. Writing a
>> C++ library to process standard or de facto standard data formats
>> such as JSON, XML, CBOR, BSON, SQL is much more work and the results are
>> far less satisfactory than in other languages that have support for
>> fundamental types such as int128, uint128, float128, big_int, big_decimal,
>> bytes to some unicode encoding, some unicode encoding to bytes,
>> validation of unicode encoding, etc.
>
> I haven't tried to implement such libraries in C++. But it is not those
> types that are the sticking points. These can be made as classes if you
> like. (Built-in types might be neater or more efficient, of course.)
>
> To make a good JSON (or whatever) library, you want to be able to write:
>
> struct data {
> int x;
> string s;
> };
>
> data d;
>
> auto j = to_json(d);
>
> and have the result {"x" : 123, "s" : "Hello, world!"}.
>
> The key missing feature is a way for "to_json" to access the structure
> details.
The same argument can be applied to all forms of serialisation, not just
common data formats.
There is more to working with the likes of JSON that native object
serialisation, much of my code works with the JSON object directly
without any corresponding native objects.
What C++ dues allow, which other languages don't, is code like (from my
JSON library unit tests):
object["one"]["two"]["three"]["four"] = 42;
CPPUNIT_ASSERT_EQUAL( 42, object["one"]["two"]["three"]["four"] );
and
object["attributes"][0]["member"] = "child";
CPPUNIT_ASSERT_EQUAL( "child", object["attributes"][0]["member"] );
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_gavL@es9w71p.tv |
|---|---|
| Date | 2021-06-18 15:53 +0000 |
| Message-ID | <saifgu$4j2$1@gioia.aioe.org> |
| In reply to | #80499 |
On Fri, 18 Jun 2021 08:06:55 -0700 (PDT) "daniel...@gmail.com" <danielaparker@gmail.com> wrote: >On Friday, June 18, 2021 at 2:56:34 AM UTC-4, David Brown wrote: >> That all depends on your needs. At the moment, I for one have no need >> for anything like that in C++. > >It's not about your needs, it's about how the absence of fundamental types >in the C++ standard library impedes the emergence of libraries. Writing a >C++ library to process standard or de facto standard data formats >such as JSON, XML, CBOR, BSON, SQL is much more work and the results are Why? What do you think typedefs (or the silly using syntax) are for? >far less satisfactory than in other languages that have support for >fundamental types such as int128, uint128, float128, big_int, big_decimal, At least C++ has unsigned types which is more than java managed for 2 decades. >though. C++ will still need a way to tag information to a C++ entity, such as >serialized names where these differ from member data names. Most languages >that support reflection allow this through attributes. C++ currently only >supports built-in attributes. Maybe we'll have something in C++ 2029? What can reflection do that typeid(), reinterpret_cast or just a simple type variable in a base class can't?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-06-18 16:06 +0000 |
| Message-ID | <Aw3zI.39602$G11.30265@fx01.iad> |
| In reply to | #80501 |
MrSpook_gavL@es9w71p.tv writes: >On Fri, 18 Jun 2021 08:06:55 -0700 (PDT) >"daniel...@gmail.com" <danielaparker@gmail.com> wrote: >>On Friday, June 18, 2021 at 2:56:34 AM UTC-4, David Brown wrote: >>> That all depends on your needs. At the moment, I for one have no need >>> for anything like that in C++. >> >>It's not about your needs, it's about how the absence of fundamental types >>in the C++ standard library impedes the emergence of libraries. Writing a >>C++ library to process standard or de facto standard data formats >>such as JSON, XML, CBOR, BSON, SQL is much more work and the results are > >Why? What do you think typedefs (or the silly using syntax) are for? > >>far less satisfactory than in other languages that have support for >>fundamental types such as int128, uint128, float128, big_int, big_decimal, > >At least C++ has unsigned types which is more than java managed for 2 decades. > >>though. C++ will still need a way to tag information to a C++ entity, such as >>serialized names where these differ from member data names. Most languages >>that support reflection allow this through attributes. C++ currently only >>supports built-in attributes. Maybe we'll have something in C++ 2029? > >What can reflection do that typeid(), reinterpret_cast or just a simple type >variable in a base class can't? Iterate over the members of a class/struct dynamically, for example.
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_Zp_@opm5ve6jyhq.ac.uk |
|---|---|
| Date | 2021-06-18 09:22 +0000 |
| Message-ID | <sahol0$17e6$1@gioia.aioe.org> |
| In reply to | #80485 |
On Thu, 17 Jun 2021 13:45:33 -0700 (PDT) "daniel...@gmail.com" <danielaparker@gmail.com> wrote: >On Wednesday, June 16, 2021 at 4:35:59 AM UTC-4, David Brown wrote: >> >> As soon as ... reflection and metaclasses make it to the >> language, I'll be using them too. >> >"As soon as" probably means C++ 2026. > >And in the meantime, while other languages such as rust see the >emergence of a rich library ecosystem, C++ remains comparatively >impoverished because of the absence of standard types - no >int128, no uint128, no float128, no big_decimal, no big_int, >no unicode encoding validators or converters ... And consequently, >no comprehensive CBOR or BSON or SQL libraries that map to standard >types, no JSON or XML libraries that don't reimplement unicode >encoding validation and conversion ... Don't project your own requirements onto others. I don't think I've ever once thought I've needed any of that in the language in the last 20 years since its all solved either by posix or freely available libraries.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-06-16 04:55 -0700 |
| Message-ID | <a63cd371-f12f-419f-9200-32e5a1d82892n@googlegroups.com> |
| In reply to | #80425 |
On Wednesday, 16 June 2021 at 07:34:06 UTC+3, Juha Nieminen wrote: > Öö Tiib <oot...@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.) You have lost capability to read, Juha, so you build straw-men that I did not write about C++98 and so then argue with those. The constexpr of C++14 was awesome. The sabotage of C++17 breaking it to hard to use and adding non-working 'if constexpr', 'consteval' and other horrible std::lawyer::laundry is very disappointing. Here you continue about people with whom I've nothing to do: > 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. In C++14 the only issue is std::initializer_list that they never repaired all rest is good. C++17 copy-pasted some fine classes from boost all rest is trash.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-06-16 13:16 +0000 |
| Message-ID | <sactk3$175u$2@gioia.aioe.org> |
| In reply to | #80447 |
Öö Tiib <ootiib@hot.ee> wrote: > You have lost capability to read, Juha, so you build straw-men that I did not > write about C++98 and so then argue with those. Is it even possible to just have a conversation in this newsgroup without accusations being thrown around? Just relax.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-06-16 11:03 -0700 |
| Message-ID | <bcf46d80-88aa-4f18-8110-8786246aa4bcn@googlegroups.com> |
| In reply to | #80453 |
On Wednesday, 16 June 2021 at 16:17:09 UTC+3, Juha Nieminen wrote: > Öö Tiib <oot...@hot.ee> wrote: > > You have lost capability to read, Juha, so you build straw-men that I did not > > write about C++98 and so then argue with those. > Is it even possible to just have a conversation in this newsgroup without > accusations being thrown around? Just relax. But I feel relaxed ... my accusations were straight to the point. You in lengths discussed something with what I mostly agree in manner like I had said something that I did not. You avoided discussing what I said that C++17 was horrible, pathetic trash, sabotage of language I liked and so I'm stuck in C++14.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-06-17 05:35 +0000 |
| Message-ID | <saemub$8ej$1@gioia.aioe.org> |
| In reply to | #80472 |
Öö Tiib <ootiib@hot.ee> wrote: > and so I'm stuck in C++14. My condolences.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-06-17 16:51 -0700 |
| Message-ID | <284fd2a3-ea38-4b0a-a4dc-f347a2fc8e99n@googlegroups.com> |
| In reply to | #80480 |
On Thursday, 17 June 2021 at 08:35:26 UTC+3, Juha Nieminen wrote: > Öö Tiib <oot...@hot.ee> wrote: > > and so I'm stuck in C++14. > My condolences. No condolescences are mine ... to those who have to use C++17 and so their code is formally full of undefined behaviors.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2021-06-17 20:19 -0400 |
| Subject | Re: Why does vector::reserve() not grow exponentially ? |
| Message-ID | <cone.1623975541.122784.114585.1004@monster.email-scan.com> |
| In reply to | #80487 |
[Multipart message — attachments visible in raw view] — view raw
Öö Tiib writes: > On Thursday, 17 June 2021 at 08:35:26 UTC+3, Juha Nieminen wrote: > > Öö Tiib <oot...@hot.ee> wrote: > > > and so I'm stuck in C++14. > > My condolences. > > No condolescences are mine ... to those who have to use C++17 and so their > code is formally full of undefined behaviors. C++17 isn't that bad. std::variant alone is worth the price of the admission.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-06-17 18:22 -0700 |
| Message-ID | <a1c534e5-25f1-4f90-98ce-a9f5f9a667d7n@googlegroups.com> |
| In reply to | #80488 |
On Friday, 18 June 2021 at 03:19:18 UTC+3, Sam wrote: > Öö Tiib writes: > > > On Thursday, 17 June 2021 at 08:35:26 UTC+3, Juha Nieminen wrote: > > > Öö Tiib <oot...@hot.ee> wrote: > > > > and so I'm stuck in C++14. > > > My condolences. > > > > No condolescences are mine ... to those who have to use C++17 and so their > > code is formally full of undefined behaviors. > C++17 isn't that bad. std::variant alone is worth the price of the admission. 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 optional and variant are in std now. All these implementations are undefined behavior by C++17 but if I do not use C++17 compilers or C++14 compilers to what defects of C++17 were back-ported then problem is solved.
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_6a2az@yxcggolr9p.com |
|---|---|
| Date | 2021-06-18 09:24 +0000 |
| Message-ID | <sahonk$18gg$1@gioia.aioe.org> |
| In reply to | #80489 |
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.
[toc] | [prev] | [next] | [standalone]
Page 6 of 13 — ← Prev page 1 … 4 5 [6] 7 8 … 13 Next page →
Back to top | Article view | comp.lang.c++
csiph-web