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. 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.
Until the language gives us a way to distinguish string literals from other arbitrary arrays of char, it's the best we can do. The alternative is to have generic code suddenly stop working when T==char.
What about requiring the use of as_array or as_literal in all cases?
You mean, so that raw built-in arrays would cease to be ranges at all? I guess that's a possiblity. Nobody thought about that, IIRC.
I did consider doing this with the RangeEx upgrade. I rejected the idea on the basis that the as_array idiom did not always fully optimize away on lesser compilers and the syntactic mess was unpleasant. I appreciate that many believe that native arrays should not appear in modern C++ code, but the guarantee that the array produces a pointer type from begin() and end() can be used to provide optimal implementations for contiguous pointer ranges. Without the further development of Concepts, or numerous specializations for concrete array types the use of native arrays is extremely useful in high performance protocol handling code. 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.
Yes. If necessary just for char[] to minimize breakage.
In summary, I believe that the surprise is small and infrequently occurs. There are however a large number of people using many char arrays with Boost.Range. The surprise when using the library in a manner that is documented as unsupported is insufficiently important when contrasted with the impact it would have on valid code.
-- Olaf
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. 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. Neil Groves