Re: utf-16 and glib

[Dominic Lachowicz]

> Glib/gtk is full of macros. I believe que a C compiler is the right place to
> this kind of unsafe code. If i want create safe code i have c#,c++, JAVA, D
> or VALA.
> Using macros is the only way to ensure intermediate APIs don´t have any
> overhead. Besides modern GUIs have support to understand what we have in a
> MACRO. Visual c++ have that kind of support.

The argument isn't against macros in general. It's against having
macros choose an underlying implementation of a function.

As far as I'm aware, this is only done in glib on win32 where
filenames are concerned. And this was done because we couldn't change
the *fundamentally broken* API due to ABI guarantees (the functions
were defined as taking a string in your multi-byte locale. if you
upgraded glib to a version that always expected utf8, a lot of
existing apps would break due to no fault of their own, which would be
bad).

That's a completely different use case than yours. And a regrettable
one, because everyone agrees that we'd rather not have those macros
there if we could have somehow avoided them. You're not supposed to
explicitly call the _utf8() version, nor are you supposed to have
access to the other deprecated, broken version. Contrast this with all
of Microsoft's A/W functions, and you'll see that the situations are
completely different.

So what you're suggesting is introducing brokenness by design, rather
than reluctantly coping with some brokenness of an existing design.

Besides, your case is based on some presumed "efficiency" of using
UTF-16, but you have demonstrated no such evidence in your favor,
which is unlikely to convince glib's maintainers. The cost of
converting a filename from UTF-8 to UTF-16 isn't very high, I'll tell
you.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: utf-16 and glib

[Dominic Lachowicz]

>>> What is wrong with:
>>> gchar*  g_utf8_strncpy  (gchar *dest,const gchar *src,gsize n);
>>>
>>
>> That's one not needed as strncpy should work.
>>
>
> hehe i know but that function it really exist:
> http://library.gnome.org/devel/glib/unstable/glib-Unicode-Manipulation.html#g-utf8-strncpy

It does make sense. strncpy copies N bytes, when what you want to do
is copy N characters from a multi-byte encoded string. You don't want
to the copy to stop somewhere in the middle of a multi-byte character
sequence because the result simply wouldn't make sense.

>>> and the macro:
>>> gtext*  g_text_strncpy  (gtext*dest,const gtext*src,gsize n);

Because having 2 implementations of a function and having 1
automatically chosen by a pre-processor macro is one of the worst API
decisions that Microsoft has ever made. And that's saying something.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list