On Sat, Apr 21, 2012 at 10:01 PM, Neil Groves <neil@grovescomputing.com> 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