On Sunday 18 of March 2012, Olivier Hallot wrote: > Thanks Rafael > > Any suggestion for the same issue for OUStringBuffer?
First of all, what code would need such additions to OUStringBuffer? The two classes are modeled after Java's strings, where the idea is that the normal string is ... well, the normal string, and the buffer string is for creating new strings. Therefore, in theory, you do not need querying functionality in OUStringBuffer. In practice, as it happens, theory and practice are not quite the same :). So, if justified, I don't think there'd be any practical reasons against duplicating OUString methods in OUStringBuffer, they would be small inline functions calling the same functionality anyway. That said, I myself dislike the buffer class. I doubt its preallocation is a significant requirement for good performance (especially given it's only 16 characters). I think a much better and simpler solution would be to drop the buffer class and instead add reserve() to the string class for the cases where it would matter. Hopefully when we can break the ABI. Or, actually, seeing that _rtl_uString is marked as internal by the doxygen doc, it looks like it might be doable even now. Something to add to my TODO list for making the string classes actually nice to use :). > Em 18-03-2012 10:46, Rafael Dominguez escreveu: > > Theres no need, OUString already has a method lastIndexOf, > > http://opengrok.libreoffice.org/xref/core/sal/inc/rtl/ustring.hxx#1133 > > > > On Sun, Mar 18, 2012 at 1:06 PM, Olivier Hallot > > <olivier.hal...@documentfoundation.org > > <mailto:olivier.hal...@documentfoundation.org>> wrote: > > > > Hi all > > > > I put forefront that I am a newbie on C++ so, forgive me if I ask things > > too basic or dumb. I was looking into the replacement of String by > > OUString/OUStringBuffer in some parts of the code (starmath). > > > > First, I'd like a pointer on a text/discussion on why this is > > necessary/recomended.(*) The String class is deprecated. There's nothing to gain from having 2 classes for the same purpose, perhaps besides headaches. > > Secondly, as expected, some of the members of class String don't exist > > in O[U]String[Buffer]. Therefore I was advised by Norbert to create the > > member in the classes where I need them. So far, so good. > > > > But such critical class, used all over the code, need a bit more care > > and sponsorship, so with the specific case of > > STRING::SearchBackward(...), is it OK to add a new member in > > rtl::OUStringBuffer? If so, is it OK to clone STRING:SearchBackward(...) > > to OUStringBuffer::SearchBackward(...)? No. As said above, if the addition is justified, for consistency it should be modeled after OUString, not String. -- Lubos Lunak l.lu...@suse.cz _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
