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? Ciao, Mathias -- Mathias Hasselmann <mathias hasselmann gmx de> Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil