std.stringbuffer

[Robert Fraser]

Janice Caron wrote:
> 2008/4/30 Me Here <p9e883002 at sneakemail.com>:
>>> "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.
> 
> One is file, the other is a folder. std.string is a file, so it can't
> also be a folder.
> 
> 
>>  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.
> 
> Well, that's what a StringBuffer would do, but nobody seemed to like
> the idea. A string contains two pieces of information: (1) ptr, and
> (2) length. A StringBuffer would carry a third piece of information:
> (3) capacity. (Actually, in general it would be Buffer!(T), with
> StringBuffer just being a special case).
> 
> Built in-strings to have a capacity, but it's not carried round in a
> field. Instead. to find the capacity of an array, you have to call
> std.gc.capacity(array) - and I can't see how there can not be a
> performance hit there.
> 
> Increasing the length of a D array doesn't necessarily mean
> reallocating (although as noted above, the code has to do some work to
> find out the capacity), but it /does/ mean re-initialising the newly
> exposed elements. Again, that has to be a performance hit. With a
> Buffer!(), you could increase the length (up to capacity) not only
> without reallocating but also without reinitializing, just by changing
> the value of an int.
> 
> But <shrugs> - if people don't want StringBuffers, who am I to argue?

I like StringBuffers :-). Did Walter veto the idea completely or did he 
say "not a class". I'd use a struct - there's no extra bloat, the 
interface can be encapsulated, and people can use a pointer if they're 
passing between functions (since it will most often be used within the 
scope of a single function anyway). Or just pass it on the stack, if 
it's guaranteed to only be 3 DWORDs.

My suggestion (grain of salt) is to represent them similarly to the way 
mtext does by using two bits somewhere to hold the character type (char, 
wchar, dchar) and change character types as needed.