On Fri, 20 Nov 2009 04:13:42 +0300, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Leandro Lucarella wrote:
dsimcha, el 19 de noviembre a las 23:21 me escribiste:
Face it, D is a close to the metal language. Any attempt to define
the spec at a
purely abstract level without reference to any implementation details,
and without
leaving certain details implementation defined is absurd. I think
people need to
face the fact that you can't have close-to-the-metal flexibility and
performance
and at the same time far-from-the-metal strict separation of
specification from
implementation details.
Yes, but I think this is a place where you are doing early
optimization at
the expense of usability. You can always do the slice-thinguie yourself
if
you are that needed for speed that you can't afford an extra indirection
when using an array (which will be the only overhead if T[new] were
implemented as a pure reference type).
I think the cost here in terms of usability if far higher than the
little
performance you loose, specially when you can overcome the issue for
those
weird cases where you need it.
I think one aspect that tends to be forgotten is that built-in arrays
are the lowest abstraction - really just one small step above pointers.
Efficiency lost there is lost forever. That's why I consider the current
design adequate and the proposed designs less so.
In other words: you can build a more convenient facility on top of T[],
but you couldn't build a more efficient facility on top of a convenient
one. I think D made the right choice with built-in arrays.
Andrei
Not so true. T[] appends are slow, *very* slow. Whenever I need anything
efficient, I always use an additional "size" field (and arr.length is used
as capacity). This is tricky, error-prone and not too intuitive to
newcomers. As such, it contradicts with all your statements above.
And there is also a hack to make it work a bit faster:
T[] arr;
arr.length = capacity
arr.length = 0;
Much to my disgust, having no higher-level abstraction in language core
only encourages writing code like this.
TBH, I used to write code like above before, too, but not now. I slowly
eliminate everything like this (as well as all the ~= operations) from the
code I wrote. It's unpredictable, slow, and leads to hard-to-fix bugs.
In other words, I disagree with your opinion that D made a right choice
with built-in pseudo-arrays.
