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.
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.