Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #158331 > unrolled thread

C++ container / iterator question

Back to article view | Back to comp.lang.c

Contents

  C++ container / iterator question Heng Yuan <superduperhengyuan@gmail.com> - 2021-01-12 21:32 -0800
    Re: C++ container / iterator question Anton Shepelev <anton.txt@gmail.com> - 2021-01-25 23:07 +0300
      Re: C++ container / iterator question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-25 14:40 -0800
      Re: C++ container / iterator question Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-25 22:57 +0000
        Re: C++ container / iterator question Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2021-01-26 16:26 +0100
          Re: C++ container / iterator question Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-26 19:14 +0300
          Re: C++ container / iterator question James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-26 11:29 -0500
            Re: C++ container / iterator question Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-26 20:09 +0300
          Re: C++ container / iterator question Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-26 17:05 +0000
            Re: C++ container / iterator question Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2021-01-26 21:00 +0100
              Re: C++ container / iterator question Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-01-26 20:17 +0000
              Re: C++ container / iterator question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-26 13:19 -0800
              Re: C++ container / iterator question James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-26 17:40 -0500
              Re: C++ container / iterator question Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-27 00:09 +0000
              Re: C++ container / iterator question Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-27 12:20 +0300
              Re: C++ container / iterator question "jfbod...@gmail.com" <jfbode1029@gmail.com> - 2021-01-27 08:54 -0800
                Re: C++ container / iterator question Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-27 20:02 +0300
                Re: C++ container / iterator question Manfred <noname@add.invalid> - 2021-01-27 18:14 +0100

#158331 — C++ container / iterator question

Let's say that I have a custom container SpoolList like following.

template<class T>
class SpoolList
{
public:
	const T& get (size_t index) const
	{
		Block& block = getBlock (index);
		return block.get (index - block.startIndex);
	}
	void set (size_t index, const T& value)
	{
		Block& block = getBlock (index);
		block.dirty = true;
		block.set (index - block.startIndex, value);
	}
	...
};

Block is basically a cached block of data loaded from disk (there can be 2-3 such LRU blocks).

My questions are the following.

1) Overloading operator[] does not get the correct operator[] used.  I overloaded the following two:

    T& operator[](size_t index)
	{
		Block& block = getBlock (index);
		block.dirty = true;
		return block.get (index - block.startIndex);
	}
	const T& operator[](size_t index) const
	{
		return get (index);
	}

However, it appears that G++ calls the first one if the SpoolList is not a const version.  That is, for a code like the following:
		SpoolList<int> list;
		...
		int myValue = list[0];
The operator[] called is still the first one which would set the dirty bit.

Did I do something wrong?  While I could certainly call get() or use const_iterator, my concern is that the user of the SpoolList would could use operator[] in undesired situations.  Is there a better way of operator overloading that does not have this issue?

2) What about iterators?  I had the similar issue for operator*.  That is the first one is always called if the iterator itself is not const.
    T& operator* ();
	const T& operator* () const;

3) My goal is actually trying to run C++ STL algorithms such as sort / n-th element etc.  Two sub questions.
3a) How many LRU blocks is optimal for C++ sort?  My guess is two.
3b) If we consider the search phase and replace-phase of C++ STL algorithms, it appears to me that there is a potential for faster sorting if the correct iterator is used, if data is mostly sort already.
		SpoolList<int> list;
		...
		std::sort (list.begin (), list.end ());

Is there a way s.t. minimize the number of blocks with dirty bit being set if the data is not changed?

Can you provide any pointers for look at / follow / learn?

Thanks,

Heng Yuan

[toc] | [next] | [standalone]

#158611

Heng Yuan:

> Let's say that I have a custom container SpoolList like following.
> [...]

This group is devoted to C, not to C++, see:
comp.lang.c++

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#158615

Anton Shepelev <anton.txt@gmail.com> writes:
> Heng Yuan:
>> Let's say that I have a custom container SpoolList like following.
>> [...]
>
> This group is devoted to C, not to C++, see:
> comp.lang.c++

It's a bug in Google Groups (it's started dropping the "++" from the
newsgroup name), as I pointed out on this thread a couple of weeks ago.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#158617

On 2021-01-25, Anton Shepelev <anton.txt@gmail.com> wrote:
> Heng Yuan:
>
>> Let's say that I have a custom container SpoolList like following.
>> [...]
>
> This group is devoted to C, not to C++, see:
> comp.lang.c++

Not anymore. Some Javascript-spewing troglodyte who was put charge of
pointlessly diddling Google Groups has decided that + characters in a
newsgroup name are no longer significant.

-- 
TXR Programming Language: http://nongnu.org/txr

[toc] | [prev] | [next] | [standalone]

#158630

On 25.01.21 23:57, Kaz Kylheku wrote:
> On 2021-01-25, Anton Shepelev <anton.txt@gmail.com> wrote:
>> Heng Yuan:
>>
>>> Let's say that I have a custom container SpoolList like following.
>>> [...]
>>
>> This group is devoted to C, not to C++, see:
>> comp.lang.c++
>
> Not anymore. Some Javascript-spewing troglodyte who was put charge of
> pointlessly diddling Google Groups has decided that + characters in a
> newsgroup name are no longer significant.
>
So create a CPP group instead of highjacking
this one.
Found about 80 CPP groups in the subscribe list.

[toc] | [prev] | [next] | [standalone]

#158631

Sjouke Burry:
> Kaz Kylheku:
> > Anton Shepelev:
> >
> > > This group is devoted to C, not to C++, see:
> > > comp.lang.c++
> >
> > Not anymore. Some Javascript-spewing troglodyte who was
> > put charge of pointlessly diddling Google Groups has
> > decided that + characters in a newsgroup name are no
> > longer significant.
>
> So create a CPP group instead of highjacking this one.
> Found about 80 CPP groups in the subscribe list.

A bug in the Google Groups interface with Usenet, which is
broken by design, is not a reason for the creation of a new
group with a name compatible with the bug. It is, however, a
very strong reason to abandon Google Groups for good,
register with a free and possibly anonymous Usenet server,
and install a decent newsreader.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#158632

On 1/26/21 10:26 AM, Sjouke Burry wrote:
> On 25.01.21 23:57, Kaz Kylheku wrote:
...
>> Not anymore. Some Javascript-spewing troglodyte who was put charge of
>> pointlessly diddling Google Groups has decided that + characters in a
>> newsgroup name are no longer significant.
>>
> So create a CPP group instead of highjacking
> this one.
> Found about 80 CPP groups in the subscribe list.

No one is trying to hijack this group. People are posting to
comp.lang.c++, unaware of the fact that Google Groups will ignore the ++
and direct their messages to this group.

My news server, eternal-september, only shows 58 CPP groups, and the
overwhelming majority of them are associated with Borland, and most of
those are about C++Builder. One is for the IBM compiler, one is
demon.ip.cppnews, and the remaining 3 are Russian. None of them seems
intended as a forum for discussing C++ in general.

[toc] | [prev] | [next] | [standalone]

#158634

James Kuyper:

> My news server, eternal-september, only shows 58 CPP
> groups, and the overwhelming majority of them are
> associated with Borland, and most of those are about
> C++Builder. One is for the IBM compiler, one is
> demon.ip.cppnews, and the remaining 3 are Russian. None of
> them seems intended as a forum for discussing C++ in
> general.

What is more important, is that most of those other groups
are empty crumbling halls where the only sound is the echo
of your footsteps. If the Russian groups you mention are
gated Fidonet echoes, it is a bit more complicated to post
to them via a general Usenet server than to a normal
unmoderated Usenet groups. I had to register to receive a
special code, and inlcude it in the Keywords header. There
are easier Fidonet gatewaus, but they do not work as
general-purpose servers, i.e.:

                  https://www.fidonet.fi/

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#158633

On 2021-01-26, Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> wrote:
> On 25.01.21 23:57, Kaz Kylheku wrote:
>> On 2021-01-25, Anton Shepelev <anton.txt@gmail.com> wrote:
>>> Heng Yuan:
>>>
>>>> Let's say that I have a custom container SpoolList like following.
>>>> [...]
>>>
>>> This group is devoted to C, not to C++, see:
>>> comp.lang.c++
>>
>> Not anymore. Some Javascript-spewing troglodyte who was put charge of
>> pointlessly diddling Google Groups has decided that + characters in a
>> newsgroup name are no longer significant.
>>
> So create a CPP group instead of highjacking
> this one.

comp.lang.c++ existed before Google, period.

why should Usenet adjust to some idiotic Google Groups problem?

Creating a new C++ newsgroup, or renaming one, is a big deal.

-- 
TXR Programming Language: http://nongnu.org/txr

[toc] | [prev] | [next] | [standalone]

#158635

On 26.01.21 18:05, Kaz Kylheku wrote:
> On 2021-01-26, Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> wrote:
>> On 25.01.21 23:57, Kaz Kylheku wrote:
>>> On 2021-01-25, Anton Shepelev <anton.txt@gmail.com> wrote:
>>>> Heng Yuan:
>>>>
>>>>> Let's say that I have a custom container SpoolList like following.
>>>>> [...]
>>>>
>>>> This group is devoted to C, not to C++, see:
>>>> comp.lang.c++
>>>
>>> Not anymore. Some Javascript-spewing troglodyte who was put charge of
>>> pointlessly diddling Google Groups has decided that + characters in a
>>> newsgroup name are no longer significant.
>>>
>> So create a CPP group instead of highjacking
>> this one.
>
> comp.lang.c++ existed before Google, period.
>
> why should Usenet adjust to some idiotic Google Groups problem?
>
> Creating a new C++ newsgroup, or renaming one, is a big deal.
>
So crashing into an existing group to take over is a better solution?

[toc] | [prev] | [next] | [standalone]

#158636

On Tue, 2021-01-26, Sjouke Burry wrote:
> On 26.01.21 18:05, Kaz Kylheku wrote:
>> On 2021-01-26, Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> wrote:
>>> On 25.01.21 23:57, Kaz Kylheku wrote:
>>>> On 2021-01-25, Anton Shepelev <anton.txt@gmail.com> wrote:
>>>>> Heng Yuan:
>>>>>
>>>>>> Let's say that I have a custom container SpoolList like following.
>>>>>> [...]
>>>>>
>>>>> This group is devoted to C, not to C++, see:
>>>>> comp.lang.c++
>>>>
>>>> Not anymore. Some Javascript-spewing troglodyte who was put charge of
>>>> pointlessly diddling Google Groups has decided that + characters in a
>>>> newsgroup name are no longer significant.
>>>>
>>> So create a CPP group instead of highjacking
>>> this one.
>>
>> comp.lang.c++ existed before Google, period.
>>
>> why should Usenet adjust to some idiotic Google Groups problem?
>>
>> Creating a new C++ newsgroup, or renaming one, is a big deal.
>>
> So crashing into an existing group to take over is a better solution?

I guess it can't hurt to reveal it now.  You can't stop us, anyway.

In 2017, we in the C++ World Domination Council finally managed to
plant a sleeper agent (code name: Bjarne) at Google.  He spent the two
first years swapping out dead Seagate drives in an Idaho server farm,
but in early 2020 he managed to get a transfer to the Google Groups
team, and was activated.  What you see now is the first fruit of his
work.

We're currently evaluating, and deciding on where to go next.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#158638

Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> writes:
> On 26.01.21 18:05, Kaz Kylheku wrote:
>> On 2021-01-26, Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> wrote:
>>> On 25.01.21 23:57, Kaz Kylheku wrote:
>>>> On 2021-01-25, Anton Shepelev <anton.txt@gmail.com> wrote:
>>>>> Heng Yuan:
>>>>>
>>>>>> Let's say that I have a custom container SpoolList like following.
>>>>>> [...]
>>>>>
>>>>> This group is devoted to C, not to C++, see:
>>>>> comp.lang.c++
>>>>
>>>> Not anymore. Some Javascript-spewing troglodyte who was put charge of
>>>> pointlessly diddling Google Groups has decided that + characters in a
>>>> newsgroup name are no longer significant.
>>>>
>>> So create a CPP group instead of highjacking
>>> this one.
>>
>> comp.lang.c++ existed before Google, period.
>>
>> why should Usenet adjust to some idiotic Google Groups problem?
>>
>> Creating a new C++ newsgroup, or renaming one, is a big deal.
>>
> So crashing into an existing group to take over is a better solution?

Nobody is "crashing into an existing group".  A handful of users have
tried to post to comp.lang.c++ using Google Groups (which *should* work)
and have had their articles show up in comp.lang.c due to a recently
introduced bug in Google Groups.  (I *think* it affects only original
posts, not followups; can anyone confirm or deny that?)

I've reported the bug, but I'm not optimistic about it being fixed any
time soon.

Creating a new group, either in Usenet or in Google Groups, is not a
solution to any of this.

Until the bug is fixed, we can just tell users about the problem and
advise them to avoid using Google Groups to make new posts to
comp.lang.c++.

Perhaps someone could write a paragraph briefly describing the problem
and potential workarounds, and post it (just once if possible) in
response to any future incorrect posts.  I might do so myself.  Anyone
who sees a new misposted article could just copy-and-paste that
paragraph into a followup and redirect followups to comp.lang.c++.
I'm open to other suggestions, but I don't think we need a lengthy
thread on the subject.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#158639

On 1/26/21 3:00 PM, Sjouke Burry wrote:
> On 26.01.21 18:05, Kaz Kylheku wrote:
>> On 2021-01-26, Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> wrote:
>>> On 25.01.21 23:57, Kaz Kylheku wrote:
>>>> On 2021-01-25, Anton Shepelev <anton.txt@gmail.com> wrote:
>>>>> Heng Yuan:
>>>>>
>>>>>> Let's say that I have a custom container SpoolList like following.
>>>>>> [...]
>>>>>
>>>>> This group is devoted to C, not to C++, see:
>>>>> comp.lang.c++
>>>>
>>>> Not anymore. Some Javascript-spewing troglodyte who was put charge of
>>>> pointlessly diddling Google Groups has decided that + characters in a
>>>> newsgroup name are no longer significant.
>>>>
>>> So create a CPP group instead of highjacking
>>> this one.
>>
>> comp.lang.c++ existed before Google, period.
>>
>> why should Usenet adjust to some idiotic Google Groups problem?
>>
>> Creating a new C++ newsgroup, or renaming one, is a big deal.
>>
> So crashing into an existing group to take over is a better solution?

Do you know of anyone who's been deliberately crashing into this group,
or who has argued for doing so?

[toc] | [prev] | [next] | [standalone]

#158640

On 2021-01-26, Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> wrote:
> On 26.01.21 18:05, Kaz Kylheku wrote:
>> On 2021-01-26, Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> wrote:
>>> On 25.01.21 23:57, Kaz Kylheku wrote:
>>>> On 2021-01-25, Anton Shepelev <anton.txt@gmail.com> wrote:
>>>>> Heng Yuan:
>>>>>
>>>>>> Let's say that I have a custom container SpoolList like following.
>>>>>> [...]
>>>>>
>>>>> This group is devoted to C, not to C++, see:
>>>>> comp.lang.c++
>>>>
>>>> Not anymore. Some Javascript-spewing troglodyte who was put charge of
>>>> pointlessly diddling Google Groups has decided that + characters in a
>>>> newsgroup name are no longer significant.
>>>>
>>> So create a CPP group instead of highjacking
>>> this one.
>>
>> comp.lang.c++ existed before Google, period.
>>
>> why should Usenet adjust to some idiotic Google Groups problem?
>>
>> Creating a new C++ newsgroup, or renaming one, is a big deal.
>>
> So crashing into an existing group to take over is a better solution?

No; that is a description of the problem. Or rather, its effect.

-- 
TXR Programming Language: http://nongnu.org/txr

[toc] | [prev] | [next] | [standalone]

#158641

Sjouke Burry:

> So crashing into an existing group to take over is a
> better solution?

You misunderstand. The lamer-oriented Google's web-client to
Usenet is broken: When sent from Google, messages to
comp.lang.c++ end up here. It is a bug.  The only solution
is to use a normal client.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#158661

On Tuesday, January 26, 2021 at 2:00:54 PM UTC-6, Sjouke Burry wrote:
> On 26.01.21 18:05, Kaz Kylheku wrote: 
> > On 2021-01-26, Sjouke Burry <burrynu...@ppllaanneett.nnll> wrote: 
> >> On 25.01.21 23:57, Kaz Kylheku wrote: 
> >>> On 2021-01-25, Anton Shepelev <anto...@gmail.com> wrote: 
> >>>> Heng Yuan: 
> >>>> 
> >>>>> Let's say that I have a custom container SpoolList like following. 
> >>>>> [...] 
> >>>> 
> >>>> This group is devoted to C, not to C++, see: 
> >>>> comp.lang.c++ 
> >>> 
> >>> Not anymore. Some Javascript-spewing troglodyte who was put charge of 
> >>> pointlessly diddling Google Groups has decided that + characters in a 
> >>> newsgroup name are no longer significant. 
> >>> 
> >> So create a CPP group instead of highjacking 
> >> this one. 
> > 
> > comp.lang.c++ existed before Google, period. 
> > 
> > why should Usenet adjust to some idiotic Google Groups problem? 
> > 
> > Creating a new C++ newsgroup, or renaming one, is a big deal. 
> >
> So crashing into an existing group to take over is a better solution?

The solution is for Google to fix their broken shit, or to stop using Groups for
usenet access (which I'm about 10 minutes away from as soon as I can 
find a good news client for MacOS).  Might as well, I'm starting to think Groups
is about to be EOL'd.  

[toc] | [prev] | [next] | [standalone]

#158663

jfbode1029:

> or to stop using Groups for usenet access (which I'm about
> 10 minutes away from as soon as I can find a good news
> client for MacOS).

On my vitage 2007 MacBook, I use the `tin' newsreader, and
like it:

   https://en.wikipedia.org/wiki/Tin_(newsreader)

I installed it right then, in 2007, from "Macports" or
similar system, but after the developer fixed an important
bug that prevented `tin' from viewing gated Russian Fidonet
echoes, I recompiled it from the source. It still works like
new.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#158665

On 1/27/2021 5:54 PM, jfbod...@gmail.com wrote:
> The solution is for Google to fix their broken shit, or to stop using Groups for
> usenet access (which I'm about 10 minutes away from as soon as I can
> find a good news client for MacOS).  Might as well, I'm starting to think Groups
> is about to be EOL'd.

Thunderbird works pretty OK, and it is available for MacOS too.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web