On Mon, 2011-10-31 at 09:15 +0100, Stephan Bergmann wrote: > However, I would also be sceptical that there are that many places that > actually need to construct such an (immutable!) string---maybe at least > some of the places are misguided attempts at preallocating some buffer > of a given length? Those should then be rewritten to use > rtl::OUStringBuffer instead.
Worth noting that the ByteString Fill and Expand are now removed. So its just String that retains Fill/Expand. I handled the ByteString::Fill generally on a case-by-case basis. e.g. 565587eba10a8c4e01d4346669327bd9065c5dfa where the idea was simply to write 512 0's to disk Generally IIRC StringBuffers were the way to go. You can find padToLength in comphelper/inc/string.hxx which expands a buffer to the desired length and pads it with the requested character, which is pretty much an equivalent to the "Expand" concept anyway. C. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
