> 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