Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


On 01/10/12 13:55, Noel Grandin wrote:

On 2012-10-01 13:47, Michael Stahl wrote:
... which brings me to another point: in a hypothetical future when we 
could efficiently create a UTF8String from a string literal in C++ 
without copying the darn thing, what should hypothetical operations to 
mutate the string's buffer do?

We need external iterators that store the byte index of the current 
code-point as part of their state.
Update operations would then take that iterator as a parameter, so that 
they'd know where to start mutating from.
Then it becomes a case of carefully shuffling the correct number of 
bytes around, bearing in mind that a unicode code-point may be anything 
from one to four bytes long.

that's also a problem, but i was thinking of another one: string literal
goes into a write-protected memory map which will cause a segfault on
writes.

Or are you talking about memory management?
The current OUString class allocates a new character buffer for every 
mutation, I assume we'd keep that strategy.

you mean if i have some string and then add !a" "b" "c" to it it will
re-allocate 3 times?  that is too expensive.  there needs to be some
protocol to ensure exclusive ownership of the buffer (which the
OUStringBuffer has automatically) and then whenever it's out of capacity
double the allocation.



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.