Re: Type checking

[Colomban Wendling <lists ban herbesfolles org>]

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.