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