From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 591473AA88EB for ; Tue, 12 Jul 2022 00:32:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 591473AA88EB Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-86-1iLY_mSlPmG1yaifn5hYvQ-1; Mon, 11 Jul 2022 20:32:14 -0400 X-MC-Unique: 1iLY_mSlPmG1yaifn5hYvQ-1 Received: by mail-qk1-f199.google.com with SMTP id bl27-20020a05620a1a9b00b0069994eeb30cso6524631qkb.11 for ; Mon, 11 Jul 2022 17:32:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=rO8xczBRW4sqaBgDe0M0mkdn5Bk5yDvBBFwdKsC40H4=; b=6PRcdSDxnfhIPygUOv6xAuyb1x+EMdE175YGZYV+WBRvNLBDevqGeekdLzl3e4d3+t /DsdVtOJGeW7wGoKDANjqIOigkoclBVz+6PLLMD9k6X4bzEzQO2JL1UrLSg6iU0w6mzj PUWhA+Wo2uhAc3znxfDx/uzkmVIU0o0jXBVVMoUbUiKWYmcmml4xMH+BXHS27Q6uGvzx Gn8S3xz6D/P+nndZRjM63vNraI6Nw+aq2aAWbYSpilgTDvYsVRjWYB2LmvUEZc5YOcp9 QTAED6kH6Fbtia873whjrGv55Bw8e1YbtV/IVtSAy2T89hC6snm7Tys1/yZmDKJ4zSXp 6u1w== X-Gm-Message-State: AJIora9+fj7yF6nz5cK/OhMY8q171MrOoyzQfTJqN+0YXxLZ6zap1Gj8 DtvU35XwPYtFutJe5oLaNRlLcfufgTEeRqjQyimNGP07bDCkT5wwySbm3dPo2eAaQ2BRL86LxRf EvKIqYOE= X-Received: by 2002:a05:6214:529e:b0:473:1e3a:9f1b with SMTP id kj30-20020a056214529e00b004731e3a9f1bmr15724961qvb.41.1657585933422; Mon, 11 Jul 2022 17:32:13 -0700 (PDT) X-Google-Smtp-Source: AGRyM1syYiARfgFLqu0pBGzwba8+/T9cKX4qUTyaInL2am4JNunZAaChMEmOX12I0ClHpfjZWRkxGg== X-Received: by 2002:a05:6214:529e:b0:473:1e3a:9f1b with SMTP id kj30-20020a056214529e00b004731e3a9f1bmr15724953qvb.41.1657585933199; Mon, 11 Jul 2022 17:32:13 -0700 (PDT) Received: from t14s.localdomain (c-73-69-212-193.hsd1.ma.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id h19-20020a379e13000000b006b55da43182sm6969672qke.23.2022.07.11.17.32.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Jul 2022 17:32:12 -0700 (PDT) Message-ID: <6e214b5b8c3c50a72ef2340b6d57481c885fe27e.camel@redhat.com> Subject: Re: [RFC] Using std::unique_ptr and std::make_unique in our code From: David Malcolm To: Pedro Alves , gcc@gcc.gnu.org Date: Mon, 11 Jul 2022 20:32:07 -0400 In-Reply-To: <6f183e53-02b9-9472-a5cc-9c57c5c0e898@palves.net> References: <20220708204651.42624-1-dmalcolm@redhat.com> <6f183e53-02b9-9472-a5cc-9c57c5c0e898@palves.net> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2022 00:32:19 -0000 On Mon, 2022-07-11 at 11:56 +0100, Pedro Alves wrote: > Hi! > > On 2022-07-08 9:46 p.m., David Malcolm via Gcc wrote: > > -                                   pending_diagnostic *d, > > +                                   > > std::unique_ptr d, > > I see that you didn't add any typedef for std::unique_ptr in > this patch.  It will be > inevitable that people will start adding them, for conciseness, IME, > though.  Perhaps, but right now I prefer to spell out std::unique_ptr, since I'm not as comfortable with C++11 as I might be. > To avoid diverging > naming styles for such typedefs in the codebase, GDB settled on using > the "_up" suffix (for Unique Pointer) > quite early in the C++11 conversion, and we use such typedefs > pervasively nowadays.  For example, for the type > above, we'd have: > >   typedef std::unique_ptr pending_diagnostic_up; > > and then: > >  -                                  pending_diagnostic *d, >  +                                  pending_diagnostic_up d, > > I would suggest GCC have a similar guideline, before people start > using foo_ptr, > bar_unp, quux_p, whatnot diverging styles. Thanks for the info. I suspect the gdb community is much more comfortable with C++ (and C++11) than the gcc community. The recommendation sounds reasonable for if/when we start adding such typedefs, but, as I said, for now I think I want to spell out std::unique_ptr in the few places I'm using it. Hope this makes sense, and these are just my opinions, of course Dave > > And it would be nice if GCC followed the same nomenclature style as > GDB, so we could > have one single guideline for the whole GNU toolchain, so people > moving between codebases > only had to learn one guideline. > > Pedro Alves >