On 10/01/2012 12:38 PM, Michael Meeks wrote:
On Mon, 2012-10-01 at 11:32 +0200, Noel Grandin wrote:
David, I agree with you - what I'm really getting at here is that it
seems perfectly reasonable to me to fold the functionality of
OUStringBuffer into OUString, making our string classes that much simpler.
Otherwise we're going to end up constantly converting between the two
for no good reason that I can see.
I guess it'd be good to have some sample patches for tools string
conversion showing the problem - that'd really help the discussion I
think.
We'd have to make the following changes to struct rtl_uString:
- add (or steal from somewhere) a single bit to indicate whether or not
the buffer field contained a read-only array of chars
- a 'sal_uInt32 nCapacity' field.
Fitting that inside the ABI is going to be quite fun; then again - we
havn't played the old game of adjusting pointers to allocate magic data
before the struct yet I guess.
...and I hope we never do. ;) Really, there likely are better
arguments in favor of a complete redesign of LO's string functionality
than in trying to unite OUString and OUStringBuffer in a
backwards-compatible way. While the distinction between the two is
arbitrary and unnecessary, that problem is IMO "well under control."
Stephan
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
