Hello,
While programming in C and GTK+, Why is it "better" to use g_strdup_printf, g_free, g_strcmp0 etc... and fellow glib functions?
Merci!
+3
A:
Their behavior is well-defined on any platform that GTK+ supports, as opposed to the native functions which may perhaps sometimes partway work.
Ignacio Vazquez-Abrams
2010-02-10 20:48:48
+4
A:
I general, GLib's purpose is a utility and portability library. Those in itself are reasons to consider using it.
The specific functions you mention all offer something extra on top of their C standard library variants:
g_strdup_printfis likesprintf, but actually allocates the buffer for you and saves you the guesswork of how large the buffer should be. (The return value should beg_free'd.)g_freeis likefree, but checks for a NULL-pointer.g_strcmp0is likestrcmp, but treats a NULL-pointer like an empty string, and thus sorts it in front.
Shtééf
2010-02-10 20:48:58
The standard `free` is defined to be a no-op if passed a `NULL`-pointer, so `g_free` offers no bonus there.
Chris Lutz
2010-02-10 21:31:54
Still a good idea to match `g_malloc()` with `g_free()` instead of `free()` from libc. I have observed that on Windows it's possible for multiple DLLs to link to separate versions of `malloc()` (with separate internal heap structures) and mixing-and-matching causes crashes. Not sure if this is a real world concern or if it might be true on other platforms, but by using GLIB's wrappers you can avoid that.
asveikau
2010-02-11 05:10:29
Glib also has hooks in `g_malloc()` and `g_free()` where you can add debugging functions to check for memory leaks: http://library.gnome.org/devel/glib/stable/glib-Memory-Allocation.html#glib-mem-profiler-table
ptomato
2010-02-11 13:07:17
Oh yeah, and `g_malloc()` will terminate the program if it fails to allocate the memory, as opposed to `malloc()` where you have to check that the returned pointer is not `NULL`...
ptomato
2010-02-11 14:39:35
+2
A:
For consistent behavior in multiple operating systems. It's a portability thing.
In some other unix environments other than Linux, or if your program is compiled on windows, some of those functions may not exist or behave differently on the target operating system.
Using the glib versions ensure consistent behavior.
Bob
2010-02-10 20:49:22
+1
A:
I have to say, this is well intended but not well executed. It is sorta nice that your program won't crash and burn when you try to free() a NULL pointer. Or sort a NULL string. But that's a mixed blessing. It prevents you from discovering nasty bugs in your code as well. Not only will you have a hard time getting your program ported some day, because you're relying on non-standard functions, you'll have a really hard time because your code was buggy and you never found out.
Hans Passant
2010-02-10 21:24:28
The standard says that `free(NULL)` (or any free on a null pointer) is perfectly safe and is a no-op. No benefits there.
Chris Lutz
2010-02-10 21:34:18