Re: utf-16 and glib

[Dominic Lachowicz <domlachowicz gmail com>]

> 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.