[Mesa-dev] [RFC PATCH] i965: Allow C++ type safety in the use of enum brw_urb_write_flags.

[Chad Versace]

On 08/23/2013 02:18 PM, Paul Berry wrote:

> The disadvantages are that (a) we need an explicit enum value for 0,
> and (b) we can't use related operators like |= unless we define
> additional overloads.

Disadvantage (a) is trivial, not really a problem.

Disadvantage (b) can be made painless with the macro I discuss below.


> So what do folks think?  Is it worth it?


Yes, I think it's worth it. The code becomes more readable and
more type safe, as evidenced by the diff lines like this:
 > -                       unsigned flags,
 > +                       enum brw_urb_write_flags flags,

If we continue to do this to other enums, then we should probably
define a convenience macro to define all the needed overloaded
bit operators. Like this:

   #define BRW_CXX_ENUM_OPS(type_name) \
       static inline type_name \
       operator|(type_name x, type_name y) \
       { \
          return (type_name) ((int) x | (int) y); \
       } \
       \
       static inline type_name \
       operator&(........) \
       ........ and more operators


> +/**
> + * Allow brw_urb_write_flags enums to be ORed together (normally C++ wouldn't
> + * allow this without a type cast).
> + */
> +inline enum brw_urb_write_flags
> +operator|(enum brw_urb_write_flags x, enum brw_urb_write_flags y)
> +{
> +   return (enum brw_urb_write_flags) ((int) x | (int) y);
> +}
> +#endif

I think the comment is distracting rather than helpful. There is no need for C++
code to apologize for being C++ code.

For what it's worth, this patch is
Reviewed-by: Chad Versace <chad.versace at linux.intel.com>