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.
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