Jump to page: 1 25  
Page
Thread overview
October 08
C++20 defines

- std::ranges::contiguous_range [1] on top of
- std::random_access_iterator [2]

as specializations of

- std::ranges::random_access_range on top of
- std::random_access_iterator

. A contiguous ranges has all its elements stored continuously (adjacently) in memory.

Does anybody know the application for this concept/predicate?

[1] https://en.cppreference.com/w/cpp/ranges/contiguous_range
[2] https://en.cppreference.com/w/cpp/iterator/contiguous_iterator
October 08
On Thursday, 8 October 2020 at 13:30:30 UTC, Per Nordlöw wrote:
> C++20 defines
>
> - std::ranges::contiguous_range [1] on top of
> - std::random_access_iterator [2]
>
> as specializations of
>
> - std::ranges::random_access_range on top of
> - std::random_access_iterator
>
> . A contiguous ranges has all its elements stored continuously (adjacently) in memory.
>
> Does anybody know the application for this concept/predicate?
>
> [1] https://en.cppreference.com/w/cpp/ranges/contiguous_range
> [2] https://en.cppreference.com/w/cpp/iterator/contiguous_iterator

Optimizations that require linear memory access, like SIMD. I believe.
October 08
On Thursday, 8 October 2020 at 13:43:01 UTC, Ola Fosheim Grøstad wrote:
> Optimizations that require linear memory access, like SIMD. I believe.

How could `isContiguousRange` be defined in D?
October 08
On Thursday, 8 October 2020 at 13:59:09 UTC, Per Nordlöw wrote:
> On Thursday, 8 October 2020 at 13:43:01 UTC, Ola Fosheim Grøstad wrote:
>> Optimizations that require linear memory access, like SIMD. I believe.
>
> How could `isContiguousRange` be defined in D?

It would probably require a new range interface where front and popFront produce slices instead of elements.

October 08
On 10/8/20 9:59 AM, Per Nordlöw wrote:
> On Thursday, 8 October 2020 at 13:43:01 UTC, Ola Fosheim Grøstad wrote:
>> Optimizations that require linear memory access, like SIMD. I believe.
> 
> How could `isContiguousRange` be defined in D?

isDynamicArray!T

-Steve
October 08
On Thursday, 8 October 2020 at 14:06:18 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 8 October 2020 at 13:59:09 UTC, Per Nordlöw wrote:
>> On Thursday, 8 October 2020 at 13:43:01 UTC, Ola Fosheim Grøstad wrote:
>>> Optimizations that require linear memory access, like SIMD. I believe.
>>
>> How could `isContiguousRange` be defined in D?
>
> It would probably require a new range interface where front and popFront produce slices instead of elements.

Or a method slice() that return the container as a slice? In c++ containers have data and length, so I guess that is an option too.

But it would be more generic to have a front that it is a slice. Would work for btrees, deques etc.
October 08
On Thursday, 8 October 2020 at 14:18:45 UTC, Ola Fosheim Grøstad wrote:
> Or a method slice() that return the container as a slice? In c++ containers have data and length, so I guess that is an option too.

To elaborate, c++ containers have a member data() that points to the beginning of the contiguous buffer and a member size() that indicates the number of elements. D has a way to indicate length, but I don't think there is any commonly used data() equivalent? Although one probably could define a freestanding function that can be overloaded? Then you could just test with the compiles trait.

October 08
On 10/8/20 10:34 AM, Ola Fosheim Grøstad wrote:
> On Thursday, 8 October 2020 at 14:18:45 UTC, Ola Fosheim Grøstad wrote:
>> Or a method slice() that return the container as a slice? In c++ containers have data and length, so I guess that is an option too.
> 
> To elaborate, c++ containers have a member data() that points to the beginning of the contiguous buffer and a member size() that indicates the number of elements. D has a way to indicate length, but I don't think there is any commonly used data() equivalent? Although one probably could define a freestanding function that can be overloaded? Then you could just test with the compiles trait.
> 

We have arrays in D, there is no need to duplicate what C++ does because they don't have a real array type.

In D, you would check if the range is a dynamic array, and then use ptr/length to deal with optimizations (I do this in iopipe).

-Steve
October 08
On Thursday, 8 October 2020 at 14:45:47 UTC, Steven Schveighoffer wrote:
> We have arrays in D, there is no need to duplicate what C++ does because they don't have a real array type.

std::array and std::vector are array types, but the concept of being contiguous applies to all containers, also third party.

> In D, you would check if the range is a dynamic array, and then use ptr/length to deal with optimizations (I do this in iopipe).

ok, if all custom containers with a linear buffer provides the same pointer interface then that would work like data().

But I think the c++ solution is too weak. It does not work with deques, btrees etc... :-/



October 08
On Thursday, 8 October 2020 at 14:45:47 UTC, Steven Schveighoffer wrote:
>
> We have arrays in D, there is no need to duplicate what C++ does because they don't have a real array type.
>
> In D, you would check if the range is a dynamic array, and then use ptr/length to deal with optimizations (I do this in iopipe).
>
> -Steve

Just clarify, you mean that anything that is continuous memory can be converted to a slice (as supposed to an array, even if the relationship is somewhat ambiguous is D).

So if a type with continuous memory storage is converted to a slice, will isDynamicArray!T also be valid for the slice?

« First   ‹ Prev
1 2 3 4 5