Martyn Russell a écrit : > On 17/03/10 22:03, Andrew Cowie wrote: >> in gtk/gtkbutton.c which after wading through several macros ends up as >> a call to g_type_check_instance() in glib/gtype.c with some if/else >> blocks around it. > > [snip] > >> So I'm wondering: can we [C, GTK] do away with one of the code paths >> entirely? It'd be nice to do away with the checks in the internal >> accessors, of course, but that isn't going to happen because the >> internal code is now using the public accessors. >> >> So maybe we can at least not check in the cast macros? >> >> Again, I haven't profiled a C only applcation in a while, so this may be >> out of date. Someone with a GUI heavy C app would need to check. But >> this used to be really expensive for C apps. And meanwhile we're using >> GTK for some years now without using the cast macros at all, and things >> are working. So that's at least a datapoint. > > Isn't this why we have G_DISABLE_CAST_CHECKS ? > And G_DISABLE_CHECKS for g_return*s.
If enabling them really worth it in terms of performances, builders (users, distributors, etc) may want to do so. But if G_DISABLE_CAST_CHECKS does only affect the program that is built with (it changes only the internal casts), G_DISABLE_CHECKS have more impact: the functions would no longer check their arguments, even when called from applications. So I think that using G_DISABLE_CAST_CHECKS may be a good idea if it have an impact on performances, but G_DISABLE_CHECKS is more questionable, and should probably not be the default. My 2 cents.. Colomban W. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list