[haiku-development] Re: BString method SymbolAt() proposal
- From: "Michael Lotz" <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 21 Jun 2010 00:20:58 +0200
> On 2010-06-19 at 18:34:23 [+0200], Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
> > wrote:
> > On 2010-06-19 at 12:39:47 [+0200], Reinhard Scharnagl
> > <rescharn@xxxxxxx>
> > wrote:
> > > The BString class seems to be not complete. Typical UTF8 symbols
> > > like '€' do not fit into one char but into an int32. Nevertheless
> > > BString
> > > methods only support char parameters, where handling a single
> > > UTF8
> > > symbol is intended.
> >
> > That's not at all true, there are:
> > const char* CharAt(int32 charIndex, int32* bytes =
> > NULL)
> > const;
> > bool CharAt(int32 charIndex, char* buffer,
> > int32* bytes) const;
>
> Those do have O(n) complexity, though, which makes iteration
> unnecessarily
> expensive. Not much of a problem for short strings, but not so nice
> for a
> generic API. A BUnicodeString with O(n) string conversion and O(1)
> random
> character access would be much nicer.
A bit late, but: I've introduced these along with character based
versions of most other relevant functions in r35371. These aren't
documented in the BeBook for obvious reasons. While these aren't really
optimized they make it way easier to handle UTF8 as used in the rest of
the system. The Tracker filtering/typeahead not properly handling
multibyte strings was my initial motivation to add these functions
(r35375), and they have since been put to use to replace some
occurances of manual UTF8 handling within other code (the string
truncation code for example, r35381).
In short, the proposed function isn't necessary as the Chars version of
the BString methods should already provide everything to properly do
all the BString provided string operations on a character basis (even
though not really efficiently for larger strings).
Regards
Michael
Other related posts:
