Re: GLib String support

Am Samstag, den 09.08.2008, 19:01 +0100 schrieb adrian.dmc:
> Hi...
> Following my previous e-mail I'll present were my ideas for changing
> the support for strings in GLIb.
> When I look at the string functions in Glib there is a lot of
> inconsistency: error checking, what character set is supported and
> function naming; so I'm proposing to change, at least, the function
> naming system to something like:
> #
> # g_ascii/loc/utf8_str[n]%function%
> #
> # loc - uses current locale
> # ascii - uses ascii
> # utf8 - uses utf-8
> #
> # if n is specified it indicates that the function is limited by
> length
> #
> # %function% - dup, cpy, cat, len, pre, suf, strip, ...
> #
> Because there's a lot of changes this will only make part of the 3.0
> release (I think).
> To minimize code length a macro can be used to set the default
> encoding (ascii/loc/utf8).
> As I change the naming system I'll optimize existing code and error
> checking (if needed).
> Please comment, I would like to know if I should proceed with this
> idea or not...

Strings in glib/gtk always are UTF-8. Always. So there is absolutely no
need for "current locale" versions of string handling functions. There
also shouldn't be such a version, since codepages were broken from the
day when they were invented: They needlessly limit the range of
characters a application can process, and even more important: They add
a vast amount of complexity to your program. Programmers really should
not have to think about locale issues.

Remains the question: Why are their ASCII only versions of all those
functions. Dunno. Legacy? Performance? Side note: Why don't have Intel's
fancy processors some g_utf8_next_char() function yet?


Mathias Hasselmann <mathias hasselmann gmx de>
Openismus GmbH:
Personal Site:

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]