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.cla...@gmail.com>
wrote:
> On Fri, Mar 18, 2016 at 9:57 AM, Randall Sawyer
> <srandallsaw...@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/
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
