From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103596 invoked by alias); 9 Nov 2016 12:43:01 -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 103561 invoked by uid 89); 9 Nov 2016 12:43:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1391, personal X-HELO: mail-qk0-f180.google.com Received: from mail-qk0-f180.google.com (HELO mail-qk0-f180.google.com) (209.85.220.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Nov 2016 12:42:48 +0000 Received: by mail-qk0-f180.google.com with SMTP id n204so243529872qke.2 for ; Wed, 09 Nov 2016 04:42:48 -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-transfer-encoding; bh=QTObCmuAX2/3sLbjIPYfe8UfSveHM3jnvW+Zqr3n5zQ=; b=f8booIkrlUfw8ZxC4Gpyj3RqqnCLUsG1akxvmIYeLp7Shuo/i6X1ZNE5ggc+WRT85s cUH2GXegIg9Kqb+bl/PPWdFe5wcIdGBbRwWkatRvxUse5djv4wPyL/8vz+yUWUoB9FlX Ll71xwnTQopy5cQZp0sP3HdRDaNb2mHYJgHUxpo29qU5ouJR3FN7UaYMrcQQlkGBBXE4 A+0myC6akFb0z4mZ0u6Bk8PjXFTrEQlreQN8vR+j0rEMBNHin47LcF/KbM2/VQCOdmuG QxbuPmIpmBTQ8oDCaybel/0mR3gZsCD88Lgcv3X3TqyRUJFkHPC4RNNnGx18QGUWqwlj kqbw== X-Gm-Message-State: ABUngvdREs17Zq6NoGuoTI+BCmsKab48qf2+kqRWnqdRVm4+XKeufo5ms0OzyeOZ7d84cvEMiIvIPxTw0m7IKg== X-Received: by 10.55.101.151 with SMTP id z145mr17109190qkb.35.1478695367050; Wed, 09 Nov 2016 04:42:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.149.55 with HTTP; Wed, 9 Nov 2016 04:42:46 -0800 (PST) In-Reply-To: <1257b752-107c-684f-feb9-5b190b1575b8@redhat.com> References: <1478651991-5083-1-git-send-email-palves@redhat.com> <1257b752-107c-684f-feb9-5b190b1575b8@redhat.com> From: Yao Qi Date: Wed, 09 Nov 2016 12:43:00 -0000 Message-ID: Subject: Re: [PATCH] gdb: Use vector::emplace_back To: Pedro Alves Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00212.txt.bz2 On Wed, Nov 9, 2016 at 12:21 PM, Pedro Alves wrote: > > 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 know leading underscore is used in some projects, so I want to know is it a C++ code standard that we use trailing underscore in this case or it is your personal coding habit. It is the latter. > > 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 =3D kind_; > id =3D id_; > nargs =3D nargs_; > hashval =3D htab_hash_string (id); > } > > But it's probably possible to find different examples if you > look deep enough. > > Would you do/prefer something different? > Since the trailing underscore usage like this is not mentioned in C++ code standard, people are free to use or not to use it. I don't have a preference on that. --=20 Yao (=E9=BD=90=E5=B0=A7)