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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
