This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Type-safe wrapper for enum flags
- From: Pedro Alves <palves at redhat dot com>
- To: Patrick Palka <patrick at parcs dot ath dot cx>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Tue, 03 Nov 2015 11:17:58 +0000
- Subject: Re: [PATCH] Type-safe wrapper for enum flags
- Authentication-results: sourceware.org; auth=none
- References: <1446144341-21267-1-git-send-email-palves at redhat dot com> <CA+C-WL8XvvJR_QnKkVX-Znkkk7zLr9COfQipsK8AMAhkuvedQQ at mail dot gmail dot com>
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.
> 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!
--
Pedro Alves