Re: [gtk-list] Re: Why g_print ?

[Ian Main <slow intergate bc ca>]

Hey, that's great :)  Thanks.  Me think this looks like classic FAQ
material to me :)  Shawn ?

Ian

On Thu, 31 Jul 1997, Tim Janik wrote:

> 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
> 
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
> 
>