From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41710 invoked by alias); 3 Nov 2015 11:18:05 -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 41693 invoked by uid 89); 3 Nov 2015 11:18:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 03 Nov 2015 11:18:01 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id EAC0A8F289; Tue, 3 Nov 2015 11:17:59 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tA3BHw2T006595; Tue, 3 Nov 2015 06:17:59 -0500 Message-ID: <563897E6.30006@redhat.com> Date: Tue, 03 Nov 2015 11:18:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Patrick Palka CC: "gdb-patches@sourceware.org" Subject: Re: [PATCH] Type-safe wrapper for enum flags References: <1446144341-21267-1-git-send-email-palves@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-11/txt/msg00062.txt.bz2 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