std.stringbuffer

[Janice Caron]

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?