On Saturday, 16 March 2013 at 21:49:33 UTC, Vladimir Panteleev
wrote:
On Saturday, 16 March 2013 at 21:42:31 UTC, Igor Stepanov wrote:
On Saturday, 16 March 2013 at 21:21:51 UTC, Vladimir Panteleev
wrote:
On Saturday, 16 March 2013 at 21:15:32 UTC, Igor Stepanov
wrote:
What do the lines el_combine? I do not see them in the code
structure comparison.
Greetings Igor,
The el_combine calls are supposed to ensure correct order of
evaluation.
I based that code from this fragment:
https://github.com/D-Programming-Language/dmd/blob/635c6b07/src/e2ir.c#L2702
Visually, it should work :)
I would try to make sure that the various components of
expression are correctly calculated. In particular, I am
concerned the calculation of the length of a dynamic array.
You can try to do so, that would return the length of the
entire expression.
/ ***** In DMD ***** /
if (t1->ty == Tarray)
{
retrun el_una(I64 ? OP128_64 : OP64_32, TYsize_t,
el_same(&earr1));
}
/ ***** In D ***** /
int[] arr = [1,2,3];
int[] arr3 = [1,2,3,4,5];
size_t len = cast(size_t)(arr == arr3);
assert(len == arr.length);
Dynamic arrays work perfectly, it's the static ones I'm having
trouble with... particularly, when they're being returned from
a function.
From what I can tell, the situation is that I can neither copy
them using el_same (it neither makes sense, as the arrays can
be large, nor does the compiler let me to), nor can I take
their address, because the code generator fails to process an
OPaddr elem when its child is a function call. However, the
same thing seems to work when calling the runtime function for
array equality (the current implementation)...
Probably a stupid question, but why do you want to use el_same?
As I understand it, el_same creates a copy. Why not use the
original, if we know that it will not change anything.
