Re: About Strings

On 03/19/2012 07:27 AM, Lubos Lunak wrote:
>   First of all, what code would need such additions to OUStringBuffer? The two
> classes are modeled after Java's strings, where the idea is that the normal
> string is ... well, the normal string, and the buffer string is for creating
> new strings. Therefore, in theory, you do not need querying functionality in
> OUStringBuffer. In practice, as it happens, theory and practice are not quite
> the same :). So, if justified, I don't think there'd be any practical reasons
> against duplicating OUString methods in OUStringBuffer, they would be small
> inline functions calling the same functionality anyway.

My take on it, too.

>   That said, I myself dislike the buffer class. I doubt its preallocation is a
> significant requirement for good performance (especially given it's only 16
> characters).

At least, it properly doubles capacity in ensureCapacity.

> I think a much better and simpler solution would be to drop the
> buffer class and instead add reserve() to the string class for the
> cases where it would matter. Hopefully when we can break the ABI.

Splitting into an immutable string and mutable buffer class probably 
makes much less sense in C++ than in Java, from where the design has 
been ported just too naively.  (And even if immutable classes are 
generally also a good idea in C++, esp. in combination with 
multi-threading, the mutable rtl::OUString::operator= spoils this, anyway.)

>   Or, actually, seeing that _rtl_uString is marked as internal by the doxygen
> doc, it looks like it might be doable even now. Something to add to my TODO
> list for making the string classes actually nice to use :).

While rtl_uString is internal, its layout is effectively part of the ABI.

Stephan