From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) by sourceware.org (Postfix) with ESMTPS id 563B83858C53 for ; Tue, 12 Jul 2022 11:00:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 563B83858C53 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f51.google.com with SMTP id v16so10602889wrd.13 for ; Tue, 12 Jul 2022 04:00:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rUP1LDLnGoyQ3wSfreaEC1H05wR2qUnp6ac+Vj7aMuU=; b=AhYyI3R7cqj/xvyI+U3m21wWNNPA3ZV72cdxq846wLv3pECXOfBZQLuoRTqsejyIik e60C+cMUsm8dxF5PpWr5+rui7vwGOVOcsk+uwiSxpBVgUu4iKQs2gkbNJMrnbYVG5QWT 63oPYCMbV619ugVV/cpyfEUb6Bp6o/ve7WBWDAMER5nS/l8QHDJ8fLBdwSjCBtfqhDW/ mPTc8v435EXNzyw7Z2BNhh0VlM857FXy1MQiZtSBN2/VxgptoQN+obCG5DA5ST2li50o nVh9k0TvuJxaqRxu8CIxGgMHEwrwXYcbF//SAYA+lW5d2lgcpqE4yPJ9hLNABWX1J8Hy Y8pQ== X-Gm-Message-State: AJIora8NFjblW7g/oY6PX/3705epomGxmL0OFZY6RQJIMIt36KSEtvQv NkGHwwH3w8yordyyo1wWdKIV3+3Kluc= X-Google-Smtp-Source: AGRyM1v+t1+0ykthP77qrVCANToEcgnL/FC8mj1xUBCnkQfVCRdNRwzm8OUIOqmJbDvIEZUP3Qw7cA== X-Received: by 2002:a5d:5601:0:b0:21d:7174:7e9d with SMTP id l1-20020a5d5601000000b0021d71747e9dmr19942861wrv.209.1657623635049; Tue, 12 Jul 2022 04:00:35 -0700 (PDT) Received: from ?IPv6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id m27-20020a05600c3b1b00b003a2e655f2e6sm5924396wms.21.2022.07.12.04.00.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jul 2022 04:00:33 -0700 (PDT) Subject: Re: [RFC] Using std::unique_ptr and std::make_unique in our code To: Florian Weimer Cc: David Malcolm , gcc@gcc.gnu.org References: <20220708204651.42624-1-dmalcolm@redhat.com> <6f183e53-02b9-9472-a5cc-9c57c5c0e898@palves.net> <87zgheskap.fsf@oldenburg.str.redhat.com> From: Pedro Alves Message-ID: <8b686947-1b7e-4380-8ed8-9b05517b75dc@palves.net> Date: Tue, 12 Jul 2022 12:00:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <87zgheskap.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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 11:00:39 -0000 On 2022-07-12 11:21 a.m., Florian Weimer wrote: > * Pedro Alves: > >> 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. > > This doesn't seem to provide much benefit over writing > > uP d; > > and with that construct, you don't need to worry about the actual > relationship between pending_diagnostic and pending_diagnostic_up. Given the guideline, nobody ever worries about that. When you see "_up", you just know it's a unique pointer. And as you point out, there's the custom deleters case to consider too. > > I think the GDB situation is different because many of the types do not > have proper destructors, so std::unique_ptr needs a custom deleter. Yes, there are a few cases like but it's not "many" as you suggest, and most are types for which we have no control, like 3rd party library types, like debuginfod, curses, python. Most of the rest of the custom deleter cases are instead because of intrusive refcounting. I.e., the deleter decrements the object's refcount, instead of deleting the object straight away. These are valid cases, not "GDB is doing it wrong, so GCC won't have to bother". I would suspect that GCC will end up with a good number of custom deleters as well.