Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #83921 > unrolled thread
| Started by | Muttley@dastardlyhq.com |
|---|---|
| First post | 2022-05-03 15:16 +0000 |
| Last post | 2022-06-01 14:40 +0200 |
| Articles | 20 on this page of 95 — 21 participants |
Back to article view | Back to comp.lang.c++
Anyone ever used vector<bool> ? Muttley@dastardlyhq.com - 2022-05-03 15:16 +0000
Re: Anyone ever used vector<bool> ? Ben <ben.usenet@bsb.me.uk> - 2022-05-03 16:39 +0100
Re: Anyone ever used vector<bool> ? Muttley@dastardlyhq.com - 2022-05-03 16:12 +0000
Re: Anyone ever used vector<bool> ? Bo Persson <bo@bo-persson.se> - 2022-05-03 20:25 +0200
Re: Anyone ever used vector<bool> ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-05-03 12:00 -0700
Re: Anyone ever used vector<bool> ? Juha Nieminen <nospam@thanks.invalid> - 2022-05-04 10:50 +0000
Re: Anyone ever used vector<bool> ? Muttley@dastardlyhq.com - 2022-05-03 16:14 +0000
Re: Anyone ever used vector<bool> ? Jack Lemmon <invalid@invalid.net> - 2022-05-03 17:33 +0100
Re: Anyone ever used vector<bool> ? Manfred <noname@add.invalid> - 2022-05-03 19:13 +0200
Re: Anyone ever used vector<bool> ? Muttley@dastardlyhq.com - 2022-05-04 09:13 +0000
Re: Anyone ever used vector<bool> ? Juha Nieminen <nospam@thanks.invalid> - 2022-05-04 10:45 +0000
Re: Anyone ever used vector<bool> ? Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-04 14:09 +0300
Re: Anyone ever used vector<bool> ? Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-05-04 14:39 -0700
Re: Anyone ever used vector<bool> ? red floyd <no.spam.here@its.invalid> - 2022-05-04 15:17 -0700
Re: Anyone ever used vector<bool> ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-05-05 01:57 -0400
Re: Anyone ever used vector<bool> ? Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-05 09:12 +0300
Re: Anyone ever used vector<bool> ? Juha Nieminen <nospam@thanks.invalid> - 2022-05-05 06:17 +0000
Re: Anyone ever used vector<bool> ? Ben <ben.usenet@bsb.me.uk> - 2022-05-05 10:49 +0100
Re: Anyone ever used vector<bool> ? Öö Tiib <ootiib@hot.ee> - 2022-05-05 04:29 -0700
Re: Anyone ever used vector<bool> ? Ben <ben.usenet@bsb.me.uk> - 2022-05-05 12:56 +0100
Re: Anyone ever used vector<bool> ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-05 21:37 +0200
Re: Anyone ever used vector<bool> ? Ben <ben.usenet@bsb.me.uk> - 2022-05-05 21:13 +0100
Re: Anyone ever used vector<bool> ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-06 10:39 +0200
Re: Anyone ever used vector<bool> ? Ben <ben.usenet@bsb.me.uk> - 2022-05-06 11:54 +0100
Re: Anyone ever used vector<bool> ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-06 14:29 +0200
Re: Anyone ever used vector<bool> ? Ben <ben.usenet@bsb.me.uk> - 2022-05-06 17:05 +0100
Re: Anyone ever used vector<bool> ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-06 10:22 -0700
Re: Anyone ever used vector<bool> ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-06 22:18 +0200
Re: Anyone ever used vector<bool> ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-06 13:51 -0700
Re: Anyone ever used vector<bool> ? Muttley@dastardlyhq.com - 2022-05-07 08:41 +0000
Re: Anyone ever used vector<bool> ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-07 12:33 +0200
Re: Anyone ever used vector<bool> ? Muttley@dastardlyhq.com - 2022-05-07 16:12 +0000
Re: Anyone ever used vector<bool> ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-07 09:37 -0700
Re: Anyone ever used vector<bool> ? Muttley@dastardlyhq.com - 2022-05-09 09:02 +0000
Re: Anyone ever used vector<bool> ? Bo Persson <bo@bo-persson.se> - 2022-05-09 12:14 +0200
Re: Anyone ever used vector<bool> ? Muttley@dastardlyhq.com - 2022-05-09 15:36 +0000
Re: Anyone ever used vector<bool> ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-05-09 11:56 -0400
Re: Anyone ever used vector<bool> ? Muttley@dastardlyhq.com - 2022-05-09 16:18 +0000
Re: Anyone ever used vector<bool> ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-09 09:38 -0700
Re: Anyone ever used vector<bool> ? Muttley@dastardlyhq.com - 2022-05-10 15:55 +0000
Re: Anyone ever used vector<bool> ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-05-10 13:28 -0400
Re: Anyone ever used vector<bool> ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-05-10 10:16 -0400
Re: Anyone ever used vector<bool> ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-10 18:40 +0200
Re: Anyone ever used vector<bool> ? Manfred <noname@add.invalid> - 2022-05-10 19:50 +0200
Re: Anyone ever used vector<bool> ? Öö Tiib <ootiib@hot.ee> - 2022-05-12 05:44 -0700
Re: Anyone ever used vector<bool> ? Manfred <noname@add.invalid> - 2022-05-12 17:24 +0200
Re: Anyone ever used vector<bool> ? Öö Tiib <ootiib@hot.ee> - 2022-05-12 20:11 -0700
Re: Anyone ever used vector<bool> ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-05-12 12:53 -0400
Re: Anyone ever used vector<bool> ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-05-12 22:53 -0400
Re: Anyone ever used vector<bool> ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-13 18:34 +0200
Re: Anyone ever used vector<bool> ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-05-13 23:46 -0400
Re: Anyone ever used vector<bool> ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-14 11:43 +0200
Re: Anyone ever used vector<bool> ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-15 07:48 -0700
Re: Anyone ever used vector<bool> ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-16 03:30 +0200
Re: Anyone ever used vector<bool> ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-05-15 22:57 -0400
Re: Anyone ever used vector<bool> ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-17 05:30 -0700
Re: Anyone ever used vector<bool> ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-17 05:19 -0700
Re: Anyone ever used vector<bool> ? Juha Nieminen <nospam@thanks.invalid> - 2022-05-16 05:46 +0000
Re: Anyone ever used vector<bool> ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-17 05:37 -0700
Re: Anyone ever used vector<bool> ? wij <wyniijj2@gmail.com> - 2022-05-12 08:05 -0700
Re: Anyone ever used vector<bool> ? scott@slp53.sl.home (Scott Lurndal) - 2022-05-09 17:20 +0000
Re: Anyone ever used vector<bool> ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-09 12:05 -0700
Re: Anyone ever used vector<bool> ? Bo Persson <bo@bo-persson.se> - 2022-05-09 21:57 +0200
Re: Anyone ever used vector<bool> ? wij <wyniijj2@gmail.com> - 2022-05-09 13:56 -0700
Re: Anyone ever used vector<bool> ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-09 08:33 -0700
Re: Anyone ever used vector<bool> ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-05-09 11:56 -0400
Re: Anyone ever used vector<bool> ? Manfred <noname@add.invalid> - 2022-05-09 18:13 +0200
Re: Anyone ever used vector<bool> ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-05-10 10:14 -0400
Re: Anyone ever used vector<bool> ? scott@slp53.sl.home (Scott Lurndal) - 2022-05-10 14:31 +0000
Re: Anyone ever used vector<bool> ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-07 18:38 +0200
Re: Anyone ever used vector<bool> ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-05-07 18:28 -0400
Re: Anyone ever used vector<bool> ? Manfred <noname@add.invalid> - 2022-05-08 18:37 +0200
Re: Anyone ever used vector<bool> ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-08 11:50 -0700
Re: Anyone ever used vector<bool> ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-05-08 18:18 -0400
Re: Anyone ever used vector<bool> ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-07 09:45 -0700
Re: Anyone ever used vector<bool> ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-07 19:12 +0200
Re: Anyone ever used vector<bool> ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-07 20:36 -0700
Re: Anyone ever used vector<bool> ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-08 08:26 +0200
Re: Anyone ever used vector<bool> ? scott@slp53.sl.home (Scott Lurndal) - 2022-05-06 13:55 +0000
Re: Anyone ever used vector<bool> ? Juha Nieminen <nospam@thanks.invalid> - 2022-05-06 06:35 +0000
Re: Anyone ever used vector<bool> ? Ben <ben.usenet@bsb.me.uk> - 2022-05-06 11:29 +0100
Re: Anyone ever used vector<bool> ? Juha Nieminen <nospam@thanks.invalid> - 2022-05-09 04:58 +0000
Re: Anyone ever used vector<bool> ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-08 22:30 -0700
Re: Anyone ever used vector<bool> ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-03 14:41 -0700
Re: Anyone ever used vector<bool> ? Andrea Venturoli <ml.diespammer@netfence.it> - 2022-05-04 08:20 +0200
Re: Anyone ever used vector<bool> ? wij wij <wyniijj2@gmail.com> - 2022-05-04 03:21 -0700
Re: Anyone ever used vector<bool> ? Muttley@dastardlyhq.com - 2022-05-04 10:52 +0000
Re: Anyone ever used vector<bool> ? Juha Nieminen <nospam@thanks.invalid> - 2022-05-04 10:47 +0000
Re: Anyone ever used vector<bool> ? Muttley@dastardlyhq.com - 2022-05-04 10:53 +0000
Re: Anyone ever used vector<bool> ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-01 05:46 +0200
Re: Anyone ever used vector<bool> ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-01 07:31 +0200
Re: Anyone ever used vector<bool> ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-06-01 14:20 +0200
Re: Anyone ever used vector<bool> ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-01 14:23 +0200
Re: Anyone ever used vector<bool> ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-06-01 14:26 +0200
Re: Anyone ever used vector<bool> ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-01 14:40 +0200
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-05-03 15:16 +0000 |
| Subject | Anyone ever used vector<bool> ? |
| Message-ID | <t4rh06$1jlv$1@gioia.aioe.org> |
I need to store ~70K images in memory as B&W bitmaps so any chance of reducing memory usage is a bonus. I've never used vector<bool> because of all the warnings that it doesn't play nice with other parts of the STL. Anyone know any different? Unfortunately I need something that be dynamically sized or I'd use std::bitset but that has to be sized at compile time which is no use.
[toc] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-03 16:39 +0100 |
| Message-ID | <87y1zir5fl.fsf@bsb.me.uk> |
| In reply to | #83921 |
Muttley@dastardlyhq.com writes: > I need to store ~70K images in memory as B&W bitmaps so any chance of reducing > memory usage is a bonus. I'd wrap a std::vector<unsigned int> in a class so you can implement whatever access you want to the bits cleanly. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-05-03 16:12 +0000 |
| Message-ID | <t4rk9o$19hq$1@gioia.aioe.org> |
| In reply to | #83922 |
On Tue, 03 May 2022 16:39:42 +0100 Ben <ben.usenet@bsb.me.uk> wrote: >Muttley@dastardlyhq.com writes: > >> I need to store ~70K images in memory as B&W bitmaps so any chance of >reducing >> memory usage is a bonus. > >I'd wrap a std::vector<unsigned int> in a class so you can implement >whatever access you want to the bits cleanly. To be fair, if I was going to roll my own I'd just use a C u_char array wrapped in a class but I can't be bothered to write all the boilerplate construct,set,unset,copy etc code, hence I was hoping to use vector<bool> directly if its not going to cause any nasty gotchas.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2022-05-03 20:25 +0200 |
| Message-ID | <jddad0Fe54kU1@mid.individual.net> |
| In reply to | #83924 |
On 2022-05-03 at 18:12, Muttley@dastardlyhq.com wrote: > On Tue, 03 May 2022 16:39:42 +0100 > Ben <ben.usenet@bsb.me.uk> wrote: >> Muttley@dastardlyhq.com writes: >> >>> I need to store ~70K images in memory as B&W bitmaps so any chance of >> reducing >>> memory usage is a bonus. >> >> I'd wrap a std::vector<unsigned int> in a class so you can implement >> whatever access you want to the bits cleanly. > > To be fair, if I was going to roll my own I'd just use a C u_char array > wrapped in a class but I can't be bothered to write all the boilerplate > construct,set,unset,copy etc code, hence I was hoping to use vector<bool> > directly if its not going to cause any nasty gotchas. > The only gotcha is that vector<bool> doesn't *fully* conform to the standard. A container, and its iterators, should be able to return a reference to the elements. But, of course, you cannot return a (real) reference to a single bit. If that doesn't look like a problem in your program, feel free to use it. And I have never used it myself, but mainly because I have never had a use for that many bools in a program.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-05-03 12:00 -0700 |
| Message-ID | <87ilqm786l.fsf@nosuchdomain.example.com> |
| In reply to | #83929 |
Bo Persson <bo@bo-persson.se> writes:
[...]
> The only gotcha is that vector<bool> doesn't *fully* conform to the
> standard. A container, and its iterators, should be able to return a
> reference to the elements. But, of course, you cannot return a (real)
> reference to a single bit.
Strictly speaking, it does fully conform to the standard, since the
standard defines it. It doesn't fully conform to the requirements for
vector<foo>.
(IMHO it might have been better to define a vector_bool type that's not
a specialization of vector.)
> If that doesn't look like a problem in your program, feel free to use it.
>
> And I have never used it myself, but mainly because I have never had a
> use for that many bools in a program.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-05-04 10:50 +0000 |
| Message-ID | <t4tlpl$eui$3@gioia.aioe.org> |
| In reply to | #83929 |
Bo Persson <bo@bo-persson.se> wrote: > The only gotcha is that vector<bool> doesn't *fully* conform to the > standard. What "standard"? The C++ standard defines how std::vector<bool> works, so it's pretty much "standard" by definition. What's special about it is that in a few aspects it doesn't work in the same way as other standard library data containers. However, the others don't all work exactly in the same as each other either. Maybe std::vector<bool> should have a category of its own (like the other containers are categorized by how they behave and what they provide).
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-05-03 16:14 +0000 |
| Message-ID | <t4rkck$1as1$1@gioia.aioe.org> |
| In reply to | #83921 |
On 3 May 2022 15:43:45 GMT ram@zedat.fu-berlin.de (Stefan Ram) wrote: >Muttley@dastardlyhq.com writes: >>I need to store ~70K images in memory as B&W bitmaps so any chance of reducing > >>memory usage is a bonus. I've never used vector<bool> because of all the >>warnings that it doesn't play nice with other parts of the STL. Anyone know >>any different? > > Don't hesitate to use ::std::vector< bool >! You might like > to hide it behind an interface or a custom class; that way > you can switch easily to another implementation if need be. > (If you don't use an interface, you can also switch the > implementation later, albeit maybe a bit more difficult.) > > Bjarne wrote in 2014, "std::vector<bool> - when we need > more than 8*sizeof(long) bits". He did /not/ write "std:: > vector<bool> - Don't ever use it!". The core guidelines > also do not seem to advise against it. > > "vector<bool> - neither a vector, nor does it contain bools." Advising against it is not the same as promoting it :)
[toc] | [prev] | [next] | [standalone]
| From | Jack Lemmon <invalid@invalid.net> |
|---|---|
| Date | 2022-05-03 17:33 +0100 |
| Message-ID | <t4rlis$2sqqe$1@paganini.bofh.team> |
| In reply to | #83921 |
On 03/05/2022 16:16, Muttley@dastardlyhq.com wrote: > > Unfortunately I need something that be dynamically sized or I'd use std::bitset > but that has to be sized at compile time which is no use. > How about using List? <https://www.cplusplus.com/reference/list/list/> Not fast but dynamic in nature and vector modifiers and iterators can be used.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2022-05-03 19:13 +0200 |
| Message-ID | <t4rnrt$12mh$1@gioia.aioe.org> |
| In reply to | #83926 |
On 5/3/2022 6:33 PM, Jack Lemmon wrote: > On 03/05/2022 16:16, Muttley@dastardlyhq.com wrote: >> >> Unfortunately I need something that be dynamically sized or I'd use std::bitset >> but that has to be sized at compile time which is no use. >> > How about using List? <https://www.cplusplus.com/reference/list/list/> > Not fast but dynamic in nature and vector modifiers and iterators can be > used. > > > Well, not. The OP wants compact & fast. List is not it.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-05-04 09:13 +0000 |
| Message-ID | <t4tg4m$2f3$1@gioia.aioe.org> |
| In reply to | #83928 |
On Tue, 3 May 2022 19:13:33 +0200 Manfred <noname@add.invalid> wrote: >On 5/3/2022 6:33 PM, Jack Lemmon wrote: >> On 03/05/2022 16:16, Muttley@dastardlyhq.com wrote: >>> >>> Unfortunately I need something that be dynamically sized or I'd use >std::bitset >>> but that has to be sized at compile time which is no use. >>> >> How about using List? <https://www.cplusplus.com/reference/list/list/> >> Not fast but dynamic in nature and vector modifiers and iterators can be >> used. >> >> >> >Well, not. > >The OP wants compact & fast. List is not it. Indeed. Aside from using a list to store individual bits seems silly, I also need something that does direct indexing which list obviously doesn't do.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-05-04 10:45 +0000 |
| Message-ID | <t4tlfv$eui$1@gioia.aioe.org> |
| In reply to | #83926 |
Jack Lemmon <invalid@invalid.net> wrote: > On 03/05/2022 16:16, Muttley@dastardlyhq.com wrote: >> >> Unfortunately I need something that be dynamically sized or I'd use std::bitset >> but that has to be sized at compile time which is no use. >> > How about using List? <https://www.cplusplus.com/reference/list/list/> > Not fast but dynamic in nature and vector modifiers and iterators can be > used. I have hard time thinking of a less efficient way to store a bitmap (at least using standard library containers).
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-05-04 14:09 +0300 |
| Message-ID | <t4tmt4$vur$1@dont-email.me> |
| In reply to | #83936 |
04.05.2022 13:45 Juha Nieminen kirjutas: > Jack Lemmon <invalid@invalid.net> wrote: >> On 03/05/2022 16:16, Muttley@dastardlyhq.com wrote: >>> >>> Unfortunately I need something that be dynamically sized or I'd use std::bitset >>> but that has to be sized at compile time which is no use. >>> >> How about using List? <https://www.cplusplus.com/reference/list/list/> >> Not fast but dynamic in nature and vector modifiers and iterators can be >> used. > > I have hard time thinking of a less efficient way to store a bitmap > (at least using standard library containers). I have hard time finding any use case at all for std::list. I know there is a use case for holding dynamically created global objects alive and at the same memory address, but globals are evil anyway, regardless of how they are held.
[toc] | [prev] | [next] | [standalone]
| From | Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> |
|---|---|
| Date | 2022-05-04 14:39 -0700 |
| Message-ID | <f24d8edd-8fa2-4e13-a1ad-84d6797627fcn@googlegroups.com> |
| In reply to | #83941 |
On Wednesday, May 4, 2022 at 12:09:41 PM UTC+1, Paavo Helde wrote: > > I have hard time thinking of a less efficient way to store a bitmap > > (at least using standard library containers). > I have hard time finding any use case at all for std::list. I know there > is a use case for holding dynamically created global objects alive and > at the same memory address, but globals are evil anyway, regardless of > how they are held. I'm currently writing a "pre-compiler" that processes a translation unit and give output that can go into a normal C++20 compiler. In order to make it as fast as possible, I overloaded global new and delete so that memory is allocated in 10-megabyte blocks at a time, and nothing ever gets de-allocated. (It uses about 400 megs of RAM for an average source file). But anyway I use 'list' extensively to make sure every object stays where it is, instead of a vector de-allocating and moving stuff around.
[toc] | [prev] | [next] | [standalone]
| From | red floyd <no.spam.here@its.invalid> |
|---|---|
| Date | 2022-05-04 15:17 -0700 |
| Message-ID | <t4uu28$uch$1@redfloyd.dont-email.me> |
| In reply to | #83942 |
On 5/4/2022 3:07 PM, Stefan Ram wrote: > Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> writes: >> I use 'list' extensively to make sure every object stays >> where it is, instead of a vector de-allocating and moving >> stuff around. > > When one uses a vector of pointers to objects, the objects > are not moved when the size of the vector changes. Such a > vector then can be used like a list, but tests have often > shown the vector to be faster. > Items can, in fact, be moved. If you push_back() on a vector whose size() is the same as its capacity(), the vector needs to be reallocated, and the data may therefore move and be copied/moved.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-05-05 01:57 -0400 |
| Message-ID | <t4vovr$hf$1@dont-email.me> |
| In reply to | #83944 |
On 5/4/22 18:17, red floyd wrote: > On 5/4/2022 3:07 PM, Stefan Ram wrote: ... >> When one uses a vector of pointers to objects, the objects >> are not moved when the size of the vector changes. Such a >> vector then can be used like a list, but tests have often >> shown the vector to be faster. >> > > Items can, in fact, be moved. If you push_back() on a vector > whose size() is the same as its capacity(), the vector needs > to be reallocated, and the data may therefore move and be > copied/moved. True, the pointer objects stored in the vector may be moved. The objects that they point at are not.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-05-05 09:12 +0300 |
| Message-ID | <t4vpt2$7c1$1@dont-email.me> |
| In reply to | #83942 |
05.05.2022 00:39 Frederick Virchanza Gotham kirjutas: > On Wednesday, May 4, 2022 at 12:09:41 PM UTC+1, Paavo Helde wrote: > >>> I have hard time thinking of a less efficient way to store a bitmap >>> (at least using standard library containers). >> I have hard time finding any use case at all for std::list. I know there >> is a use case for holding dynamically created global objects alive and >> at the same memory address, but globals are evil anyway, regardless of >> how they are held. > > > I'm currently writing a "pre-compiler" that processes a translation unit and give output that can go into a normal C++20 compiler. > > In order to make it as fast as possible, I overloaded global new and delete so that memory is allocated in 10-megabyte blocks at a time, This looks like what a normal memory allocator does anyway. > and nothing ever gets de-allocated. This looks like a typical pool allocator. No need to reinvent the wheel. (It uses about 400 megs of RAM for an average source file). But anyway I use 'list' extensively to make sure every object stays where it is, instead of a vector de-allocating and moving stuff around. If you never delete or insert any elements, then std::deque also guarantees that the stuff is not moved around, and provides better memory proximity guarantees than std::list. Even if your allocator manages to place the elements next to each other, they would be still interspersed with unneeded forward and backward links inside a std::list. If you are concerned about performance, you should be concerned about memory compactness and proximity. So still I do not see a use case for std::list here, std::deque looks better in all senses. YMMV.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-05-05 06:17 +0000 |
| Message-ID | <t4vq6a$1n9b$1@gioia.aioe.org> |
| In reply to | #83941 |
Paavo Helde <eesnimi@osa.pri.ee> wrote: > I have hard time finding any use case at all for std::list. When I was working at the university here I once had to implement (a rather complicated and advanced) algorithm (which had something to do with graph manipulation) which required a doubly-linked list. No other data container would have done the job because the speed of the algorithm relied on the ability to splice linked lists (and sections of them). That being said, std::list couldn't be used for this, especially now that std::list::splice() is not an O(1) operation (which would pretty much defeat the purpose). The one strength of std::list that no other container had (nor can have), and they removed it...
[toc] | [prev] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-05 10:49 +0100 |
| Message-ID | <87bkwcpauz.fsf@bsb.me.uk> |
| In reply to | #83951 |
Juha Nieminen <nospam@thanks.invalid> writes: > Paavo Helde <eesnimi@osa.pri.ee> wrote: >> I have hard time finding any use case at all for std::list. > > When I was working at the university here I once had to implement > (a rather complicated and advanced) algorithm (which had something to > do with graph manipulation) which required a doubly-linked list. No other > data container would have done the job because the speed of the algorithm > relied on the ability to splice linked lists (and sections of them). > > That being said, std::list couldn't be used for this, especially now > that std::list::splice() is not an O(1) operation (which would pretty > much defeat the purpose). It's O(1) in C++11, 14 and 20 (at least in the public drafts). > The one strength of std::list that no other container had (nor can have), > and they removed it... -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-05-05 04:29 -0700 |
| Message-ID | <4dc0556b-577d-4779-9e92-ad70622ce178n@googlegroups.com> |
| In reply to | #83952 |
On Thursday, 5 May 2022 at 12:50:26 UTC+3, Ben wrote: > Juha Nieminen <nos...@thanks.invalid> writes: > > > Paavo Helde <ees...@osa.pri.ee> wrote: > >> I have hard time finding any use case at all for std::list. > > > > When I was working at the university here I once had to implement > > (a rather complicated and advanced) algorithm (which had something to > > do with graph manipulation) which required a doubly-linked list. No other > > data container would have done the job because the speed of the algorithm > > relied on the ability to splice linked lists (and sections of them). > > > > That being said, std::list couldn't be used for this, especially now > > that std::list::splice() is not an O(1) operation (which would pretty > > much defeat the purpose). > > It's O(1) in C++11, 14 and 20 (at least in the public drafts). It has 6 overloads. Most are O(1) but one case where we transfer iterator range from other list to this list is linear in length of said range.
[toc] | [prev] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-05 12:56 +0100 |
| Message-ID | <875ymkp4zv.fsf@bsb.me.uk> |
| In reply to | #83953 |
Öö Tiib <ootiib@hot.ee> writes: > On Thursday, 5 May 2022 at 12:50:26 UTC+3, Ben wrote: >> Juha Nieminen <nos...@thanks.invalid> writes: >> >> > Paavo Helde <ees...@osa.pri.ee> wrote: >> >> I have hard time finding any use case at all for std::list. >> > >> > When I was working at the university here I once had to implement >> > (a rather complicated and advanced) algorithm (which had something to >> > do with graph manipulation) which required a doubly-linked list. No other >> > data container would have done the job because the speed of the algorithm >> > relied on the ability to splice linked lists (and sections of them). >> > >> > That being said, std::list couldn't be used for this, especially now >> > that std::list::splice() is not an O(1) operation (which would pretty >> > much defeat the purpose). >> >> It's O(1) in C++11, 14 and 20 (at least in the public drafts). > > It has 6 overloads. Most are O(1) but one case where we transfer iterator > range from other list to this list is linear in length of said range. Obviously, but that's surely not what the OP was talking about. That one could never have been, and will never be O(1). -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web