On Thursday, 26 May 2016 at 22:15:42 UTC, ag0aep6g wrote:
On 05/26/2016 11:13 PM, Era Scarecrow wrote:
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?
Well a few things at work. First the array is originally a
static array, so I pass it as a slice; But if you pass it as a
slice you get the entire length, and modifying the length
requires either changing length or appending, both which may
cause allocation (something I want to avoid). By making my own
compatible structure I can manage the length and pointer directly
and precisely.
Second I would prefer the length to start at 0 and grow UP TO
the size of the static array. If it was just a single array this
wouldn't be an issue, but I'm working with a couple hundred of
these. Plus I don't want to add more data to the memory or
structure than necessary to treat it as an array after the fact.
I shouldn't have to.
Truthfully the same result can be done with shrinking it
afterwards, but I was trying to see if I could make it any faster
by managing the pointer and length directly and avoiding the
large temporaries. So far any speed gains are so minimal it's
worth dropping.
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.
I've filed an issue:
https://issues.dlang.org/show_bug.cgi?id=16081
Glad I found a bug! :) And all because [].ptr.offsetof wasn't an
option...
I just wanted to guarantee it was the correct order (in case it
gets changed in the future). But ultimately it isn't worth
pursuing.
