std.stringbuffer

[Me Here]

Janice Caron wrote:


>
>The name can be anything we want it to be.
>...
>Except "std.string.anything" :-)

I did laugh. Not quite "any colour you like so long as its black", but 
close :)
>
>"std.string" is a module, so it can't also be a package. That's a
>limitation of the D language.

Now. This is where you show me up to be nothing but a pretender in this 
forum.
I have no idea what the distinction is be tween thos two in D.


>>  Finally, if the retention of unused but allocated space in an array is a
>>feature of the current design, then I would add
>>  a debug time warning indicating when a char[] has had to be grown. These
>>could be used during devlopment to adjust
>>  the preallocated size of arrays to be large enough to accomodate all (most?
>>typical?) requirements.
>
>I would support the addition of some function like
>
>     gc.minimise(char[])
>
>which returned all the unused space following the end of the array
>back to the gc, without any copying of the used part. I wouldn't be
>able to write that though - the gc is not my area of expertise.

I /think/ you may have misunderstood my intent here. Unsurprising cos it 
was badly outlined.
And I'm not at all sure that D works this way.

In, for example, Perl, an array can be pre-sized but then set to be empty.
That is, it can have space preallocated to it, but contain nothing.
Likewise strings have two length attributes internally.
- one denotes the length of the contents, as woudl be returned to the 
program by the length() function.
- one indicated the actual length of the ram allocated to it.

This allows, or example, chomp() to simply move adjust a number (the 
program visible length) and do
not adjustment or reallocation at all. It can also adjust the left hand 
end of the contents
effectively foreshortening the string, again without adjusting the 
allocation.
So visually, a scalar holding a string might at some point in its life 
look something like:
(this ascii art is going to come out a mess on the server but...)

header
[ offset     ]     |--------+
[actualLen  
]-------------------------------------------------------------------------->
[pgmVisible]              |------------------------------------------------>
[pointer    ]----v         |
                    [][][][][][][the contents the program can see is here][][][][][][]

Basically, it start out with offset zero and only as much padding (if any) 
as is required to bring it to suitable alignment.
But if you remove characters at the end (chomp or chop) then the padding 
grows as the content shrink and nothing is allocated.
If you remove characters from the front of the string the offset 
accomodates that and the allocation doesn't change.
And if further mutations expand the string, then these spaces are reused 
before a new allocation is made.

If for example, you know you are going to be build ia long string up 
piecewise from small appendages, you can inilialise it to some
length big enough for the expected final length and the truncate it 
(assign '' to it) and it will retain its allocation, even though the
program visible length is zero. Then, as you add stuff to it, it grows 
into the allocation.

My point was that /if/ Ds arrays have a similar capability, to be 
preallocated large and empty and grow into the space then
when a mutation requires a reallocation of a mutable array because it has 
outgrown its original allocation,
then a debug-enabled warning saying by how much, might allow the 
programmer to preallocate the initial mutable array larger and
so avoid reallocation at runtime.

There's a whole heap of speculation about what might be going on inside D 
that I have no real knowledge of at all.

Note:There is no suggestion here that D shoudl work this way. Only that if 
it does allow preallocation of arrays sizes,
then a warning when a mutation causes allocation would allow the 
programmer to best use that facility.

Cheers, b.

--