On Thu, 2008-11-13 at 08:43 +0000, Neil Roberts wrote: > On Thu, 2008-11-13 at 03:29 -0500, Pierre-Luc Beaudoin wrote: > > Le jeudi 13 novembre 2008 à 15:09 +0800, 韦锴 a écrit : > > > CLUTTER_ACTOR_IS_REACTIVE (actor), it is neither TRUE nor FALSE in > > > glib 's definition. > > > > If you look at the definition of TRUE, you'll find out that it is > > !FALSE, and you'll find out that FALSE is 0. Therefore, comparing > > CLUTTER_ACTOR_IS_REACTIVE (actor) to TRUE or FALSE won't be a problem as > > in C any value > or < 0 is considered true, and 0 is false. > > I think the point 韦锴 was trying to make is that you can't do: > > if (CLUTTER_ACTOR_IS_REACTIVE (actor) == TRUE) > ... > > nor > > if (CLUTTER_ACTOR_IS_REACTIVE (actor) > == CLUTTER_ACTOR_IS_VISIBLE (actor)) > ... > > because the macro directly returns a mask of the flags so it will return > 0 or 8, not FALSE or TRUE. This is probably ok for the macro because it > doesn't claim to return gboolean, but clutter_actor_get_reactive does so > we should fix it. The glib docs say the gboolean is 'a standard boolean > type. Variables of this type should only contain the value TRUE or > FALSE'.
One really sneaky problem if you don't normalize is: guint some_boolean_field : 1; obj.some_boolean_field = CLUTTER_ACTOR_IS_REACTIVE (actor); Which says to me "normalize in the macro, avoid 3 day debugging sessions". All the GTK_WIDGET_VISIBLE() etc macros that test flags do that. - Owen -- To unsubscribe send a mail to [EMAIL PROTECTED]
