About Strings

[Lubos Lunak]

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.hallot at documentfoundation.org
> > <mailto:olivier.hallot at 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.lunak at suse.cz