This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Type-safe wrapper for enum flags

On Tue, Nov 3, 2015 at 6:17 AM, Pedro Alves <> wrote:
> On 11/01/2015 03:19 PM, Patrick Palka wrote:
>>> +
>>> +public:
>>> +  /* Allow default construction, just like raw enums.  */
>>> +  enum_flags ()
>>> +  {}
>> Why not zero-initialize enum_value here? Given that enum_flags
>> represents a bitwise OR of enum_type, it seems reasonable that its
>> default value would be zero rather than uninitialzied.
> My reasoning was to make this look as much as a raw enum as possible.
> If one is zero initialized and other isn't, then I'm going to be
> staring at (client) code wondering whether to initialize or not.
> Making it be like raw enums, the rule is simple.
> But, in any case, client code will still need to explicitly initialize
> in C mode, as then the flags enum is just a typedef.  Thus seems best
> not to rely on default initialization as long as we support C mode.

That makes sense.

>> What are global operator^ and operator& omitted?
> Simply because nothing in the code base trips on the
> need for them.  They'd be needed for things like:
>  flags f1 = ((enum flag_values) some_input_int) & FLAG_VAL1;
>  flags f2 = ((enum flag_values) some_input_int) ^ FLAG_VAL2;
> I'll add them.
> Thanks for the review!

FWIW the latest patch looks good to me.

BTW, I think GCC could make use of this enum_flags abstraction. When
GCC moved to C++ it seems to have went the type-unsafe route regarding
enum compatibility, converting  "enum foo { ... };" to "enum foo_flags
{ ... }; typedef int foo;" which is a pretty inferior solution. Do you
plan on incorporating this abstraction into GCC too? If not, I can
help to do it.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]