optimising OUString for space

[Stephan Bergmann]

On 10/01/2012 02:45 PM, Michael Stahl wrote:
> On 01/10/12 14:23, Noel Grandin wrote:
>> On 2012-10-01 13:58, Michael Stahl wrote:
>>> 	The only problem with a change there is our ABI - which explicitly
>>> exposes the encoding of that.
>>> the right time to do it is for LO4.  sadly nobody has signed up for that
>>> yet :( ... (while there are volunteers for far sillier proposals, like
>>> getting rid of com.sun.star...)
>>
>> Perhaps we need to split out some preparatory tasks?
>> For example
>>    - fix code that directly accesses the underlying buffer
>>    - create an external iterator class (which would currently be a thin
>> wrapper around int) for looping over the buffer and indexing into it
>> -  fix code that indexes into an OUString to use the new external iterator
>
> there already exists method iterateCodePoints, using a pointer to the
> next code unit as the iterator (note that this interface depends on
> immutability of the buffer):
>
>>      inline sal_uInt32 iterateCodePoints(
>>          sal_Int32 * indexUtf16, sal_Int32 incrementCodePoints = 1) const
>
> problem is, nobody is using it...
>
> guess you could comment out operator[], that should find lots of
> convertible call sites :)

Note that in the common case of accessing (i.e., searching for, etc.) 
7-bit ASCII content in a string, regardless of whether it is internally 
represented as UTF-8 or UTF-16, going via an operator[] interface that 
operates directly on the string object's innards might be more efficient 
than going via an iterator interface (which is, of course, necessary 
when potentially accessing non-ASCII content).

What an ideal string abstraction would look like is not clear to me at all.

Stephan