On 10/6/05, Nikolaj Kiær Thygesen <[EMAIL PROTECTED]> wrote: > ... and after a number of years developing phones for the low-end > market I'm very much used to the low-resource situation :o) I feel a slight > discomfort from not checking pointer return values, but if it's to no avail > then...
Heh, yes, I used to write videogames, so it's a bit similar. From habit I always check returns in my own libraries and it feels odd to me too. Perhaps another answer is that GTK is designed as a desktop GUI toolkit and is not so suitable for high reliablility or low resource environments. > It would just be annoying to have done large amounts of work in a > program just to have it crash all the sudden because it couldn't allocate a > widget. > Since you suggested that I should "provide your own memory alloc", > does that mean that I can force gtk allocation of widgets to use my own > custom memory allocation schemes??? Yes, see: http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Allocation.html#g-mem-set-vtable You can provide your own malloc() implementation that does something like: gpointer my_malloc( gsize n ) { void *p; if( !(p = malloc( n )) ) { // or whatever ... do something that you know will free a lot // of RAM and is safe to call, even during a _new(), and // which is guaranteed not to call malloc() itself. // you could even malloc() a megabyte or so as your program // starts as a "guard area" and not use it, then free() when you // get the first out-of-mem and warn the user my_cache_flush(); if( !(p = malloc( n )) ) { // we are totally screwed exit( ENOMEM ); } // set a flag ... our main loop tests this regularly // and warns the user somehow my_low_mem_warning = TRUE; } return( p ); } > I'm pretty unexperienced with gtk, so I might be asking stupid questions > here, but did anyone ever suggest implementing exception-like error-handling > in gtk...??? you know like the setjmp()/longjmp() variation found in some > packages. Yes, this has been proposed a few times, but I think no one really liked the idea when it came to the details. It would make gtk a lot more complicated for a rather marginal improvement for most use cases. John _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
