On 2011-10-04 17:14, Robert Jacques wrote:
I'm sorry, you're right. In my mind b extended to the end of the a
array, for some reason. However, if you do define b to extend to the end
of the a array, then it can append without allocating:
auto a = [0, 1, 2, 3, 4];
auto b = a[2 .. $];
b ~= 5;
assert(b[0]==2);
a[2] = 10;
assert(b[0]==10);
So please don't dismiss this point.
Hmm, D1 and D2 behaves differently in this case. In D1 "a" is not
changed when "b" is changed. Since you append to "b" I though that it
would always require a reallocation of "b".
[snip]
Would this something similar to:
https://github.com/jacob-carlborg/orange/blob/master/orange/serialization/Serializer.d#L1520
?
I'm not sure, that routine seems to be filtering pointers between those
with aliases and those without aliases, which would be similar in effect
to:
if( auto node = arr.ptr in setOfAliases ) {} else {}
What is the advantage with using a tree? Is the advantage that you loop
over the elements once in the pseudo-code compared to that I loop over
them twice, as in:
https://github.com/jacob-carlborg/orange/blob/master/orange/serialization/Serializer.d#L1495
?
Primarily, it's O(N logN) vs O(N^2). Also, it solves the isSliceOf
problem we discussed above and puts arrays and objects into the same
framework, as objects containing fixed sized arrays can have slices.
I guess I just have to try this and see how it works out. Anyway, thank
you for your review and your patience.
--
/Jacob Carlborg
