Re: G_UTF8String: Boxed Type Proposal

[Behdad Esfahbod <behdad behdad org>]

I like to voice my opinion as well:

  - Bundling data and its length in a boxed type is useful, but that's gblob,

  - Bundling number-of-Unicode-character is rarely useful indeed,

  - A string API that would require any changes to the string content to go through editing function calls is painful and will remain unused,

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.

behdad

On Mon, Mar 21, 2016 at 6:32 AM, Matthias Clasen <matthias clasen gmail com> wrote:

On Fri, Mar 18, 2016 at 9:57 AM, Randall Sawyer
<srandallsawyer hushmail me> 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 gnome org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

--

behdad
http://behdad.org/