From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40910 invoked by alias); 9 Nov 2016 12:21:47 -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 40893 invoked by uid 89); 9 Nov 2016 12:21:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1436 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 ESMTP; Wed, 09 Nov 2016 12:21:46 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4059E8535A; Wed, 9 Nov 2016 12:21:45 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uA9CLi75013964; Wed, 9 Nov 2016 07:21:44 -0500 Subject: Re: [PATCH] gdb: Use vector::emplace_back To: Yao Qi References: <1478651991-5083-1-git-send-email-palves@redhat.com> Cc: "gdb-patches@sourceware.org" From: Pedro Alves Message-ID: <1257b752-107c-684f-feb9-5b190b1575b8@redhat.com> Date: Wed, 09 Nov 2016 12:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00210.txt.bz2 On 11/09/2016 11:12 AM, Yao Qi wrote: > Hi Pedro, > Patch is good to me, a question on coding style below, > > On Wed, Nov 9, 2016 at 12:39 AM, Pedro Alves wrote: >> /* Arguments of --command option and its counterpart. */ >> -struct cmdarg { >> +struct cmdarg >> +{ >> + cmdarg (cmdarg_kind type_, char *string_) >> + : type (type_), string (string_) >> + {} >> + > > Is there any reason you name parameters with tailing "_"? I don't > see anything about tailing "_" in GDB or GCC C++ code standard. We just need names for the parameters that are obviously similar to the public members of the struct they'll be assigned to in the member initializer list just below. (We use "m_" prefix for private members. Public members of plain old data structs don't get the "m_" prefix.) Leading or trailing underscore are the most obvious choices, I think. I mildly prefer trailing over leading for being less easily confused with "m_" IMO, and also, some coding conventions use single leading underscore for private member. I see gcc using trailing underscore for "shadow" parameters too. E.g.: id_base::id_base (id_kind kind_, const char *id_, int nargs_) { kind = kind_; id = id_; nargs = nargs_; hashval = htab_hash_string (id); } But it's probably possible to find different examples if you look deep enough. Would you do/prefer something different? Thanks, Pedro Alves