From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73887 invoked by alias); 16 Nov 2015 20:48:38 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 73861 invoked by uid 89); 16 Nov 2015 20:48:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Mon, 16 Nov 2015 20:48:36 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 9AEBBC049D4F; Mon, 16 Nov 2015 20:48:35 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-72.phx2.redhat.com [10.3.113.72]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAGKmZWv019020; Mon, 16 Nov 2015 15:48:35 -0500 Subject: Re: Add null identifiers to genmatch To: Pedro Alves , gcc-patches@gcc.gnu.org, richard.sandiford@arm.com References: <87lhaaosh5.fsf@e105548-lin.cambridge.arm.com> <563E0B2D.3080408@redhat.com> <563FD7F8.1020503@redhat.com> <564A3957.60102@redhat.com> From: Jeff Law Message-ID: <564A4122.9010100@redhat.com> Date: Mon, 16 Nov 2015 20:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564A3957.60102@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg01991.txt.bz2 On 11/16/2015 01:15 PM, Pedro Alves wrote: > Hi Jeff, > > (Sorry I didn't reply sooner, I was OOO.) No worries. >>> >>> Boolean params are best avoided if possible, IMO. In this case, >>> it seems this could instead be a new wrapper function, like: >> This hasn't been something we've required for GCC. I've come across >> this recommendation a few times over the last several months as I >> continue to look at refactoring and best practices for codebases such as >> GCC. > > FWIW, GDB is in progress of converting to C++ and we're pulling in > GCC's C++ conventions as reference, so I thought I'd see what the GCC > community thought here. FWIW, I often look at GCC's conventions, google's conventions, then start doing google searches around this kind of stuff. And as always, the quality of the latter can vary wildly :-) > >> >> By encoding the boolean in the function's signature, it (IMHO) does make >> the code a bit easier to read, primarily because you don't have to go >> lookup the tense of the boolean). The problem is when the boolean is >> telling us some property an argument, but there's more than one argument >> and other similar situations. > > There's more than one way to avoid boolean parameters. > If you have more than one of those, the boolean trap is even > worse IMO. In such cases, enums can help make things clearer for > the reader. E.g.: > > foo (true, false); > foo (false, true); > > vs: > > foo (whatever::value1, bar::in_style); Yea, I saw the latter at some point as well. In general I don't think we've used enums as well as we could/should have in GCC through the years. > > I think that internal helper functions defined close to > their usage end up being OK to use booleans, while if you have > a API consumed by other modules it pays off more to try to > avoid the boolean trap. > > Anyway, sorry for the noise. I know there are bigger fish to fry. Not noise at all -- no need to apologize. jeff