# Re: G_UTF8String: Boxed Type Proposal

*Date*: Mon, 21 Mar 2016 13:30:24 -0700*From*: Behdad Esfahbod <behdad@xxxxxxxxxx>*Subject*: Re: G_UTF8String: Boxed Type Proposal

I like to voice my opinion as well:

- Bundling data and its length in a boxed type is useful, but that's gblob,I also have a piece of a more personal opinion: Many processes that simply *reject* invalid Unicode text are useless in many situations. For example, gedit used to refuse to open a file if it had even a single invalidly-encoded byte. I find that annoyingly limited. Same thing about Pango. Fortunately, both have been fixed for many years now.

behdadOn Mon, Mar 21, 2016 at 6:32 AM, Matthias Clasen <matthias.clasen@xxxxxxxxx> wrote:

On Fri, Mar 18, 2016 at 9:57 AM, Randall Sawyer

<srandallsawyer@xxxxxxxxxxx> wrote:

> 2) If the former is true - which it is - then the developer will need to

> call g_utf8_strlen() to determine if there are multi-byte sequences to

> navigate - and if there are - g_utf8_offset_to_pointer() to locate the array

> index. Doesn't this increase processing demand?

It does. But whether that is a problem (in general, or for your

particular use case) can only be answered by profiling. My theory is

that you won't be able to notice this on the profile at all, unless

all your application does is constantly operating on large amounts of

text. In which case, you really shouldn't be using GString to begin

with...

> 3) Wouldn't it be helpful to keep track of how many code points

> ("characters")are stored in the GString - a number which may be less than

> the value of GString.len - without needing to call g_utf8_strlen() each time

> to find out?

> 4) Would my efforts be better spent editing patches of "gstring.h" and

> "gstring.c" - or - to proceed as I am to introduce a parallel alternative?

I think we haven't gotten past the 'what is the problem you are trying

to solve - and is it a problem in the first place ?' part yet.

_______________________________________________

gtk-devel-list mailing list

gtk-devel-list@xxxxxxxxx

https://mail.gnome.org/mailman/listinfo/gtk-devel-list

--

behdad

http://behdad.org/

http://behdad.org/

_______________________________________________ gtk-devel-list mailing list gtk-devel-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-devel-list

**Follow-Ups**:**Re: G_UTF8String: Boxed Type Proposal***From:*Randall Sawyer

**References**:**G_UTF8String: Boxed Type Proposal***From:*Randall Sawyer

**Re: G_UTF8String: Boxed Type Proposal***From:*Matthias Clasen

**Re: G_UTF8String: Boxed Type Proposal***From:*Randall Sawyer

**Re: G_UTF8String: Boxed Type Proposal***From:*Jasper St. Pierre

**Re: G_UTF8String: Boxed Type Proposal***From:*Matthias Clasen

**Re: G_UTF8String: Boxed Type Proposal***From:*Jasper St. Pierre

**Re: G_UTF8String: Boxed Type Proposal***From:*Matthias Clasen

**Re: G_UTF8String: Boxed Type Proposal***From:*Simon McVittie

**Re: G_UTF8String: Boxed Type Proposal***From:*Matthias Clasen

**Re: G_UTF8String: Boxed Type Proposal***From:*Randall Sawyer

**Re: G_UTF8String: Boxed Type Proposal***From:*Matthias Clasen

- Prev by Date:
**Re: G_UTF8String: Boxed Type Proposal** - Next by Date:
**Re: G_UTF8String: Boxed Type Proposal** - Previous by thread:
**Re: G_UTF8String: Boxed Type Proposal** - Next by thread:
**Re: G_UTF8String: Boxed Type Proposal** - Index(es):