On Mon, 19 Sep 2011 10:08:32 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 9/19/11 6:25 AM, Steven Schveighoffer wrote:
On Sun, 18 Sep 2011 15:34:16 -0400, Timon Gehr <timon.g...@gmx.ch>
wrote:
On 09/18/2011 08:28 PM, Andrei Alexandrescu wrote:
That would allow us to e.g. switch from the
pointer+length representation to the arguably better pointer+pointer
representation with ease.
In what way is that representation better?
I agree, I don't see why the representation is inherently better. Some
operations become higher performance (i.e. popFront), and some become
worse (i.e. length). Most of the others are a wash.
That's where frequency of use comes into play. I'm thinking popFront
would be used most often, and it touches two words.
I'm not so sure. It's very difficult to prove this is the case (either
way).
Already foreach does not use the range primitives for arrays, which is
probably the most frequent user of popFront (for ranges other than arrays
of course).
However, length is used frequently in slicing, or passing to underlying C
or OS functions which require ptr + length. Maybe the compiler can
optimize out the calculations of length when they are just getting
translated right back to pointers. For example a = a[1..$] shouldn't have
to calculate a.length, it should just be a.ptr += 5. I also think it
would be nice to have direct access to the end pointer. Likewise,
a.length -= 5 shouldn't have to calculate the original length, then
subtract 5, then pass that to the setlength function.
I'm not sure if the runtime code would be better or worse if we used 2
pointers instead of ptr/length. for sure that is where the bulk of the
changes would need to be made.
The other thing that I don't like is it's much easier to construct an
invalid slice with 2 pointers than it is with a ptr/length.
I suspect my opinion doesn't matter much for what we all "think" is used
more frequently, but there are bigger issues to solve before we could have
a library-based array type. It might be best to leave the array as a
magic type, but just change the internal representation in the
compiler/runtime.
I know that printf was abused at some point for writing slices by relying
on the fact that the order of length/ptr happened to be the same when you
specified the length of a string as a parameter to printf, this would
definitely break any code that relies on that. Not that we need to care,
but it's something to think about.
And actually, false pointers would be cut down (both pointers always point
to the referenced block), which might be worth all the trouble anyways :)
-Steve
