sbergman at redhat.com
Mon Mar 19 05:39:28 PDT 2012
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
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.
More information about the LibreOffice