On Thu, Jan 29, 2009 at 5:02 PM, Xavier Bestel wrote:
> On Thu, 2009-01-29 at 16:51 +0200, Tor Lillqvist wrote:
>> > I think strncpy() is one of the few that needs an utf8 equivalent,
>> > because a char may span several bytes.
>>
>> Well, he didn't say exactly what semantics he wanted his
>> g_ut
On Thu, Jan 29, 2009 at 5:02 PM, Xavier Bestel wrote:
> On Thu, 2009-01-29 at 16:51 +0200, Tor Lillqvist wrote:
>> > I think strncpy() is one of the few that needs an utf8 equivalent,
>> > because a char may span several bytes.
>>
>> Well, he didn't say exactly what semantics he wanted his
>> g_ut
Tor Lillqvist escribió:
What is wrong with:
gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n);
It isn't needed. The nice thing about UTF-8 is that strings in UTF-8
can be handled with normal C str* functions just fine.
this function it really exist :-[ .
http://library.gno
On Thu, 2009-01-29 at 16:51 +0200, Tor Lillqvist wrote:
> > I think strncpy() is one of the few that needs an utf8 equivalent,
> > because a char may span several bytes.
>
> Well, he didn't say exactly what semantics he wanted his
> g_utf8_strncpy() and g_utf16_strncpy() to have. In the UTF-8 case
> I think strncpy() is one of the few that needs an utf8 equivalent,
> because a char may span several bytes.
Well, he didn't say exactly what semantics he wanted his
g_utf8_strncpy() and g_utf16_strncpy() to have. In the UTF-8 case,
should the "size" mean characters or bytes? In the UTF-16 case,
Hi Tor,
On Thu, 2009-01-29 at 16:37 +0200, Tor Lillqvist wrote:
> > What is wrong with:
> > gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n);
>
> It isn't needed. The nice thing about UTF-8 is that strings in UTF-8
> can be handled with normal C str* functions just fine.
I think st
> What is wrong with:
> gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n);
It isn't needed. The nice thing about UTF-8 is that strings in UTF-8
can be handled with normal C str* functions just fine.
> gunichar2 * g_utf16_strncpy (gunichar2*dest,const gunichar2*src,gsize n);
Such a
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..
Am Montag, den 26.01.2009, 12:40 +0100 schrieb Martín Vales:
> Paul LeoNerd Evans escribió:
> > On Sun, 18 Jan 2009 17:43:57 +0100
> > Martín Vales wrote:
> >
> >
> >> Other overhead i see is the open dir/file funtions, where in windows we
> >> need do the utf8 to utf16 everytime in windows. I
On Sun, 18 Jan 2009 17:43:57 +0100
Martín Vales wrote:
> Other overhead i see is the open dir/file funtions, where in windows we
> need do the utf8 to utf16 everytime in windows. If JAVA,.NET and Qt use
> utf16 by default why in gnome world we use utf8 by default?.
Probably one of the biggest
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 pr
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
Martín Vales writes:
> Colin Walters escribió:
>> On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod wrote:
>>
>>> Lets just say that
>>> UTF-16 is at best implementation details of Firefox.
>>>
>>
>> Well, JavaScript is notably UTF-16. Given that the Web, Java and
>> .NET
To be honest -
On Mon, 2009-01-26 at 18:30 +0100, Martín Vales wrote:
> Colin Walters escribió:
> > On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod wrote:
> >
> >> Lets just say that
> >> UTF-16 is at best implementation details of Firefox.
> >>
> >
> > Well, JavaScript is notably UTF-16. Given that th
Colin Walters escribió:
On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod wrote:
Lets just say that
UTF-16 is at best implementation details of Firefox.
Well, JavaScript is notably UTF-16. Given that the Web, Java and .NET
(i.e. all the most important platforms) are all UTF-16 it's li
On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod wrote:
> Lets just say that
> UTF-16 is at best implementation details of Firefox.
Well, JavaScript is notably UTF-16. Given that the Web, Java and .NET
(i.e. all the most important platforms) are all UTF-16 it's likely to
be with us for quite a w
Martín Vales wrote:
> I can see the advantages of use utf8 but the true it´s most of people
> use utf16. I know gnome/linux/cairo/freedesktop promote utf8 but most
> people use utf16:
> http://unicode.org/notes/tn12/#Software_16
This is a very baseless claim. One that actually turns out to be fal
Paul LeoNerd Evans escribió:
On Sun, 18 Jan 2009 17:43:57 +0100
Martín Vales wrote:
Other overhead i see is the open dir/file funtions, where in windows we
need do the utf8 to utf16 everytime in windows. If JAVA,.NET and Qt use
utf16 by default why in gnome world we use utf8 by default?.
Martín Vales writes:
> hi:
>
> I working with visual c++ in Windows and i find glib very useful for
> many C task, but i am worry about the g_malloc overhead.
>
> We really need a new malloc??
>
> gpointer
> g_malloc (gsize n_bytes)
> {
> if (G_UNLIKELY (!g_mem_initialized))
>g_mem_init_nome
2009/1/21 Liam R E Quin :
> On Mon, 2009-01-19 at 18:43 +0100, BJörn Lindqvist wrote:
>> Actually, a custom allocator could be useful even in the general case.
>> Malloc is a system call and has quite bad performance on certain
>> platforms (windows in particular i think). Something like the gslice
On Wed, 2009-01-21 at 10:21 +0100, BJörn Lindqvist wrote:
> 2009/1/21 Liam R E Quin :
> > On Mon, 2009-01-19 at 18:43 +0100, BJörn Lindqvist wrote:
> >> Actually, a custom allocator could be useful even in the general case.
> >> Malloc is a system call and has quite bad performance on certain
> >>
> Malloc is a system call and has quite bad performance on certain
> platforms (windows in particular i think).
Malloc is not a system call. And please don't make performance
assumptions without having benchmark data to back it up. Note that it
is not necessarily that clear what is a "system call"
On Mon, 2009-01-19 at 18:43 +0100, BJörn Lindqvist wrote:
> Actually, a custom allocator could be useful even in the general case.
> Malloc is a system call and has quite bad performance on certain
> platforms (windows in particular i think). Something like the gslice
> allocator could
> Probably i
Actually, a custom allocator could be useful even in the general case.
Malloc is a system call and has quite bad performance on certain
platforms (windows in particular i think). Something like the gslice
allocator could
Probably improve performance a bit.
2009/1/18, muppet :
>
> On Jan 18, 2009,
On Jan 18, 2009, at 11:43 AM, Martín Vales wrote:
What are the advantages of use a glib_mem_vtable ???. I think we
have the same malloc function in all operating systems?
This vtable allows you to swap in a different allocator with next to
no effort. Maybe it has special OOM handling, or
On Tue, Jan 20, 2009 at 12:48 PM, Larry Reaves wrote:
> On Tue, 2009-01-20 at 09:01 +0100, Martín Vales wrote:
>> BJörn Lindqvist escribió:
>> > Actually, a custom allocator could be useful even in the general case.
>> > Malloc is a system call and has quite bad performance on certain
>> > platfor
On Tue, 2009-01-20 at 09:01 +0100, Martín Vales wrote:
> BJörn Lindqvist escribió:
> > Actually, a custom allocator could be useful even in the general case.
> > Malloc is a system call and has quite bad performance on certain
> > platforms (windows in particular i think). Something like the gslice
BJörn Lindqvist escribió:
Actually, a custom allocator could be useful even in the general case.
Malloc is a system call and has quite bad performance on certain
platforms (windows in particular i think). Something like the gslice
allocator could
Probably improve performance a bit.
gslice i be
On Sun, Jan 18, 2009 at 11:43 AM, Martín Vales wrote:
>
> Other overhead i see is the open dir/file funtions, where in windows we need
> do the utf8 to utf16 everytime in windows. If JAVA,.NET and Qt use utf16 by
> default why in gnome world we use utf8 by default?.
Historically, Unix was a late
29 matches
Mail list logo
