Re: utf-16 and glib
Please, please, please don't switch to UTF-16. To me gtk is about getting to use technologies that are solid, real, fun, and effective. Principally, that means C and *nix. UTF-8 is the greatest thing for one reason that kills all the others: solid compatibility with both of the above. I think gtk on 'doz is the coolest thing, and an extra file name conversion here and there is totally acceptable and then some. Siting the way other software does things just shows why gtk delivers so much. As an application developer, sticking with utf-8 all day long and not worrying about it is just awesome. Yes I do have to worry about it sometimes, like when I use .fred pinvoke() wrappers, some 'doz python issues, etc., but just use the appropriate conversion function and move on. ... I wonder if g_print() will deliver extended characters to the win32 console the right way ... I also wonder if you read text from a cgi form variable how you would even know what encoding it's in... ...cutting extended character text in windows and pasting it into gtk and having everything automatically work is fantastic btw... ___ 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 (was: g_malloc overhead)
On Mon, 2009-01-26 at 22:49 +0100, Martin (OPENGeoMap) wrote: Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full utf16 and utf8 api in glib and use a macro to work work intermediate string: For example in windows they have this types: LPSTR =char * char * is used for utf-8 AFAIR LPWSTR= utf16windowschar * gunichar2 perhaps in glib we could have utf16 and utf8 in that way or am i wrong? I'm not glib developer. As far as the module of operating on utf-16 strings is proposed I'm not against. However I would prefere to not have 2 entries to each function. Hi: What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); That's one not needed as strncpy should work. gunichar2 * g_utf16_strncpy (gunichar2*dest,const gunichar2*src,gsize n); That's kind of support I'm not against. and the macro: gtext* g_text_strncpy (gtext*dest,const gtext*src,gsize n); regards. With the entries - nothing. With macro - it may be just me but I percive it shooting into foot. Just imagine that some header will assume gtext to be utf-8. Other will turn on the macro (or user code) and change it to utf-16. IMHO - having magic switch which might change the ABI is not good. Regards signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
On Mon, 2009-01-26 at 23:01 +0100, Martin (OPENGeoMap) wrote: Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:49 +0100, Martin (OPENGeoMap) wrote: Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full utf16 and utf8 api in glib and use a macro to work work intermediate string: For example in windows they have this types: LPSTR =char * char * is used for utf-8 AFAIR LPWSTR= utf16windowschar * gunichar2 perhaps in glib we could have utf16 and utf8 in that way or am i wrong? I'm not glib developer. As far as the module of operating on utf-16 strings is proposed I'm not against. However I would prefere to not have 2 entries to each function. Hi: 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 My error. Regards signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
On Mon, 2009-01-26 at 23:48 +0100, Martin (OPENGeoMap) wrote: Dominic Lachowicz escribió: 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. Glib/gtk is full of macros. But how many of them changes the meaning by other 'switch-macro'? I'm nearly sure that all of them evaluate to the same values at each gived platform. I believe que a C compiler is the right place to this kind of unsafe code. What do you mean by 'unsafe'? If the 'unsafe' code is unsafe there is no place to put it. If the 'unsafe' means that the code cannot be verified easily by compiler if it is correct that there is place in C code (or any other). 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. How much is the overhead? How big it is in compare to for example I/O in accessing filesystem, drawing in access to GTK+ or to GC in access to C#/Java? Besides modern GUIs You mean IDE not GUI. have support to understand what we have in a MACRO. Visual c++ have that kind of support. Well. To begin with not everybody uses IDE. I'm happy with emacs. There are people happy with gedit or vim. And, eventually, it doesn't matter what IDE have support to. What programmer have support is the real matter. And - finally - what IDE will do with included header? Regards. Regards signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
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
Re: utf-16 and glib (was: g_malloc overhead)
On Mon, 2009-01-26 at 22:49 +0100, Martin (OPENGeoMap) wrote: Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full utf16 and utf8 api in glib and use a macro to work work intermediate string: For example in windows they have this types: LPSTR =char * char * is used for utf-8 AFAIR LPWSTR= utf16windowschar * gunichar2 perhaps in glib we could have utf16 and utf8 in that way or am i wrong? I'm not glib developer. As far as the module of operating on utf-16 strings is proposed I'm not against. However I would prefere to not have 2 entries to each function. Hi: What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); That's one not needed as strncpy should work. gunichar2 * g_utf16_strncpy (gunichar2*dest,const gunichar2*src,gsize n); That's kind of support I'm not against. and the macro: gtext* g_text_strncpy (gtext*dest,const gtext*src,gsize n); regards. With the entries - nothing. With macro - it may be just me but I percive it shooting into foot. Just imagine that some header will assume gtext to be utf-8. Other will turn on the macro (or user code) and change it to utf-16. IMHO - having magic switch which might change the ABI is not good. Regards ___ 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
On Mon, 2009-01-26 at 23:01 +0100, Martin (OPENGeoMap) wrote: Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:49 +0100, Martin (OPENGeoMap) wrote: Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full utf16 and utf8 api in glib and use a macro to work work intermediate string: For example in windows they have this types: LPSTR =char * char * is used for utf-8 AFAIR LPWSTR= utf16windowschar * gunichar2 perhaps in glib we could have utf16 and utf8 in that way or am i wrong? I'm not glib developer. As far as the module of operating on utf-16 strings is proposed I'm not against. However I would prefere to not have 2 entries to each function. Hi: 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 My error. Regards ___ 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
On Mon, 2009-01-26 at 23:48 +0100, Martin (OPENGeoMap) wrote: Dominic Lachowicz escribió: 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. Glib/gtk is full of macros. But how many of them changes the meaning by other 'switch-macro'? I'm nearly sure that all of them evaluate to the same values at each gived platform. I believe que a C compiler is the right place to this kind of unsafe code. What do you mean by 'unsafe'? If the 'unsafe' code is unsafe there is no place to put it. If the 'unsafe' means that the code cannot be verified easily by compiler if it is correct that there is place in C code (or any other). 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. How much is the overhead? How big it is in compare to for example I/O in accessing filesystem, drawing in access to GTK+ or to GC in access to C#/Java? Besides modern GUIs You mean IDE not GUI. have support to understand what we have in a MACRO. Visual c++ have that kind of support. Well. To begin with not everybody uses IDE. I'm happy with emacs. There are people happy with gedit or vim. And, eventually, it doesn't matter what IDE have support to. What programmer have support is the real matter. And - finally - what IDE will do with included header? Regards. Regards ___ 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
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
Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:49 +0100, Martin (OPENGeoMap) wrote: Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full utf16 and utf8 api in glib and use a macro to work work intermediate string: For example in windows they have this types: LPSTR =char * char * is used for utf-8 AFAIR LPWSTR= utf16windowschar * gunichar2 perhaps in glib we could have utf16 and utf8 in that way or am i wrong? I'm not glib developer. As far as the module of operating on utf-16 strings is proposed I'm not against. However I would prefere to not have 2 entries to each function. Hi: 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 gunichar2 * g_utf16_strncpy (gunichar2*dest,const gunichar2*src,gsize n); That's kind of support I'm not against. and the macro: gtext* g_text_strncpy (gtext*dest,const gtext*src,gsize n); regards. With the entries - nothing. With macro - it may be just me but I percive it shooting into foot. Just imagine that some header will assume gtext to be utf-8. Other will turn on the macro (or user code) and change it to utf-16. IMHO - having magic switch which might change the ABI is not good. Regards ___ 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 escribió: 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. 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. Regards. ___ 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
Martin (OPENGeoMap) wrote: Dominic Lachowicz escribió: 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. 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. You are still to show us where this becomes a bottleneck. This does not make any sense in glib. I've been thinking about possibly adding UTF-16 and UTF-32 APIs to Pango, and that makes more sense when interfacing with other apps. But I've kept the macro idea just for my internal implementation in Pango, not as crack to be put in public header files. behdad Regards. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ 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
Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:49 +0100, Martin (OPENGeoMap) wrote: Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full utf16 and utf8 api in glib and use a macro to work work intermediate string: For example in windows they have this types: LPSTR =char * char * is used for utf-8 AFAIR LPWSTR= utf16windowschar * gunichar2 perhaps in glib we could have utf16 and utf8 in that way or am i wrong? I'm not glib developer. As far as the module of operating on utf-16 strings is proposed I'm not against. However I would prefere to not have 2 entries to each function. Hi: 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 gunichar2 * g_utf16_strncpy (gunichar2*dest,const gunichar2*src,gsize n); That's kind of support I'm not against. and the macro: gtext* g_text_strncpy (gtext*dest,const gtext*src,gsize n); regards. With the entries - nothing. With macro - it may be just me but I percive it shooting into foot. Just imagine that some header will assume gtext to be utf-8. Other will turn on the macro (or user code) and change it to utf-16. IMHO - having magic switch which might change the ABI is not good. Regards ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
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-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
Dominic Lachowicz escribió: 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. 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. Regards. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
Martin (OPENGeoMap) wrote: Dominic Lachowicz escribió: 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. 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. You are still to show us where this becomes a bottleneck. This does not make any sense in glib. I've been thinking about possibly adding UTF-16 and UTF-32 APIs to Pango, and that makes more sense when interfacing with other apps. But I've kept the macro idea just for my internal implementation in Pango, not as crack to be put in public header files. behdad Regards. ___ gtk-app-devel-list mailing list gtk-app-devel-l...@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
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-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
Maciej Piechotka escribió: On Mon, 2009-01-26 at 23:48 +0100, Martin (OPENGeoMap) wrote: Dominic Lachowicz escribió: 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. Glib/gtk is full of macros. But how many of them changes the meaning by other 'switch-macro'? I'm nearly sure that all of them evaluate to the same values at each gived platform. I believe que a C compiler is the right place to this kind of unsafe code. What do you mean by 'unsafe'? If the 'unsafe' code is unsafe there is no place to put it. If the 'unsafe' means that the code cannot be verified easily by compiler if it is correct that there is place in C code (or any other). by unsafe i want say something like the g-signal-connect macro: http://library.gnome.org/devel/gobject/unstable/gobject-Signals.html#g-signal-connect 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. How much is the overhead? How big it is in compare to for example I/O in accessing filesystem, drawing in access to GTK+ or to GC in access to C#/Java? hummm. Example: If we have for example a DWG binary file we have for example 15000 utf16 strings. If i use glib i need make 15000 translations utf16/utf8 to use the utf8 glib api. When i need save the file i need make other 15000 translations. There are thounsand of formats using utf16. I don´t love utf16, but I MUST use utf16 in the real world. I am not the guilty of existence of utf16 :'( . Regards. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
Martin (OPENGeoMap) wrote: hummm. Example: If we have for example a DWG binary file we have for example 15000 utf16 strings. If i use glib i need make 15000 translations utf16/utf8 to use the utf8 glib api. When i need save the file i need make other 15000 translations. There are thounsand of formats using utf16. I don´t love utf16, but I MUST use utf16 in the real world. I am not the guilty of existence of utf16 :'( . Your examples fails to show that the conversion takes any considerable time compared to other stuff you are doing (for example, I/O is orders of magnitude slower). behdad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
On Tue, 2009-01-27 at 00:19 +0100, Martin (OPENGeoMap) wrote: hummm. Example: If we have for example a DWG binary file we have for example 15000 utf16 strings. If i use glib i need make 15000 translations utf16/utf8 to use the utf8 glib api. When i need save the file i need make other 15000 translations. There are thounsand of formats using utf16. I don´t love utf16, but I MUST use utf16 in the real world. I am not the guilty of existence of utf16 :'( . If you find that really is a bottleneck, there's nothing stopping you from writing functions _in your app_ which would deal with the strings as UTF-16 throughout the process of loading and saving. Philip Regards. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
Martin (OPENGeoMap) wrote: I don´t want say we MUST add more support to glib. I only say most software developers works with utf16 text and many of that people are not fan of that encoding but they must use it in the 100% of the source code. Other than making a lot of noise, what are you actually requesting? What functions exactly? If you don't have numbers to back your request, just stop it already. behdad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
