From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105276 invoked by alias); 9 Nov 2015 13:25:22 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 105263 invoked by uid 89); 9 Nov 2015 13:25:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail-oi0-f53.google.com Received: from mail-oi0-f53.google.com (HELO mail-oi0-f53.google.com) (209.85.218.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 09 Nov 2015 13:25:17 +0000 Received: by oiad129 with SMTP id d129so98960898oia.0 for ; Mon, 09 Nov 2015 05:25:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3lBMObenaROzoO/LW0cLJiU7saOwqd4eKl8XNrFqRbM=; b=PH+qIonA4NE+9d5zQvHssGW4ftG++Cryobe6YMdVvYpqqD7juPSFuRIh9HNLWqQQbo V/uBZaXvH8XJ2dcASh0oiOXDOBXj8bPxrgU2VSnjkJG9bp3+ToNlRURBval+FZnKYE/x oHOj6B/7vcxEIgV0Q4ceA2f+8HeRLjRGXhUsW1vuuzNQMSn1jRMSf6DJxfxVUF3VGN5p sVHV+o50AQgO78uNcBxNopXIXkHtjoZBJ704ZT+YnI0+WZa0Q4BgjW4rkw5MImaO7FeV KttjOfXsw9Iysg4OG2Wzr47FMZ12Rv4okex5W576NGWzyJe6gaw0bu8hRDROp2rFlvDt gVkw== X-Gm-Message-State: ALoCoQnR/n7oNVXZb07R+Gy/mi3ad3ofVYXOAfUhIn16Gjm6DHiYYFjquwRSytPhRsJqHnGO4/XM X-Received: by 10.202.170.196 with SMTP id t187mr7615164oie.78.1447075515718; Mon, 09 Nov 2015 05:25:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.155.2 with HTTP; Mon, 9 Nov 2015 05:24:56 -0800 (PST) In-Reply-To: <563897E6.30006@redhat.com> References: <1446144341-21267-1-git-send-email-palves@redhat.com> <563897E6.30006@redhat.com> From: Patrick Palka Date: Mon, 09 Nov 2015 13:25:00 -0000 Message-ID: Subject: Re: [PATCH] Type-safe wrapper for enum flags To: Pedro Alves Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-11/txt/msg00225.txt.bz2 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.