Probably just reinventing the wheel - I was not able to quickly find a String builder/buffer elsewhere.

Source code for anyone possible interested is published on a blog (no ads there, so I hope it's OK to post the link):

http://freepascal-bits.blogspot.com/2010/02/simple-string-buffer.html

-bflm

Hello,
I guess ads wouldn't be a problem anyway ;-)
I find a class like this very useful (for some tasks), thanks! This has been suggested on the list a couple of times and I even intended to implement something but didn't have the need since. Some (hopefully constructive) commentaries (and then I would suggest to add to LCL or FCL):
1) It could be called really TStringBuffer;
2) The 'W' methods could be called 'Append';
3) The GetS method could truncate the string to avoid the copy, as I think the common use will not be Append+Read+Append+Read, but Append+Append+...+Read...

Best regards,
Flávio

Honza wrote

Probably just reinventing the wheel - I was not able to quickly find a String builder/buffer elsewhere.

Thanks for the contribution. Could you explain what the advantages are of that string buffer object compared to a standard string types like AnsiString or TStringList?

Regards,
- Graeme -

I agree in all points, even while having some more ideas on the naming. If it will be considered for FCL, then let the dev team pick identifiers of their choice and any other changes/improvements - I'll be happy to implement them if needed.

Could you explain what the advantages are of that string buffer object compared to a standard string types like AnsiString or TStringList?

I guess some memory and/or time could be saved in certain usage patterns compared to TSTringList and String. There is now a dumb benchmark on the blog, but nobody should trust other's benchmarks :)

http://freepascal-bits.blogspot.com/2010/02/string-buffer-performance.html

-bflm

In our previous episode, Honza said:

Afaik later delphi versions add a stringbuilder like class. It might be worthwhile to see if something compatible can be crafted.

Honza wrote

I guess some memory and/or time could be saved in certain usage patterns compared to TSTringList and String. There is now a dumb benchmark on the blog, but nobody should trust other's benchmarks :)

Thanks. Good news is that it looks consistently faster than both String and StringList. :)

Regards,
- Graeme -