October 08, 2020
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

The only thing I read was "C++ continuous rage"
October 08, 2020
On Thu, Oct 08, 2020 at 03:55:09PM +0000, Imperatorn via Digitalmars-d wrote:
> On Thursday, 8 October 2020 at 13:30:30 UTC, Per Nordlöw wrote:
[...]
> > [1] https://en.cppreference.com/w/cpp/ranges/contiguous_range
[[...]
> The only thing I read was "C++ continuous rage"

LOL, that about describes my 15+ years of experience with C++. :-D


T

-- 
Turning your clock 15 minutes ahead won't cure lateness---you're just making time go faster!
October 08, 2020
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?

`frontArray`, a version of `front` that returned a slice of the next n elements iff there was an internal buffer already in that form? That would work with arrays, static buffers (sockets), ring buffers... Not sure if you also needed a `popFrontArray`.

I think the standard approach right now is just to define a range over slices.
October 08, 2020
On 10/8/20 11:45 AM, IGotD- wrote:
> 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).
>>
> 
> 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).

Yes. I have argued in the past (https://dlang.org/articles/d-array-article.html) that the "true" array type is hidden in the runtime, and that we should just call T[] a slice.

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

I was going to post the code for isDynamicArray, but like many things in std.traits, it's needlessly complicated.

It should just be:

enum isDynamicArray(T) = is(T == U[], U);

-Steve
October 08, 2020
On 10/8/20 12:42 PM, Steven Schveighoffer wrote:
> On 10/8/20 11:45 AM, IGotD- wrote:
>> 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).
>>>
>>
>> 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).
> 
> Yes. I have argued in the past (https://dlang.org/articles/d-array-article.html) that the "true" array type is hidden in the runtime, and that we should just call T[] a slice.
> 
>>
>> So if a type with continuous memory storage is converted to a slice, will isDynamicArray!T also be valid for the slice?
>>
> Yes.
> 
> I was going to post the code for isDynamicArray, but like many things in std.traits, it's needlessly complicated.
> 
> It should just be:
> 
> enum isDynamicArray(T) = is(T == U[], U);

enum bool isDynamicArray(T) = is(DynamicArrayTypeOf!T) && !isAggregateType!T;

Is that again about supporting enums? Sigh.


October 08, 2020
On 10/8/20 9:30 AM, 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

It occured to me we could define that traite, but we got away without it by implicitly decreeing that anything contiguous is just supposed to be a T[].

There would be a few cases where that could be useful, i.e. the result of map() over a T[]. But we'd need a strong case on why it would be useful to distinguish that from a random-access range.
October 08, 2020
On Thursday, 8 October 2020 at 17:45:30 UTC, Andrei Alexandrescu wrote:
> Is that again about supporting enums? Sigh.

There's always the possibility of adding a builtin __traits(...). ;)
October 08, 2020
On Thursday, 8 October 2020 at 17:45:30 UTC, Andrei Alexandrescu wrote:
> Is that again about supporting enums? Sigh.

BTW, what was the motivation behind all this special handling of enumerations?
October 08, 2020
On Thursday, 8 October 2020 at 19:30:08 UTC, Per Nordlöw wrote:
> BTW, what was the motivation behind all this special handling of enumerations?

Let's take that in a separate thread.
October 08, 2020
On 10/8/20 10:06 AM, Steven Schveighoffer wrote:
> 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

Is this trait true of slices pointing to user managed blocks? In particular I may use arena-allocation strategy but would love to have the type also be `isContiguousRange`