On 6 September 2013 08:34, Ramon <s...@thanks.no> wrote:
> On Friday, 6 September 2013 at 07:02:56 UTC, Iain Buclaw wrote:
>>
>>
>> Dynamic arrays are just structs with a length and ptr field. So when
>> you invoke '.length' in the debugger you aren't calling a method, you
>> are just retrieving the type's field value.
>>
>> Currently, the only fancy thing the gdb does with D arrays is that it
>> pretty prints them. So take for example you have:
>>
>> { .length = 5, .ptr = "Hello" };
>>
>>
>> Rather than printing the dynamic array like the above, it does a
>> printf("%*.s") style operation to print the contents of .ptr, but only
>> as far as .length. This is important because dynamic arrays are not
>> expected to be '0' terminated, and you can slice a dynamic array into
>> smaller arrays without copying data.
>>
>>
>> Having the ability to slice D arrays using [] in gdb is something on
>> my todo list when I get round to improving gdb for D.
>
>
> Thanks for the explanation, Iain.
>
> But: Doesn't that mean that myArray[] is just syntactic sugar for
> myArray.ptr[i]? And if so wouldn't it make sense to fool gdb, too, to accept
> print myArray[4] instead of myArray.ptr[4]?
>
Yes, myArray[] is just syntactical sugar. What the compiler code
generates is myArray.ptr[i].
gdb will always accept myArray.ptr[4] because arrays are just structs.
As I said, [] is something on my todo list.
> Funnily btw. "p myArray" prints out the whole array, yet asking it to print
> out myArray[3] fails as described.
>
As I said in my previous message, this is the only thing that gdb does
fancy with D arrays at this moment. If you wrote the equivalent code
in C and called 'p myArray' in the debugger you'd get:
{ .length = 5, .ptr = "Hello12maybesomegarbageontheend" }
Regards
--
Iain Buclaw
*(p < e ? p++ : p) = (c & 0x0f) + '0';
