Walter wrote:

> "Pavel Minayev" <evilone@omen.ru> wrote in message
> news:CFN37426561534456@news.digitalmars.com...
> 
>>On Wed, 19 Jun 2002 09:02:43 +1000 "Matthew Wilson"
>>
> <matthew@thedjournal.com>
> 
>>wrote:
>>
>>>Seems like if we give the arrays a notion of capacity, all these
>>>sophistications (including the previously unliked ++) could be
>>>
> accomodated
> 
>>>efficiently.
>>>Any reasons against?
>>>
>>None! An additional int field to store the "actual" size of the array is
>>worth it. STL uses such approach, after all, and it proved its efficiency
>>already, why not use it in D as well? Walter?
>>
> 
> Dynamic arrays currently are represented by a register pair. Adding another
> register would put a lot of register pressure on the code generator, and I
> think it would seriously slow down code that deals a lot with
> arrays. -Walter


Depending upon the kind of code, of course.  Any complex array-manipulating code, particularly text, simply must depend heavily on ~, so this is going to be faster regardless.

The 32nd bit option looks most promising though, to indicate that this array is from the start of a GC block and is owned by this instance.

The big problem, of course, is that the GC isn't fitted for doing this and requires searching through the pools before being able to add up all the owned pages, if I interpret the code correctly.  I don't really see it being of much help here; what it can do is stuff its allocated length value in the first four bytes of any array allocation through new, so that the array resize can just pump up the length silently if it fits. The GC can also do proportional overallocation here so that really long arrays don't go crappy.

Then the code generator needs to be aware that array assignments and passing as arguments leads to a bit getting taken off, and reading the length field needs to mask off the bit, and the parts of Phobos that take apart the array needs to be fixed to mask it off.  The machine code string compare is broken right now, actually, in a subtle way that I can't reproduce easily.

Just thought of something: printf will still be usable if the 32nd bit is used to indicate ownership, since it'll be masked off when passed as an argument.  So it doesn't even affect that; good stuff.

The array part of the specification should have a section on what you can and cannot expect from a compliant implementation, keeping in mind the current method, maximum length, the 32nd bit, and any other legal contortion.  Things like:

- Appending to an array may or may not result in it being re-allocated.

    char [] a = "foo", b;

    a ~= "b";
    b = a;
    a ~= "ar";
    a [0] = "x";
    /* b [0] may be either "x" or "f". */

- The array from a slice operator will always be re-allocated if appended to.

    char [] a = "foo", b;

    b = a [0 .. 1];
    b ~= "x";
    /* a [1] is "o", b [1] is "x" */

- Assignments, passing an array as an argument, and static array initialisation act identical to a slice operation of the whole array.

    char [] a = "foo", b;

    b = a;
    b ~= "bar";
    a [0] = "x";
    /* a is "fxo", b is "foobar". */

This would be very useful for compiler writers to give us an idea of acceptable behaviour.  I see your struggling with templates more as a specification deficiency than a problem with the concept - the spec should have been clear very early on what it would require of the compiler.  Every language I've written a compiler for has been deficient in this respect, resulting in a lot of later code manipulation to get it to do something I was never expecting.  A great big "Compiling D" page of the specification would be much appreciated.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D2A9D45.8010804@users.sourceforge.net...
> This would be very useful for compiler writers to give us an idea of acceptable behaviour.  I see your struggling with templates more as a specification deficiency than a problem with the concept - the spec should have been clear very early on what it would require of the compiler.  Every language I've written a compiler for has been deficient in this respect, resulting in a lot of later code manipulation to get it to do something I was never expecting.  A great big "Compiling D" page of the specification would be much appreciated.

You're right. I've been intending to add "implementation notes" sprinkled in the spec that won't form part of the spec, but will be useful to implementors.