Need for (C++20) Contiguous Range
Steven Schveighoffer
schveiguy at gmail.com
Fri Oct 9 13:31:18 UTC 2020
On 10/9/20 5:52 AM, Ola Fosheim Grøstad wrote:
> On Thursday, 8 October 2020 at 16:42:51 UTC, Steven Schveighoffer wrote:
>> It should just be:
>>
>> enum isDynamicArray(T) = is(T == U[], U);
>
> So if I create my owner container that has an opCast overload to a slice
> of the underlying buffer, would isDynamicArray be true for my container?
No.
>
> If not you need a new test.
>
No, just use a cast to an array (if that's what you implemented).
We are talking about a range that is also contiguous in memory. The only
logical reason to require this is to get a ptr and a length and use the
CPU specialized instructions for these things. We have that type
pattern, it's a slice. C++ didn't have that formally defined, so they
needed to add something.
When I developed iopipe, I made the declaration that the buffer window
shall be a random-access range. I thought of the future, where people
might find new cool ways to use buffers that weren't arrays.
And when I got to thinking about the performance of such buffers (like,
let's say a ring buffer that has 2 slices over the same underlying
buffer, so you never have to copy), the cost of *indexing* is going to
overwhelm the benefit of not having to copy. I even implemented a
ringbuffer using memory map tricks, and it's not any better than a
straight array.
So even though I still define the buffer window as having to be a random
access range, all current buffer types are arrays (that may change if I
ever get around to implementing an inter-thread iopipe).
Contiguous memory has the properties that allow the CPU to shine, and
the way to say "I have contiguous memory" in D is: use a slice.
-Steve
More information about the Digitalmars-d
mailing list