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?
>>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk