Re: g_malloc overhead

[Tor Lillqvist <tml iki fi>]

> 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 function might well be useful in some circumstances dealing
with interoperability or data formats, and I don't oppose adding it to
GLib. (Together with g_utf16_strcpy(), g_utf16_strcat() etc.)

But I don't think I have ever personally needed such a function in
platform-independent GTK code;)

(And in code that is inside a Windows ifdef, such functions aren't
needed either. The C library on Windows already has wcsncpy(),
wcscpy(), wcscat() etc.)

> and the macro:
> gtext*  g_text_strncpy  (gtext*dest,const gtext*src,gsize n);

Never, ever. Didn't the previous replies get this across strongly
enough? This idiocy is not something we want to copy from the stone
age Windows programming style.

(In current-day Windows-specific programming in C, I see no reason to
uglify your code with those TEXT() macros, TCHAR types, etc. Just use
wchar_t for characters, wchar_t literals (L'A'), and wchar_t string
literals (L"Foo"), and call the wide-char versions of C library and
Win32 API functions explicitly. Win9x is dead. No reason not to use
Unicode explicitly all the time.)

(And actually, why would one want to do Windows-specific programming
in general in C (or C++) any more... C# and Java are so much nicer.
And neither of them has any of this silly TEXT and TCHAR stuff.)

--tml