Testing array ptr for offset 0...
ag0aep6g via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Thu May 26 15:15:42 PDT 2016
On 05/26/2016 11:13 PM, Era Scarecrow wrote:
> By adding a struct overload for opOpAssign I can shrink it all down
> to this, and avoid lengths entirely... As such internally the length
> starts at 0, and checks are in place to ensure the bounds are never
> exceeded.
>
> void scan(ref Data[][] data, Condition cond) {
> foreach(i; ...) {
> if (cond)
> data[i] ~= ...
> }
> }
Sorry, I'm still lost. Why can't you do whatever you're doing in
opOpAssign directly there, or in a free function? Does the pseudo-array
contain any additional data? Would a wrapper around a built-in array not
work?
[...]
> The answer is wrong _because_ the code blows up. I inverted the check
> to check if length is at offset 0 since (the length can only be 1 and a
> better test), however it _still_ gives the wrong answer. Curiously CTFE
> is fine with this casting as long as the pointer stays in that one spot.
Oh, I see. Yeah, the answer is garbage. Seeing the spec section that
Adam D. Ruppe linked, the length field actually comes first.
That CTFE errors out when you move the pointer to a variable screams
that something is wrong. The code seems to be seriously misinterpreted
in CTFE.
----
enum x = () {
size_t[] arr = [13];
return *(cast(size_t*) &arr);
} ();
pragma(msg, x);
----
That prints "13LU". Apparently &arr is mistaken for arr here.
I've filed an issue:
https://issues.dlang.org/show_bug.cgi?id=16081
More information about the Digitalmars-d-learn
mailing list