I was updating some code and noticed string_view isn't constructible from (string_view) iterators. What's the reason for this?IMO it should be constructible from string_view iterators and perhaps even from other contiguous char iterators.
On Wed, Mar 29, 2017 at 12:26 AM, Olaf van der Spek <olafv...@gmail.com> wrote:I was updating some code and noticed string_view isn't constructible from (string_view) iterators. What's the reason for this?IMO it should be constructible from string_view iterators and perhaps even from other contiguous char iterators.The "contiguous iterator" property is a run-time property of the iterator pair, and as such not checkable at compile time.
So string_view would have to have a constructor that took either (a) a pair of string_view iterators, or (b) a pair of iterators.The first is easy to emulate with the (ptr, len) constructor.string_view (&*first, std::distance(first, last));
On Tuesday, August 8, 2017 at 12:20:07 PM UTC-4, Marshall wrote:On Wed, Mar 29, 2017 at 12:26 AM, Olaf van der Spek <olafv...@gmail.com> wrote:I was updating some code and noticed string_view isn't constructible from (string_view) iterators. What's the reason for this?IMO it should be constructible from string_view iterators and perhaps even from other contiguous char iterators.The "contiguous iterator" property is a run-time property of the iterator pair, and as such not checkable at compile time.
Well maybe that's something we ought to fix.
And no, whether an iterator is contiguous is not a runtime property of the data; it's a compile-time property of the iterator type. It's just not one we have a way to detect.
We have the concept of contiguous iterators, and we have definitions of iterator types that are contiguous. But we do not have a way to actually detect the difference between random access and contiguous iterators in C++.
So string_view would have to have a constructor that took either (a) a pair of string_view iterators, or (b) a pair of iterators.The first is easy to emulate with the (ptr, len) constructor.string_view (&*first, std::distance(first, last));
Because God knows that's something that everyone should learn to write.
On Tuesday, August 8, 2017 at 12:20:07 PM UTC-4, Marshall wrote:On Wed, Mar 29, 2017 at 12:26 AM, Olaf van der Spek <olafv...@gmail.com> wrote:I was updating some code and noticed string_view isn't constructible from (string_view) iterators. What's the reason for this?IMO it should be constructible from string_view iterators and perhaps even from other contiguous char iterators.The "contiguous iterator" property is a run-time property of the iterator pair, and as such not checkable at compile time.
Well maybe that's something we ought to fix.
On Tue, Aug 8, 2017 at 9:50 AM, Nicol Bolas <jmck...@gmail.com> wrote:On Tuesday, August 8, 2017 at 12:20:07 PM UTC-4, Marshall wrote:On Wed, Mar 29, 2017 at 12:26 AM, Olaf van der Spek <olafv...@gmail.com> wrote:I was updating some code and noticed string_view isn't constructible from (string_view) iterators. What's the reason for this?IMO it should be constructible from string_view iterators and perhaps even from other contiguous char iterators.The "contiguous iterator" property is a run-time property of the iterator pair, and as such not checkable at compile time.
Well maybe that's something we ought to fix.
And no, whether an iterator is contiguous is not a runtime property of the data; it's a compile-time property of the iterator type. It's just not one we have a way to detect.I disagree.Let's actually read what the standard says, and then look at examples.[iterator.requirements.general]/5 says:Iterators that further satisfy the requirement that, for integral values n and dereferenceable iterator values a and (a + n), *(a + n) is equivalent to *(addressof(*a) + n), are called contiguous iterators.
I therefore submit that your interpretation, that contiguousness is a runtime property rather than a static property) is not what the feature was intended to be. And if your interpretation really is what the standard says, then the standard should be corrected.
On Tue, Aug 8, 2017 at 1:28 PM, Nicol Bolas <jmck...@gmail.com> wrote:I therefore submit that your interpretation, that contiguousness is a runtime property rather than a static property) is not what the feature was intended to be. And if your interpretation really is what the standard says, then the standard should be corrected.Asking if a range is contiguous is a run-time query. Asking if a given type models a contiguous iterator is a compile-time property. These are not in conflict with each other.
A raw pointer models a contiguous iterator, yet an arbitrary pair of pointers is not necessarily a contiguous range.
IMO, once we have such a trait, string_view should be extended to construct from a pair of contiguous iterators.
On 08/08/17 22:37, Olaf van derI think the case in point is deque. In general, a deque (or a range adopting deque::iterators) is not contiguous. However, there can be a pair of iterators that denote a contiguous range within the deque.
IMHO this case probably requires some sort of support from the container. The user at least needs to be able to discover in runtime if two iterators denote a contiguous range and then convert the iterators to local_iterators, which have different type and are statically known to be contiguous (i.e. are basically guaranteed to refer to the same segment of the deque).
On Tue, Aug 8, 2017 at 4:21 PM, Andrey Semashev <andrey....@gmail.com> wrote:On 08/08/17 22:37, Olaf van derI think the case in point is deque. In general, a deque (or a range adopting deque::iterators) is not contiguous. However, there can be a pair of iterators that denote a contiguous range within the deque.
IMHO this case probably requires some sort of support from the container. The user at least needs to be able to discover in runtime if two iterators denote a contiguous range and then convert the iterators to local_iterators, which have different type and are statically known to be contiguous (i.e. are basically guaranteed to refer to the same segment of the deque).IMHO this is not a use case I care about.