std.stringbuffer

[Me Here]

Bruno Medeiros wrote:

>A couple of thoughts:

>>std.stringbuffer, to contain two things:
>>
>>(1) a StringBuffer class
>>(2) parallel mutable versions of the functions in std.string.
>>
>
>I'm with Jarret here, why the hell do we need a StringBuffer class? 
>'string' is not a class either, so just use char[].
>
>I would recomment aliasing char[] to 'mstring' (short for mutable string. 
>I think such an alias is more readable than 'char[]'
>
>Also, is there a reason why these mutable functions shouldn't be in 
>std.string, together with their invariant/const brethren?
>I don't think it makes sense to have another package if one opt by the (2) 
>solution.

As one of those that has request "a standard library of string functions 
that accept and return mutable strings Ie. char[]",
I see no reason it should be a class, free function seem to work just 
fine. A class would just be bloat.

I would be perfectly happy for these to co-exist in the std.string space. 
Indeed I would prefer it.

If a separate namespace is deamed /essential/, then I see no reason to go 
with, and certainly did "ask for" it to be called
the misleading name of std.StringBuffer. As far as I recall, that was 
Janice's own suggestion.

For preference, if a separate namespace is absolutely necessary, I go for:

     std.string.mutable

The right namespace and does what is says on the tin.

Further, /if/ I had any input to the design, then the suggestion for me to 
have to pass in preallocated buffers
to accomodate the mutated data if it needs to grow would be scotched 
forthwith.

They should look and work in exactly the same way as the existing v2 
std.string functions taking the same number
and order of parameters. Just char[] (or compatible alias) instead of 
string.

If the buffers need to grow, then allocate space from wherever (I assume 
the heap) that std.string allocates from now.
If they do not change size, then return the original intact.
If they shrink, and if the D array internals permit this, then adjust the 
.length attribute whilst leaving the actual
allocation unchanged. That way it is there for use should further 
mutations cause it to grow again.
This also helps prevent heap fragmentation if the functions are called on 
heap allocated data.

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.

In summary: mutable string functions shoudl do exactly the same as the 
invarient functions do now,
except only reallocate if necessary and (optionally) issue a warning under 
debug if they have to.

Seems almost as if a template solution could be used, except that I think 
the additional conditional code would
hamper the performance of both instantiations. Unless Ds templating is 
capable of optiising away branches
of code that relate to the /other/ type instantiations? I've had no 
occasion to use templates in D yet, so that might
be pie in the sky.



--