Thread overview | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
February 16, 2018 New abstraction: Layout | ||||
---|---|---|---|---|
| ||||
I've been long bothered that the builtin .tupleof and our own abstractions Fields and RepresentationTypeTuple in std.traits - all omit the essential information of field offsets. That makes types that use align() to have the same .tupleof, Fields, and RepresentationTypeTuple even though they shouldn't. The right answer is Layout a tuple of (offset, type) pairs describing entirely the memory layout of a type. We need such for memory allocation, garbage collection, serialization, and more. The implementation turned out to be quite compact - 81 lines including a compile-time mergesort. Destroy! https://github.com/dlang/phobos/pull/6192 Andrei |
February 17, 2018 Re: New abstraction: Layout | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 17/02/2018 12:04 AM, Andrei Alexandrescu wrote:
> I've been long bothered that the builtin .tupleof and our own abstractions Fields and RepresentationTypeTuple in std.traits - all omit the essential information of field offsets. That makes types that use align() to have the same .tupleof, Fields, and RepresentationTypeTuple even though they shouldn't.
>
> The right answer is Layout a tuple of (offset, type) pairs describing entirely the memory layout of a type. We need such for memory allocation, garbage collection, serialization, and more.
>
> The implementation turned out to be quite compact - 81 lines including a compile-time mergesort. Destroy!
>
> https://github.com/dlang/phobos/pull/6192
>
>
> Andrei
Could use the name for the field as well. At the minimum useful for debugging purposes.
|
February 17, 2018 Re: New abstraction: Layout | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Saturday, 17 February 2018 at 00:04:16 UTC, Andrei Alexandrescu wrote:
> The implementation turned out to be quite compact - 81 lines including a compile-time mergesort. Destroy!
Off-topic:
I've just realized Andrei puts "Destroy!" at the end of his messages because it's the end of scope and he wants to free any allocated resources. ;)
|
February 17, 2018 Re: New abstraction: Layout | ||||
---|---|---|---|---|
| ||||
Posted in reply to rikki cattermole | On 02/16/2018 10:10 PM, rikki cattermole wrote:
> On 17/02/2018 12:04 AM, Andrei Alexandrescu wrote:
>> I've been long bothered that the builtin .tupleof and our own abstractions Fields and RepresentationTypeTuple in std.traits - all omit the essential information of field offsets. That makes types that use align() to have the same .tupleof, Fields, and RepresentationTypeTuple even though they shouldn't.
>>
>> The right answer is Layout a tuple of (offset, type) pairs describing entirely the memory layout of a type. We need such for memory allocation, garbage collection, serialization, and more.
>>
>> The implementation turned out to be quite compact - 81 lines including a compile-time mergesort. Destroy!
>>
>> https://github.com/dlang/phobos/pull/6192
>>
>>
>> Andrei
>
> Could use the name for the field as well. At the minimum useful for debugging purposes.
That would be tricky because fields are decomposed down to primitive types. -- Andrei
|
February 17, 2018 Re: New abstraction: Layout | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 2/16/18 7:04 PM, Andrei Alexandrescu wrote: > I've been long bothered that the builtin .tupleof and our own abstractions Fields and RepresentationTypeTuple in std.traits - all omit the essential information of field offsets. That makes types that use align() to have the same .tupleof, Fields, and RepresentationTypeTuple even though they shouldn't. > > The right answer is Layout a tuple of (offset, type) pairs describing entirely the memory layout of a type. We need such for memory allocation, garbage collection, serialization, and more. > > The implementation turned out to be quite compact - 81 lines including a compile-time mergesort. Destroy! > > https://github.com/dlang/phobos/pull/6192 Can't you just use offsetof? struct S { ubyte x; int y; } static foreach(i; 0 .. s.tupleof.length) { writeln(s.tupleof[i].offsetof); } outputs: 0 4 -Steve |
February 17, 2018 Re: New abstraction: Layout | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On 2/17/18 8:19 AM, Steven Schveighoffer wrote:
> On 2/16/18 7:04 PM, Andrei Alexandrescu wrote:
>> I've been long bothered that the builtin .tupleof and our own abstractions Fields and RepresentationTypeTuple in std.traits - all omit the essential information of field offsets. That makes types that use align() to have the same .tupleof, Fields, and RepresentationTypeTuple even though they shouldn't.
>>
>> The right answer is Layout a tuple of (offset, type) pairs describing entirely the memory layout of a type. We need such for memory allocation, garbage collection, serialization, and more.
>>
>> The implementation turned out to be quite compact - 81 lines including a compile-time mergesort. Destroy!
>>
>> https://github.com/dlang/phobos/pull/6192
>
> Can't you just use offsetof?
>
> struct S
> {
> ubyte x;
> int y;
> }
>
> static foreach(i; 0 .. s.tupleof.length)
> {
> writeln(s.tupleof[i].offsetof);
> }
>
> outputs:
> 0
> 4
I found this also works:
static foreach(alias x; S.tupleof)
{
writeln(x.offsetof);
}
-Steve
|
February 17, 2018 Re: New abstraction: Layout | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On 02/17/2018 09:03 AM, Steven Schveighoffer wrote:
> On 2/17/18 8:19 AM, Steven Schveighoffer wrote:
>> On 2/16/18 7:04 PM, Andrei Alexandrescu wrote:
>>> I've been long bothered that the builtin .tupleof and our own abstractions Fields and RepresentationTypeTuple in std.traits - all omit the essential information of field offsets. That makes types that use align() to have the same .tupleof, Fields, and RepresentationTypeTuple even though they shouldn't.
>>>
>>> The right answer is Layout a tuple of (offset, type) pairs describing entirely the memory layout of a type. We need such for memory allocation, garbage collection, serialization, and more.
>>>
>>> The implementation turned out to be quite compact - 81 lines including a compile-time mergesort. Destroy!
>>>
>>> https://github.com/dlang/phobos/pull/6192
>>
>> Can't you just use offsetof?
>>
>> struct S
>> {
>> ubyte x;
>> int y;
>> }
>>
>> static foreach(i; 0 .. s.tupleof.length)
>> {
>> writeln(s.tupleof[i].offsetof);
>> }
>>
>> outputs:
>> 0
>> 4
>
> I found this also works:
>
> static foreach(alias x; S.tupleof)
> {
> writeln(x.offsetof);
> }
Yes, the implementation uses offsetof. -- Andrei
|
February 17, 2018 Re: New abstraction: Layout | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 2/17/18 9:59 AM, Andrei Alexandrescu wrote:
> On 02/17/2018 09:03 AM, Steven Schveighoffer wrote:
>> I found this also works:
>>
>> static foreach(alias x; S.tupleof)
>> {
>> writeln(x.offsetof);
>> }
>
> Yes, the implementation uses offsetof.
>
I guess I'm just confused based on the statement "the builtin .tupleof ... [omits] the essential information of field offsets."
What is this construct giving us that .tupleof doesn't?
-Steve
|
February 18, 2018 Re: New abstraction: Layout | ||||
---|---|---|---|---|
| ||||
Posted in reply to thedeemon | On Saturday, 17 February 2018 at 09:30:23 UTC, thedeemon wrote:
> On Saturday, 17 February 2018 at 00:04:16 UTC, Andrei Alexandrescu wrote:
>> The implementation turned out to be quite compact - 81 lines including a compile-time mergesort. Destroy!
>
> Off-topic:
> I've just realized Andrei puts "Destroy!" at the end of his messages because it's the end of scope and he wants to free any allocated resources. ;)
We're talking about Andrei here, so it's far more likely 'destroy' is an efficient, compact, generic term, that can take on many different meanings - depending on the context in which it used.
'D'estroy!
|
February 18, 2018 Re: New abstraction: Layout | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Saturday, 17 February 2018 at 19:37:12 UTC, Steven Schveighoffer wrote: > On 2/17/18 9:59 AM, Andrei Alexandrescu wrote: >> On 02/17/2018 09:03 AM, Steven Schveighoffer wrote: >>> I found this also works: >>> >>> static foreach(alias x; S.tupleof) >>> { >>> writeln(x.offsetof); >>> } >> >> Yes, the implementation uses offsetof. >> > > I guess I'm just confused based on the statement "the builtin .tupleof ... [omits] the essential information of field offsets." > > What is this construct giving us that .tupleof doesn't? > I guess the construct captures offsets as part of type. This is useful for allocators + 2 things with same Layout can be bitblitted to each other. > -Steve |
Copyright © 1999-2021 by the D Language Foundation