glib wraps the standard malloc() and free() with its own g_ variants, g_malloc() and g_free(), shown in Figure 2-5. These are nice in several small ways: • g_malloc() always returns a gpointer, never a char*, so there’s no need to cast the return value. • g_malloc() aborts the program if the underlying malloc() fails, so you don’t have to check for a NULL return value. • g_malloc() gracefully handles a size of 0, by returning NULL. • g_free() will ignore any NULL pointers you pass to it. In addition to these minor conveniences, g_malloc() and g_free() can support various kinds of memory debugging and profiling. If you pass the -enable-mem-check option to glib’s configure script, the compiled g_free() will warn you whenever you free the same pointer twice. The -enable-mem-profile option enables code which keeps memory use statistics; when you call g_mem_profile() they are printed to the console. Finally, you can define USE_DMALLOC and the glib memory wrappers will use the MALLOC(), etc. debugging macros available in dmalloc.h on some plat- forms. [code lang="cpp"] #include <glib.h> gpointer g_malloc(gulong size); void g_free(gpointer mem); gpointer g_realloc(gpointer mem, gulong size); gpointer g_memdup(gconstpointer mem, guint bytesize); [/code] It’s important to match g_malloc() with g_free(), plain malloc() with free(), and (if you’re using C++) new with delete. Otherwise bad things can happen, since these allocators may use different memory pools (and new/delete call constructors and destructors). Of course there’s a g_realloc() equivalent to realloc(). There’s also a convenient g_malloc0() which fills allocated memory with 0s, and g_memdup() which returns a copy of bytesize bytes starting at mem. g_realloc() and g_malloc0() will both accept a size of 0, for consistency with g_malloc(). However, g_memdup() will not. If it isn’t obvious: g_malloc0() fills raw memory with unset bits, not the value 0 for whatever type you intend to put there. Occasionally someone expects to get an array of floating point numbers initialized to 0.0; this will not work. Finally, there are type-aware allocation macros, shown in Figure 2-6. The type argu- ment to each of these is the name of a type, and the count argument is the number of type-size blocks to allocate. These macros save you some typing and multiplication, and are thus less error-prone. They automatically cast to the target pointer type, so at- tempting to assign the allocated memory to the wrong kind of pointer should trigger a compiler warning. (If you have warnings turned on, as a responsible programmer should!) [code lang="cpp"] #include <glib.h> g_new(type, count); g_new0(type, count); g_renew(type, mem, count); [/code] Source: Havoc Pennington. 1999. GTK Gnome Application Development. New York: New Riders Publishing