[squid-dev] [PATCH] SBuf const iterator fixes

[Kinkie]

On Mon, Feb 8, 2016 at 8:15 PM, Alex Rousskov
<rousskov at measurement-factory.com> wrote:
> On 02/08/2016 11:18 AM, Amos Jeffries wrote:
>> The SBufIterator is mostly actually a const iterator. But not quite.
>
> I am not sure I understand what you are implying because you did not
> change any const-related aspects of SBufIterator. What are the
> requirements for being a "const iterator" class that old SBufIterator
> violated?

It behaves like a const while not being explicitly so.
You can't do
auto i = sbuf.begin();
*i = 'a';

>> The point of difference from const_iterator is the operator*() API which
>> is also different from the normal itertor API in that is returns a char
>> instead of a char& or const char &.
>
> Please explain why returning char is wrong for const_iterator. I
> understand that [all?] standard iterators return a reference, and I also
> understand that a non-const iterator cannot return a char, but I do not
> yet understand how that difference affects constant SBufIterator.

It behaves the same,but it's a different API.

> Overall, it feels like returning a simple "char" may be more efficient
> than forcing the compiler to optimize away references to "char", but I
> may be missing something important here.

WRT the const iterator, yes. But the iterator should return a char
referente, and COW on access which is tricky.

>> This has side effects on the reverse iterator and SBuf begin/end
>> methods. Which are also const'ified.
>
> Please note that in the C++11 land, we are supposed to use
> cbegin/cend/etc. methods if we unconditionally want a const_iterator.
> These are added to the old set of begin/end/etc. methods (half of those
> old methods return const_iterators, depending on the object constness
> rather than method name):

nod. so far we are only reading from iterators.

Kinkie