Re: [gtk-list] Why g_print ?

[Tim Janik <timj psynet net>]

On Wed, 30 Jul 1997, Ian Main wrote:

> This one question still haunts me :)  How come we have g_print, g_malloc,
> g_strdup and fellow glib functions ?

regarding g_malloc(), g_free() and siblings, these functions are much safer
than thier libc equivalences. e.g. g_free() just returns if called with
NULL, i even rely on that behaviour in my apps.
also if USE_DMALLOC is defined, the definition for these functions
changes (in glib.h) to use MALLOC(), FREE() etc...
if MEM_PROFILE or MEM_CHECK are defined, there are even small statistics
made counting the used block sizes (shown by g_mem_profile() / g_mem_check()).

unfortunatly i don't have the dmalloc stuff on my system, so i wrote
a small memory access logger for gubi that covered g_malloc, g_malloc0,
g_realloc, g_free and g_strdup just like g_assert using this fancy
PRETTY_FUNCTION stuff that gcc provides, but i'm drifting off here...

considering the fact that glib provides an interface for memory chunks
to save space if you have lots of blocks that are always the same size
and to mark them ALLOC_ONLY if needed, it is just straight forward to
create a small saver (debug able) wrapper around the normal malloc/free
stuff as well - just like gdk covers Xlib. ;)

actually i think g_strerror() and g_strsignal() are a little bit of
an overkill, but OTOH there might be systems not providing these
functions (not?)...

using g_error() and g_warning() inside of applications like the GIMP
that fully rely on gtk even gives the opportunity to pop up a window
showing the messages inside of a gtk window with your own handler
(by using g_set_error_handler()) along the lines of gtk_print()
(inside of gtkmain.c).

> Thanks,
> 
> Ian

---
ciaoTJ