Re: utf-16 and glib

[Behdad Esfahbod <behdad behdad org>]

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