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: Patrick Palka <patrick at parcs dot ath dot cx>
- To: Pedro Alves <palves at redhat dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 9 Nov 2015 08:24:56 -0500
- 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> <563897E6 dot 30006 at redhat dot com>
On Tue, Nov 3, 2015 at 6:17 AM, Pedro Alves <palves@redhat.com> 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.