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
Attachment:
signature.asc
Description: This is a digitally signed message part