Re: [boost] Iterator Range and operator==

Subject: Re: [boost] Iterator Range and operator==
From: Olaf van der Spek (ml_at_[hidden])
Date: 2012-05-08 08:02:28

On Sat, Apr 21, 2012 at 10:32 PM, Olaf van der Spek <ml_at_[hidden]> wrote:
> 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[].

Neil?

-- 
Olaf