S wrote:
On 2009-12-15 10:21:04 -0800, Andrei Alexandrescu
<[email protected]> said:
retard wrote:
Tue, 15 Dec 2009 09:42:26 -0500, Steven Schveighoffer wrote:
On Tue, 15 Dec 2009 02:25:11 -0500, S <[email protected]> wrote:
Excuse me, because I haven't been active in the D community the last
year due to school concerns. However, I have been fiddling with the
language and on this newsgroups since 2001.
As I understand it, dynamic arrays are going away soon in D2.0 in
favor of an ArrayBuilder class.
I don't like it at all. I want to stomp my feet and throw a temper
tantrum. As far as I am concerned, T[] has always been an
array-builder. Now, I'd appreciate some considering, and that you'll
excuse my poor phrasing when it comes to terminology (I am not a
trained computer scientist).
It's not going away. The plan as I understand it(*) is to fix dynamic
array stomping problems, and make thread-local dynamic arrays append
efficiently without using the GC lock where possible.
-Steve
(*) I am not Walter Bright/Andrei Alexandrescu and so I do not have any
final word on what makes it into D2 or not, these are just speculations
from communications I've been involved in.
Most likely Walter won't even tell what kind of arrays D2 will have.
Anything can happen. The final word is the undocumented executable
you can download when the book hits stores.
That's a bit of an oxymoron isn't it :o). The book _is_ the
documentation, and the chapter dedicated to arrays has been public for
a while.
http://erdani.com/d/thermopylae.pdf
Andrei
Alright Andrei,
I respect your expertise. I'm going to go read this chapter and then
give you a piece of my mind.
Thank you, but I think you are overrating my expertise. I can't claim I
am a programming language designer.
But I will say this -- I hope the solutoin is good :) Pretty much all
the arrays in D are messed up, and have been that way for the last 10
years since they "sort of behave" like Python, and "sort of behave" like C.
This code is listed as nonfunctioning:
int[] a = [0, 10, 20, 30, 40, 50, 60, 70];
auto b = a[4 .. $];
a=a[0..4]; // At this point a and b are adjacent
a ~= [0, 0, 0, 0];
assert(b == [40, 50, 60, 70]); // passes; a got reallocated
But how is it ever supposed to work. Does the GC look at more than
start block addresses?
There was a long thread regarding this matter, entitled "LRU cache for
~=". You may want to look it up. The thread title is due to me and has a
mistake, it should have been "MRU" = most recently used. "LRU" is the
negation of that, reflecting the eviction policy (least recently used
entry is evicted).
Andrei
