On Fri, Sep 06, 2013 at 02:59:30AM +0200, Ramon wrote:
> On Thursday, 5 September 2013 at 23:58:06 UTC, H. S. Teoh wrote:
>
> Thanks and
>
> >@Iain: on that note, it looks like gdb thinks it's debugging C++, but
> >D doesn't have anything called 'operator[]'. It would be Really Nice
> >if we could somehow coax gdb to use opIndex instead (though it
> >doesn't really help in the case of dyn arrays 'cos they are built-in,
> >and don't actually have any opIndex to speak of).
>
> I'm not so sure.
>
> Observation:
>
> >print someDynArray.length
> 10 // works
>
> char[5] cArray = "Hello"; // Let's try C like fixed length
> array
>
> >print cArray[3]
> 'l' // works
>
> I'm not that sure dyn arrays have no [] (or index or whatever it's
> called) operator. In the end they are just arrays with smart
> housekeeping behind the curtains and some methods (like "length").
[...]
Actually, D arrays are implemented something like this:
/* C code equivalent */
struct int_array {
int *ptr;
size_t length;
}
So if you do something like 'print someDynArray.ptr[4]' it should work.
Now obviously gdb does support more abstract array-like types, like C++
types that define operator[], so I was just saying that it would be nice
if we could figure out what to put in the debug data segment to make gdb
translate arr[i] in D into arr.ptr[i].
Static arrays in D are closer to C's stack-allocated arrays (e.g. if you
declare 'char localVar[10];' inside a function), so they more-or-less
work seamlessly with C array indexing notation.
T
--
I think Debian's doing something wrong, `apt-get install pesticide', doesn't
seem to remove the bugs on my system! -- Mike Dresser
