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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]