Re: [boost] Iterator Range and operator==

Subject: Re: [boost] Iterator Range and operator==
From: Olaf van der Spek (ml_at_[hidden])
Date: 2012-04-21 16:32:40

On Sat, Apr 21, 2012 at 10:01 PM, Neil Groves <neil_at_[hidden]> wrote:
>>
>> I know, but what do you think the average C++ dev is expecting?
>> IMO it's understandable (once you know about the issue), but not expected.
>>
>>
> If there were a solution whereby the choice of the array handling where
> zero-termination should be handled as the end were readily available
> without causing overhead for the existing specified supported cases we
> would remove the surprise. However, since the Range documentation clearly
> specifies that arrays are directly supported and literal strings are not I
> do not feel that one should be surprised. The use-case that was provided
> directly explicitly constructed a range from a char[]. No implicit
> conversion occurred.

Hi Neil,

Isn't the right-hand side of operator== implicitly converted from
string literal (or array) to range?

You didn't really answer the question "What do you think the average
C++ dev is expecting?" (when just reading that code)

> The use-case presented therefore explicitly constructed a range from a
> char[]. The length of the sequence was the length of the array. This is
> consistent with the behaviour for all arrays.
>
> One of the main reasons that the char* with zero-termination was rejected
> was because of the O(N) string length calculation causing the end()
> function to be O(N). This made specifying the complexity of range
> algorithms difficult. It was not a matter of unexpected semantics AFAICT.

I don't understand. The source is an array, not a char*, so size
calculation is not O(N).
Besides, this cost is paid at construction time, not when calling end(), is it?

> Therefore from my perspective it would be necessary to specify and
> implement the additional trait information to avoid a performance
> regression before this suggestion could seriously be considered. A
> performance regression upon the common use-case of byte ranges is out of
> the question.

Byte is unsigned char, isn't it? Or did you mean char ranges?

>> Yes.
>> If necessary just for char[] to minimize breakage.
>>
>>
> In summary, I believe that the surprise is small and infrequently occurs.

Depends on usage, IMO. In my case, string literals are used far more
frequently than raw arrays.

> Olaf, has provided considerable useful feedback that I am acting upon. I
> don't wish this clear rejection of this specific idea to put you or anyone
> else off of providing feedback either positive or negative. However I want
> to ensure users of Boost.Range that use the library for
> performance-critical work as I do are assured that a performance regression
> will not occur.

I don't mind some discussion. ;)

> There is always the possibility that I have missed a design alternative, or
> that I have under-estimated the inconvenience of this particular use-case.
> If others have a strong view or solutions that are free of runtime
> performance degradation then I will of course consider them.

It's a shame string literals don't have a better / other type than char[].
-- 
Olaf