public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Pedro Alves <palves@redhat.com>,
	gcc-patches@gcc.gnu.org,        richard.sandiford@arm.com
Subject: Re: Add null identifiers to genmatch
Date: Sun, 08 Nov 2015 23:17:00 -0000	[thread overview]
Message-ID: <563FD7F8.1020503@redhat.com> (raw)
In-Reply-To: <563E0B2D.3080408@redhat.com>

On 11/07/2015 07:31 AM, Pedro Alves wrote:
> Hi Richard,
>
> Passerby comment below.
>
> On 11/07/2015 01:21 PM, Richard Sandiford wrote:
>> -/* Lookup the identifier ID.  */
>> +/* Lookup the identifier ID.  Allow "null" if ALLOW_NULL.  */
>>
>>   id_base *
>> -get_operator (const char *id)
>> +get_operator (const char *id, bool allow_null = false)
>>   {
>> +  if (allow_null && strcmp (id, "null") == 0)
>> +    return null_id;
>> +
>>     id_base tem (id_base::CODE, id);
>
> 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.

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.

I wonder if the real benefit is in the refactoring necessary to do 
things in this way without a ton of code duplication.

Jeff


  reply	other threads:[~2015-11-08 23:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-07 13:21 Richard Sandiford
2015-11-07 14:31 ` Pedro Alves
2015-11-08 23:17   ` Jeff Law [this message]
2015-11-09 14:56     ` Richard Biener
2015-11-16 20:15     ` Pedro Alves
2015-11-16 20:48       ` Jeff Law
2015-11-16 21:52         ` Richard Sandiford
2015-11-16 23:16           ` Mike Stump
2015-11-17 10:01             ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=563FD7F8.1020503@redhat.com \
    --to=law@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=palves@redhat.com \
    --cc=richard.sandiford@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).