Re: [boost] Iterator Range and operator==

Subject: Re: [boost] Iterator Range and operator==
From: Neil Groves (neil_at_[hidden])
Date: 2012-04-21 16:01:06

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